-
Notifications
You must be signed in to change notification settings - Fork 1
Database Design
The ORM of Django is very nice and speeds up development a lot, especially compared with writing schemas and queries manually. The generated schema is down-to-earth and easy to get your head around, would it be needed. Special tables (as in not generated by Django) can live along the ordinary Django tables. One such table would be the one (or many?) that is manipulated on every order by a user, where there may be some C program, controlling the RFID reader, speaking to the database (this table is subject to be partitioned on a monthly basis or something, and if it lives entirely out-of-view of Django that would save us from some potential hassle).
Is there a need for partitioning some tables? There’s not a shitload of data coming in, but over time queries might start to run slowly.
Django has built-in support for dumping and loading data through fixtures. This is neat because fixtures are database-agnostic.
Having all tables in the same database is not a problem when it comes to backups. In Postgresql, the pg_dump command have flags to cherrypick what tables to include and exclude from backups. Postgresql has not been mandated by the way, but it is superior to Mysql, which is the only alternative I can think of.