Database Types Table

Need something opinions and thoughts..

[AndAgain]

This is really realated to any type of database design, but we are working with MS SQL and .Net Code.

My question is that I and most of the developers that I have worked with have used dataType tables. For example, PageType, ProductType etc.

In a data model we are reviewing right now the developer is using a Types table that contains all dataTypes from all of the many tables of this database. This types table contains about 50 different dataTypes.

Now my question is what are some of your thoughts on this approach VS breaking the types into their own tables?

Thoughts and comments greatly appreciated.

Thank you,
AndAgain

[TheNige]

I'm not too sure what you are talking about. Can you give an example of the data in the tables?

If I can guess at what you are saying...there is no problem with breaking out related tables to be used specifically for their own purpose such as PageType, or ProductType which are related to the Page and Product tables.

If the PageType and ProductType tables are exactly the same schema though (same columns and data) then it could be feasible to keep them all in that table.

[Easy_Coder]

AndAgain,

I've seen both and done both. If I had my druthers I'd set the types into their own tables. That takes some heat of one single type/config table.

Everyime I've either done or seen this it's because time was extremely limited so in my case I've always kluged it into a single table... but when I get the time then I prefer seperate tables.

[aspdaddy]

I would also use separate tales. I have seen some of the schema of commercial products that do the other way, using attribute and atrribute type tables and the queries on them quickly become a nighmare.

As a simple starting point, 1 database table per entity isnt a bad approach.