Hi
What is the best policy in general?
More tables with less fields or less tables with more fields?
10 tables with 2 fields each or 2 tables with 10 fields each?
Regards
Printable View
Hi
What is the best policy in general?
More tables with less fields or less tables with more fields?
10 tables with 2 fields each or 2 tables with 10 fields each?
Regards
Unfortunately that is too vague a question...Quote:
Originally Posted by Tugabargains
I've seen commercial applications take "normalization rules" too far - having 500+ tables with just a handful of columns in each table.
Might have looked good at design time, but reporting against or even simply understanding this structure was overwhelming.
Ask a more specific question and we will give you our opinions!
ok,
I have the following problem:
1st Table (Local): LocalID, Name, Seats, OcupaidSeats, refTypeLocal
This table stores data about a local
ex.: 1, Cinema 1, 200, 157, 1
2, Cinema 2, 350, 100, 1
3, Cinema 3, 200, 0, 2
2nd Table (TypeLocal): TypeLocalID, Name
This table stores type of locals, at the moment there is only 2 diferent types but I need to have the facility to add more.
Ex.: 1, Cinema
2, IMax
Shoul I group this two tables and have only one
(Local): LocalID, Name, Seats, OcupaidSeats, TypeLocal ?
I'd say normalizing 1 column is pointless.
It depeneds. If you want to restrict the values in the columns, then normalizing is a good thing. It allows you to perform you validation through referential integrity. If you perform your validation in the application, for each new value you want to validate, you will have to modify/redeploy the application.Quote:
Originally Posted by -TPM-
If you don't care to restrict the values that are in the column, then yes, I'd agree that normalizing the table would be pointless.
So if you need to control the values in the field, then I would suggest the second table. Otherwise, it's not needed.