 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / General / Performance / July 2008Storing Integer values in varchar datatype
This is a pretty basic question and I think I know the answer but want to make sure I'm getting it right. If you store a value with data integer into a column that is datatype varchar, is there overhead? I'm just wondering if I have a generic table that stores various values with different datatypes into a single column if I will have a big loss in performance. Thanks. Yes, you do, especially for integer types. They process VERY efficiently through the CPUs in modern computers. Storage size is another savings, which translates into less IO which is very important for performance as well. Another issue is that you will (or SHOULD anyway) convert the field to it's appropriate type before using it in a query, where clause, join, etc. Another performance hit. Just don't do it. Use the most appropriate/correct datatype at all times (design, schema, code, etc).  SignatureKevin G. Boles Indicium Resources, Inc. SQL Server MVP kgboles a earthlink dt net > This is a pretty basic question and I think I know the answer but want to > make sure I'm getting it right. If you store a value with data integer [quoted text clipped - 5 lines] > > Thanks. Okay, I agree with you in general practice, however, what I'm wresting with now has to do with auditing. Someone has suggested to me that for an audit that is populated through triggers after data changes that I use multiple tables, one for each datatype. To clarify, if TableA having data1 (int), data2 (string) is updated the change from data1 would go to one table housing only integer values while data2 changes would be stored in a second table. I understand what they're getting at but it still seems less efficient then having a single audit table with change values being all stored in a varchar. If I'm not mistaken an integer is padded with one or two bytes when stored as a varchar, but this still seems like it would be less then having multiple tables where I'd likely need id's for each table which ultimately would be more expensive. Further, having it broken out this way seems to needlessly complicate things. I apprecaite your input. Thanks. >Yes, you do, especially for integer types. They process VERY efficiently >through the CPUs in modern computers. Storage size is another savings, [quoted text clipped - 11 lines] >> >> Thanks. > I understand what they're getting at but it still seems less efficient > then having a single audit table with change values being all stored in > a varchar. If I'm not mistaken an integer is padded with one or two > bytes when stored as a varchar, but this still seems like it would be > less then having multiple tables where I'd likely need id's for each > table which ultimately would be more expensive. Since an audit table is being written to far more often than being read from, it seems like a good tradeoff to use general data types to store all sorts of data. varchar is good for the keys. For the rest, you may be interested in sql_variant or xml. SignatureErland Sommarskog, SQL Server MVP, esquel@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx Why don't you make a straight-forward audit system (or purchase one such as ApexSQL Audit or other third-party vendors) by having audit tables that duplicate the base table structures and have the necessary additional fields required such as username, change-date, etc? SignatureKevin G. Boles Indicium Resources, Inc. SQL Server MVP kgboles a earthlink dt net > Okay, I agree with you in general practice, however, what I'm wresting > with [quoted text clipped - 41 lines] >>> >>> Thanks. > Okay, I agree with you in general practice, however, what I'm wresting with > now has to do with auditing. > > Someone has suggested to me that for an audit that is populated through > triggers after data changes that I use multiple tables, one for each datatype. Well, you could use one table with multiple columns for the data. You can even ensure only one of them is not null via constraints. I do not know your auditing requirements (i.e. what data do you need especially for querying) but another option would be to have a table with timestamp and varchar which contains a descriptive statement about the change. It all depends. Kind regards robert |
Reply to this Message |
 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.