I have a website that just takes a really big form and saves the data upon submission. That is pretty much the only thing it does. The form has a lot of data like physical address, mailing address, billing address, phone 1, phone 2, phone 3, etc. where it would make sense to split out the tables into user, addresses, phones, and using FK’s to link them together. However, if the site isn’t going to advance at all, is it worth even building out this more complex structure, or should I just store it into one table with mailing_address_1, mailing_address_2, mailing_city, phone_1_number, phone_1_type, phone_2_number, phone_2_type etc?
Share
Though no “best” solution for every case, here are my thoughts on the matter.
If you’re making a prototype – something to create,show and then throw away – you’re definitely okay with doing less than more and bringing one table. Though, even better decision would be not to use the database at all – create simple class, make a global list variable and put your data there – let it be in the RAM (if it’s really a prototype with small amount of data).
If you’re trying to see whether to push or not to push the project further – you’ll have to weigh the options you have. Normalizing database would take like 1 hour and writing all the classes should take 1 more hour and so on. See if your potential investment may return later. Also, you should see whether it would be hard to switch decision in future. If it’s pretty easily changed (like, there’s only one web form and two places where it is used), I’d go for whatever is easy right now.
In most other cases, I’d normalize the database.