Reputation: 49
I am slowly learning Django trying to write an app to replace the complicated PHP mess we have now. In the end what we need is pretty simple, but I am trying to wrap my head around what the best way (or "django way") is to do things. Here's what we do:
We manage races (what I'll call events) and do online registrations and payment for them. That basically means the user goes to a URL, fills out some personal info in a form and then they are in the database and sent to PayPal for payment.
So, with the current system some software creates a "race" form with the form fields I want and then behind the scenes a DB table is created with the name of the race. That table holds all of the registrations (obviously has a column for each form field plus some extras for behind-the-scenes processing). Currently I just recreate the form each year of the race, but I'm thinking with Django I am going to be cleaner and save the duplicate work and use the same "form" or "model" in Django land and just have some way to archive that data to another DB.
Anyway, here's where I need some advice: Django seems to do one DB table per model? So what I was thinking was I'd have a "Race" model with some general info about the race including some questions that will decide what form fields show up in my other model (for example, if the race has requires payment, we'll have some extra fields and logic for PayPal). All of the races will be in one DB table, but that's probably fine here...there's not going to be that many.
However, I then am thinking there'd be a "registrations" model that actually has all of those form fields in it and will be behind the actual registration form that people fill out. But I think that means all of the registrations for every race (via a foreign key) will be in it...one table for all of them. Maybe it's not that many, but it seems messy and unclean to have all registrations for all of the races in one table. Races on average have about 500 people, some can be a couple thousand. Do I just live with it or is there a better way to design this?
I'm also trying to think of flexability...where sometimes in the past I've had to manually load some data into the table for a specific form or mass change registrations for a particular race. Yes, I could be more specific with my queries, but it felt safer knowing I could only affect the registrations for one race because they were separate tables. Do I just create database views as some type of alternative?
In the end, I just want to make sure that this is a good design that will not slow down or be too inefficient, for example, when I will need to do sorting occasionally and also exports for each race (so that would end up needing to be queries for a specific race ID and getting everyone who registered just for that race).
Sorry for being so longwinded, I am doing the django tutorial now and I just want to be sure as I am thinking in my head how this will go, that I am going to have a decent design to grow with. Thanks so much!
Upvotes: 0
Views: 216
Reputation: 77942
Django seems to do one DB table per model
Actually you'd better think about it the other way round : a Django "Model" is the representation of one DB table.
But I think that means all of the registrations for every race (via a foreign key) will be in it...one table for all of them. Maybe it's not that many, but it seems messy and unclean to have all registrations for all of the races in one table.
Why ???
Races on average have about 500 people, some can be a couple thousand.
SQL Databases are designed to work on much bigger datasets - think millions of rows and more. With 2000 registrations per race and a few races per year you shouldn't have to worry too much. Now if you have peoples registering for more than one race, you'd be better with three tables:
with a unique constraint on (registration.race_id, registratio.person_id).
From your question I assume you have very few knowledge - if any - or relational databases, so I strongly suggest you take some times learning about proper relational databases modeling.
Upvotes: 1