I've finally gotten to do something with Django, and naturally this has left me wrestling with schema design. This is the first time I've used an ORM and I find that I'm being pulled two ways, neither of which I think are right.

(I'll pause here to note that the data I have to keep track of in this application is tiny, on the order of a few hundred rows in total. I'm using Django's ORM support because this gives me a bunch of functionality for free, I have to keep track of the data somehow, I don't feel like writing yet another set of file parsing and loading and saving code, and using an SQLite backend makes configuration trivial.)

On the one hand are my SQL instincts. With them, I see the problem through the lens of database tables and joins and I think about things like how to normalize everything. I'm pretty sure that this view is wrong in the end, partly because I don't have direct access to SQL joins and so on and partly because it feels like complete overkill to normalize a table that has perhaps 50 rows.

On the other hand are my Python object design instincts; with them I see how the objects would look if I wasn't using an ORM at all, just writing a straight Python program that was loading all of the data from files in some convenient format and then manipulating it (and saving it) without having to think like a database at all. These objects are full of dicts and arrays and names, with 'this defaults to that if not specified' behavior that's easy in code but stupid in databases. They relate to each other in a spiderweb of perfectly sensible relationships that have nothing to do with set operations.

I'm totally sure that the object oriented view is just as wrong as the pure SQL one, because it turns Django's ORM layer into a dumb object store (well, a set of hash tables more or less). I could use the ORM this way if I wanted to; at my tiny data sizes, brute force will work perfectly well.

Somewhere in the middle is an ORM schema design that is sensible both from a Python perspective and a database perspective. I just have to find out what it is, which probably means thinking about the problem more. (Maybe I should write it up for WanderingThoughts, as a form of talking to the duck. That could get me back to first principles, instead of thinking about how to solve in it Python or SQL.)

PS: I consider all of this a valuable learning experience, not something to get frustrated over. I'm certainly glad to be doing a project with a modern web framework instead of banging HTML and CGIs together by hand.