>I'm wondering which is "better" and/or more realistic. I mean in school, I learned you typically want to reduce redundancy within your database, so you decompose tables and elemenate dependencies withing your schema. Sure, seems like a good idea...but is it really worth it?
>
>I mean, say I have an application, which is marketed to many different companies. They all want slightly different things (fields for their data). If you store it all in one huge table (with lots of *cringe* nulls) then you can distrubute the application to the various companies and the code is relatively simplisitc. Companies choose which fields they want and those fields show up, data is inputed into those fields and all.
>
>Of course if you broke that huge table down into smaller tables and did joins were necessary, the representation of that data would be more compact, but would it be much better? I ask, many because the most expensive operation to do is a join.
>
>If you keep it all in one or two big tables you are doing less joins. If you keep it all compactly in many small tables, you do many more joins.
>
>Any thoughts?
>matt

For several similar applications, and to be able to have more "generic" programs, I would put up with (a few) redundant fields in the same table, but keeping everything normalized. That is, if there is a 1:1 relationship, keep the data in the same table.

Hilmar.