Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / General / Data Warehousing / October 2005

Tip: Looking for answers? Try searching our database.

Generic data types in SQL Server

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
JohnMSyrasoft - 05 Oct 2005 16:00 GMT
Hi, I have a best question practice about database design.  My idea is to
store business rules information for my customers.  Basically, I define a set
of rules.  For each rule, I know the type.  Then I want to describe the
customers' sets of rules.

I want a table of CustomerID, RuleID, Value

Example:  
Rule 1 = tax rate (Currency)
Rule 2 = Fiscal Year Start (Date)
Rule 3 = Have website (Boolean)

Then, my table might look like this: (CustomerID, RuleID, Value)

123,1,7.5
123,2,#1/1/5#
123,3,True

Obviously, I can't have a single column in SQL Server 2000 that holds
variant types.  One solution is to have a column for each type and keep Null
values in all of them except the correct type column.  That doesn't seem
right.

One suggestion was to cast the value to Binary, store it as such and then
cast the Binary value back to the expected data type when we need to use it.  
Would that work in all cases?

Any thoughts are appreciated.  
Peter Nolan - 05 Oct 2005 23:03 GMT
John,
these are not 'business rules'...these are attributes of customer and
would most effectively be stored as separate attributes.....overtyping
fields based on other fields is something we did in languages like
cobol to save space and coding......not really something we should do
in an environment where the end user is supposed to query the data.

Best Regards
Peter Nolan
www.peternolan.com
Adam Machanic - 10 Oct 2005 05:41 GMT
To add to Peter's reply, what you're doing is creating what is known as an
OTLT (One True Lookup Table) or EAV (Entity Attribute-Value).  This is a
very common mistake that developers new to databases make, and it can cause
severe data integrity problems.  Please refer to:

http://groups.google.com/groups?hl=en&q=database+otlt&qt_s=Search
http://groups.google.com/groups?hl=en&q=database+eav&qt_s=Search
http://groups.google.com/groups?hl=en&q=first+normal+form&qt_s=Search

Signature

Adam Machanic
SQL Server MVP
http://www.datamanipulation.net
--

> Hi, I have a best question practice about database design.  My idea is to
> store business rules information for my customers.  Basically, I define a
[quoted text clipped - 27 lines]
>
> Any thoughts are appreciated.
Jacco Schalkwijk - 10 Oct 2005 17:03 GMT
I looked at the first search and at the first thread that came up. OTLT was
advocated (amongst others) by a guy from HP Openview. I have worked with HP
Openview and I though it was a pile of junk*.  I now understand why.

* clearest memory of that symptom: having a dialog box with 3 buttons, 2 of
which had the same keyboard shortcut

Signature

Jacco Schalkwijk
SQL Server MVP

> To add to Peter's reply, what you're doing is creating what is known as an
> OTLT (One True Lookup Table) or EAV (Entity Attribute-Value).  This is a
[quoted text clipped - 36 lines]
>>
>> Any thoughts are appreciated.
Peter Nolan - 31 Oct 2005 15:17 GMT
Hi Adam,
wow, it even has a name? And I've not heard of it? That's something.

We have done things like encode large numbers of miscellaneous codes
into one lookup table to save ourselves the paid of having large
numbers of lookup tables...and one operational system I used to use at
IBM was the Common Table Management System where very large numbers of
code tables were stored.....but these were not attributes of a defined
entity....or they were used to decode code stored on the original
entity when we wanted to save space.....not an issue any more..

Peter
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.