June 3, 2008 at 2:58 pm
Hello all,
I'm building a brand database.
When it comes to using a character data types, I'm not sure what is the best to use: unicode (nchar,nvarchar) or non-unicode (char,varchar).
I know there is a difference in maximum characters allowed: 4000 vs. 8000.
With the future database change trend in mind, what are the pros and cons of choosing either type?
Any comments are welcome,
TIA,
Cullen
Cullen
Dare to Question -- Care to Answer
Time is like water in a sponge, as long as you are willing you can always squeeze some.
--Lu Xun, Father of Modern Chinese Literature
June 3, 2008 at 6:20 pm
The main advantage of unicode types is that they can handle more characters from more alphabets than non-unicode types which can be important if you are building something that can be used around the world.
The downside is that you need twice as much space to store unicode types than non-unicode ones. For example,
declare @n nvarchar(3), @r varchar(3)
select @n = N'BOB', @r = 'BOB'
select datalength(@n), datalength(@r) -- 6 and 3, respectively
June 3, 2008 at 6:27 pm
If you need to use languages outside English, then use Unicode. If you are sure you won't, then stick with regular varchar.
June 4, 2008 at 8:23 am
Thanks Steve, K. for the comments/suggestions.
Is there any danger of of varchar or char data type being dropped in future releases of MSSQL as image, ntext and text types are?
Cullen
Dare to Question -- Care to Answer
Time is like water in a sponge, as long as you are willing you can always squeeze some.
--Lu Xun, Father of Modern Chinese Literature
June 4, 2008 at 9:08 am
No danger of that. Not any time soon, anyway.
This page has a list of what will be removed in future editions:
http://technet.microsoft.com/en-us/library/ms143729(SQL.100).aspx
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 4, 2008 at 9:46 am
Thanks GSquared!
The document talks about "timestamp syntax for rowversion data type" being deprecated. Can you enlighten me as to what timestamp syntax is?
Cullen
Dare to Question -- Care to Answer
Time is like water in a sponge, as long as you are willing you can always squeeze some.
--Lu Xun, Father of Modern Chinese Literature
June 4, 2008 at 11:23 am
create table Test (
ID int identity primary key,
Timestamp, -- Like this <---
OtherColumns...)
Currently, you can create a table with "Timestamp" as a column name, or data type, and it really isn't what the title seems to indicate. It's really a sequential binary "row version" that gets created when the row is inserted and changes every time the row is updated.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 4, 2008 at 12:17 pm
Thanks GSquared,
Timestamp field will be around, right?
create table Test (
ID int identity primary key,
rowversion Timestamp, -- Is this how it should be used in the future?
OtherColumns...)
Cullen
Dare to Question -- Care to Answer
Time is like water in a sponge, as long as you are willing you can always squeeze some.
--Lu Xun, Father of Modern Chinese Literature
June 4, 2008 at 12:32 pm
I think the plan is to just use Rowversion.
create table Table (
ID int identity primary key,
Rowversion,
OtherColumns...)
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
June 4, 2008 at 12:44 pm
Thanks very much!
Cullen
Dare to Question -- Care to Answer
Time is like water in a sponge, as long as you are willing you can always squeeze some.
--Lu Xun, Father of Modern Chinese Literature
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply