Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Enums in SQL Server Expand / Collapse
Author
Message
Posted Tuesday, August 28, 2007 8:31 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 5:39 AM
Points: 4,463, Visits: 6,391
IIRC, this is one of the worst things you can do with a UDF. It essentially equates to RBAR (Row By Agonizing Row) processing under the covers - as in a lookup for each row streaming through the resultset.

Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #394322
Posted Tuesday, August 28, 2007 9:28 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, April 30, 2013 9:07 PM
Points: 1,529, Visits: 824
Comments are not necessarily free. They can be costly at maintenance time. There are many occasions when the code is changed and the comments are not...especially when the changes are not done by the original developer. An enum forces the code to use a value from a limited set and still allows for good readability.

An enum does cost more at compile time but is translated to an integer value at runtime. I would think that if an enum was used in a stored procedure that is compiled once, the performance penalty of translating a character string to an integer value at compile time would be negligable.

An enumeration also acts as another integrity test through type checking. This, IMHO, is more valuable than the small performance gains from using any type of integer.



Post #394351
Posted Tuesday, August 28, 2007 10:12 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, November 26, 2014 9:53 AM
Points: 3,475, Visits: 584

Isn't it called Dictionary Objects?

http://www.microsoft.com/technet/scriptcenter/scripts/misc/diction/default.mspx?mfr=true

Dictionary Objects




Regards,
Yelena Varshal

Post #394372
Posted Tuesday, August 28, 2007 12:13 PM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 5:39 AM
Points: 4,463, Visits: 6,391
1) >>Comments are not necessarily free. They can be costly at maintenance time. There are many occasions when the code is changed and the comments are not...especially when the changes are not done by the original developer. An enum forces the code to use a value from a limited set and still allows for good readability.

2) >>An enum does cost more at compile time but is translated to an integer value at runtime. I would think that if an enum was used in a stored procedure that is compiled once, the performance penalty of translating a character string to an integer value at compile time would be negligable.

3) >>An enumeration also acts as another integrity test through type checking. This, IMHO, is more valuable than the small performance gains from using any type of integer.

**********************
for Item 1 above, comments are most useful when they are made by OTHER THAN the original developer. In any case, if developers don't adhere to good commenting then they need to be upgraded.

for Item 2 above, which particular method of enumeration are you espousing here. There have been several given in this thread and on the original web posting.

for Item 3 above, your comment is invalid in so much as you can type the wrong value in just like you can type the wrong value in when you do the lookup to get it.


Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #394433
Posted Tuesday, August 28, 2007 12:26 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, May 30, 2010 3:18 PM
Points: 14, Visits: 74
Please fix the print style sheet so the text is not truncated.
Post #394444
Posted Tuesday, August 28, 2007 1:39 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, December 5, 2014 5:54 PM
Points: 1,341, Visits: 805

Although an admirable effort, the author misses the mark.

I would urge readers to, instead, push the folks at Microsoft to implement proper support for relational domains. This is the superior and theoretically sound solution.

TroyK




Post #394464
Posted Tuesday, August 28, 2007 2:15 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Monday, December 15, 2014 4:38 AM
Points: 3,110, Visits: 11,528

I don’t see any point to the idea of ENUMS; basically, it solves a problem that doesn’t exist.

 

There is nothing wrong with any of the techniques in the code below, other than the author not liking to write it.

 

I will say that you should never use a hard coded ID value; that defeats the whole purpose of a surrogate key by hard-coding the meaning of a particular ID.

 

 

--Method 1

select

      Order.OrderId,

      Order.OrderDate,

      Order.PaymentTypeId

from

      Order

      join

      PaymentType

      on Order.PaymentTypeId = PaymentType.PaymentTypeId

where

      PaymentTypeDescription = 'Invoice'

 

 

or

 

--Method 2

select

      Order.OrderId,

      Order.OrderDate,

      Order.PaymentTypeId

from

      Order

where

      Order.PaymentTypeId in (

      select

            PaymentType.PaymentTypeId

      from

            PaymentType

      where

            PaymentTypeDescription = 'Invoice'

      )

 

or

 

--Method 3

declare @PaymentTypeId int

 

select

      @PaymentTypeId = PaymentType.PaymentTypeId

from

      PaymentType

where

      PaymentTypeDescription = 'Invoice'

 

select

      Order.OrderId,

      Order.OrderDate,

      Order.PaymentTypeId

from

      Order

where

      Order.PaymentTypeId = @PaymentTypeId

 

 

 

 

Post #394477
Posted Tuesday, August 28, 2007 5:16 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, July 22, 2014 3:27 PM
Points: 126, Visits: 137
This, like many articles, seems written by a person who hasn't read much of the existing thought on the topic, and is therefore blindly bumping into old issues that have already been covered in much more detail elsewhere. Read Celko, read Date, read about all the reasons for the surrogate key optimization, then come back and write something if there's more to say than has been said already.

FWIW: surrogate keys are both evil, and necessary for scalability. Unless/until the database vendors come up with an internal engine optimization that avoids this problem (the issue of the width of keys / the cost to compare them / the cost of On Update Cascade), an issue which seems still to be a blind spot for them, we will have surrogate keys with all the extra joins, logic problems and headaches they create.
Post #394531
Posted Tuesday, August 28, 2007 5:43 PM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 5:39 AM
Points: 4,463, Visits: 6,391
It is obviously physically impossible to process many if not most 'natural keys' as efficiently as surrogate ones, therefore your pining about this 'evil' is to no avail. At least you ACKNOWLEDGE the need for surrogate keys - something Celko in his ivory tower still doesn't do. Espousing a 23 character key when a tinyint will suffice as a surrogate is simply ridiculous.

Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #394535
Posted Tuesday, August 28, 2007 9:41 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, September 22, 2014 12:12 PM
Points: 86, Visits: 142

In the SQL 2005 world, I've wondered (but not implemented) code using the SQLCMD metacommand :setvar and :r.  One could use these like #define and #include in C++.

File1.sql
#setvar enumMale M

#setvar enumFemale F

File2.sql:

:r file1.sql

select Name from Person where Sex = '$(enumMale)'

 

The above is contrived and simplistic, but you get the idea - rather than going for enum, just go for symbolic substitution.

Post #394551
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse