4

I like to use a GUI application to design databases using ERD. Currently I am using the EER Diagram of the free MySQLWorkbench.

Once I like the way the ERD looks, I Forward Engineer the ERD in MySQLWorkbench to create the actual database. Then I introspect the MySQL database with django-admin.py inspectdb to Reverse Engineer into an output of a Python snippet code for Django's models.py.

But then I have to take the inspectdb output and manually edit it to my liking. One particular part I really don't like to do is manually eliminating each join table from a many-to-many relationship.

Is there a good (and preferably free) GUI ERD design program out there specifically designed for Django?

hobbes3
  • 28,078
  • 24
  • 87
  • 116
  • Maybe you could copy inspectdb into someapp/management/commands/my_inspectdb.py and adapt it. – jpic Feb 26 '12 at 13:26
  • 2
    any particular reason why you need to design a db in the gui? if you need a diagram, why not do all the models in django and then generate a diagram from an existing db? – miki725 Feb 26 '12 at 13:32
  • Wouldn't it be easier to create the database from Django and reverse-engineer the diagram in MySQL workbench? It'll save you lot of time. – Mariusz Jamro Feb 26 '12 at 13:38
  • 4
    Wait, I'm a bit confused. Like most people, I'm a visual person, so it's easier for me to figure out all the foreign keys and relationship visually than trying to figure it out in a command line or Python script. Unless the database only has a few tables, it's hard for me to design the database from scratch in `models.py`. – hobbes3 Feb 26 '12 at 13:43
  • See http://stackoverflow.com/questions/1806681/gui-designer-for-managing-django-models – enticedwanderer Feb 26 '12 at 14:41

2 Answers2

7

If you wish to design your models at the database level, in the way that you're describing, you are going to need to do exactly that: design your SQL and then convert that into Django models.

This is not the normal way of designing a Django application: typically you would design the models as you wanted them to be, and only put a lot of effort into schema design if you need to resolve some performance problems. Django models aren't really meant to be an abstraction of a relational database: they're meant to be an abstraction of your application's persisted objects, which happens to be implemented on top of a relational database.

There is nothing wrong with wanting/needing to do an explicit schema design, but it makes you a bit of an outlier (most web devlelopers don't), hence the difficulty you're having finding tools suited to your needs.

The closest thing is the graph_models command which is part of Django command extensions. This lets you visualize your models (you still write them in python code, but the visual representation will help you iterate faster).

kdt
  • 27,905
  • 33
  • 92
  • 139
  • 4
    If you don't explicitly design the schema, how could you tell that your tables are appropriately normalized in your Django application? – hobbes3 Feb 27 '12 at 05:15
  • 6
    hobbes3: quite. Lots of Django/PHP/RoR people don't care about normalization -- that's not necessarily right or wrong, but it's the culture. Lots of web applications have databases that are so simple it's irrelevant, or the denormalization actually helps performance. The typical (not always correct) attitude is to start with something simple, and only if there is a performance problem do you change the schema to suit the DB server instead of the human programmer. – kdt Feb 27 '12 at 10:19
  • 3
    Thanks a lot for the culture explanation. Not caring about normalization... wow that's not something I learned from database books haha. But I like how you said to keep it simple. It makes sense to me :-). – hobbes3 Feb 29 '12 at 06:17
  • 1
    @hobbes3 Normalisation is not a goal. Normalisation is a tool to understand tradeoffs in database design. – Marcin Jul 23 '15 at 15:56
4

It is not usual to design a database layout for django apps as such, and doing so is likely to lead to a sub-optimal design.

Instead, just design your model classes, taking account of how you will query them, and the way that ForeignKey (and the other relations types) work. If you don't do this, you are likely to find that your app suffers from conceptual mismatch.

kdt
  • 27,905
  • 33
  • 92
  • 139
Marcin
  • 48,559
  • 18
  • 128
  • 201