Comments on: SQL Table Layout http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/ Wed, 19 Jun 2013 10:51:37 +0000 hourly 1 By: The most-watched IT questions this week: March 30, 2010 - ITKE Community Blog http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/#comment-75326 The most-watched IT questions this week: March 30, 2010 - ITKE Community Blog Tue, 30 Mar 2010 05:44:01 +0000 #comment-75326 [...] SQL Table Layout, asked by Philsal and answered by Meandyou and [...]

]]> By: carlosdl http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/#comment-74936 carlosdl Wed, 17 Mar 2010 13:32:57 +0000 #comment-74936 I don’t think that would make it unwieldy. The number of tables is not really important, and from the database design point of view, that would be the recommended approach.

]]> By: philsal http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/#comment-74927 philsal Wed, 17 Mar 2010 01:31:32 +0000 #comment-74927 Hi
Yes we programmed it in our legacy system (which is not sql). We could have a seperate table per group but there are 396 different properties in the database. Would this make it unwieldy?

]]> By: carlosdl http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/#comment-74921 carlosdl Tue, 16 Mar 2010 23:10:48 +0000 #comment-74921 “In our legacy system this was handled automatically”

automatically, how ?

Something may look as ‘automatic’ to the users, but internally there must be a process that automates it. How was that managed internally ?

On the other hand, how about the one look up table for each group of properties approach (which is the option I would prefer) ?

]]> By: philsal http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/#comment-74919 philsal Tue, 16 Mar 2010 22:02:02 +0000 #comment-74919 I guess the biggest issue I have is that I want to add relations into the tables so that tools such as crystal reports can just populate the links between tables. It seems to me that this means the every property in the base tables require two fields. There are going to be many hundreds of these so it doesnt seem to me to be efficient way of handling. In our legacy system this was handled automatically

]]> By: carlosdl http://itknowledgeexchange.techtarget.com/itanswers/sql-table-layout/#comment-74899 carlosdl Tue, 16 Mar 2010 15:07:33 +0000 #comment-74899 Another option could be splitting the properties table:

PROPERTY_GROUP
GroupId		(PK)
GroudDescription

PROPERTY_TABLE
GroupId		(PK)
PropertyId	(PK)
PropertyValue

Then, your other tables would need to include the GroupId and the PropertyId.

The option of having 1 table for each group of properties is also a good one, and both have pros and cons.

]]>