This is a discussion on the datatype within the SQL Server forums, part of the Microsoft SQL Server category; --> hello ! I got some problems here. I have an attribute that determines the unit of something,e.g. the size ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| hello ! I got some problems here. I have an attribute that determines the unit of something,e.g. the size of using "mm" , the length of using "seconds" and something others may using "n-page", so ,which data type should I use. the "nvarchar" or others? thank you very much! *** Sent via Developersdex http://www.developersdex.com *** |
| |||
| >> I have an attribute that determines the unit of something,e.g. the size of using "mm" , the length of using "seconds" and something others may using "n-page", so ,which data type should I use. the "nvarchar" or others? << You need to learn how a relational design works. What meaningful name could you give such a column? "some_kind_of_unit" or "don't_know_unit" or "could_be_anything" is a bit vague. Since seconds cannot be transformed into volts, etc. this column is in violation of !NF -- it holds several totally different things, like field in a file system. Units of measure are part of an attribute's value, not an attribute. You are confusing data and meta-data. Get of a copy of SQL PROGRAMMING STYLE or SQL FOR SMARTIES and read the chapters on scales and measurements, and the design of encoding schemes. |
| |||
| If you are just storing the description, eg... mm seconds n-page then I'd hold them using nvarchar and size it according to the maxium length you expect, if its just the above then nvarchar(7). If you are talking about the units themselves then i'd go down this route.... create table unit_type ( id int not null identity constraint sk_unit_type unique clustered, name nvarchar(7) not null constraint pk_unit_type primary key nonclustered ) create table measurement ( unit_type_id int not null references unit_type( id ), unit decimal( 10, 5 ) not null ) Hope that helps. Tony. -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials "John Kevien" <kevien-2002@163.com> wrote in message news:mJBag.1$RV2.122@news.uswest.net... > > hello ! > > I got some problems here. I have an attribute that determines the unit > of something,e.g. the size of using "mm" , the length of using "seconds" > and something others may using "n-page", so ,which data type should I > use. the "nvarchar" or others? > > > thank you very much! > > > > *** Sent via Developersdex http://www.developersdex.com *** |
| |||
| Just curious: why nvarchar instead of varchar? "Tony Rogerson" <tonyrogerson@sqlserverfaq.com> wrote in message news:e4fa0l$327$1$8300dec7@news.demon.co.uk... > If you are just storing the description, eg... > > mm > seconds > n-page > > then I'd hold them using nvarchar and size it according to the maxium > length you expect, if its just the above then nvarchar(7). > > If you are talking about the units themselves then i'd go down this > route.... > > create table unit_type ( > id int not null identity constraint sk_unit_type unique > clustered, > name nvarchar(7) not null constraint pk_unit_type primary key > nonclustered > ) > > create table measurement ( > unit_type_id int not null references unit_type( id ), > unit decimal( 10, 5 ) not null > ) > > Hope that helps. > > Tony. > > -- > Tony Rogerson > SQL Server MVP > http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > SQL Server Consultant > http://sqlserverfaq.com - free video tutorials > > > "John Kevien" <kevien-2002@163.com> wrote in message > news:mJBag.1$RV2.122@news.uswest.net... >> >> hello ! >> >> I got some problems here. I have an attribute that determines the unit >> of something,e.g. the size of using "mm" , the length of using "seconds" >> and something others may using "n-page", so ,which data type should I >> use. the "nvarchar" or others? >> >> >> thank you very much! >> >> >> >> *** Sent via Developersdex http://www.developersdex.com *** > > |
| ||||
| Hi Neil, Its the Microsoft recommendation for string data types, use the N (unicode) versions, there are a few things that require unicode if you use SSIS too. I'm finding it a hard habbit to get into! Tony. -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials "Neil" <nospam@nospam.net> wrote in message news:wpIag.3219$x4.3114@newsread3.news.pas.earthli nk.net... > Just curious: why nvarchar instead of varchar? > > "Tony Rogerson" <tonyrogerson@sqlserverfaq.com> wrote in message > news:e4fa0l$327$1$8300dec7@news.demon.co.uk... >> If you are just storing the description, eg... >> >> mm >> seconds >> n-page >> >> then I'd hold them using nvarchar and size it according to the maxium >> length you expect, if its just the above then nvarchar(7). >> >> If you are talking about the units themselves then i'd go down this >> route.... >> >> create table unit_type ( >> id int not null identity constraint sk_unit_type unique >> clustered, >> name nvarchar(7) not null constraint pk_unit_type primary key >> nonclustered >> ) >> >> create table measurement ( >> unit_type_id int not null references unit_type( id ), >> unit decimal( 10, 5 ) not null >> ) >> >> Hope that helps. >> >> Tony. >> >> -- >> Tony Rogerson >> SQL Server MVP >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a >> SQL Server Consultant >> http://sqlserverfaq.com - free video tutorials >> >> >> "John Kevien" <kevien-2002@163.com> wrote in message >> news:mJBag.1$RV2.122@news.uswest.net... >>> >>> hello ! >>> >>> I got some problems here. I have an attribute that determines the unit >>> of something,e.g. the size of using "mm" , the length of using "seconds" >>> and something others may using "n-page", so ,which data type should I >>> use. the "nvarchar" or others? >>> >>> >>> thank you very much! >>> >>> >>> >>> *** Sent via Developersdex http://www.developersdex.com *** >> >> > > |