more tables or more entries

[Tugabargains]

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

[szlamany]

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...

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!

[Tugabargains]

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 ?

[-TPM-]

I'd say normalizing 1 column is pointless.

[vb_dba]

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.

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.