A commentator on my recent entry about learning from my Djangoschema design experience wrote,about me abandoning explicit primary keys:

I'm not sure your data will be best served by giving up the databaseschema you want in deference to the conventions and limitations of the(Django ORM) framework.

I want to clarify something: the issues in my schema that are drivingme away from using explicit primary keys and to surrogate keys are not Django specific.

I've now designed two database schemas, one purely in SQL

What Django does to my primary key problem is magnify the effects ofchanges and errors in two ways. First, the admin interface allowsconvenient direct insertion of data into the database, includingimmediately creating foreign key dependencies. People sometimes makemistakes when typing things in; the fewer steps between typing insomething and having it wind up in the database, the fewer chancesyou have of catching your error. In a slower environment I might havenoticed some of my typos after I had written the file of loader commandsor SQL