nvarchar & varchar

Hi,

I am new to MS SQL. When I create a column in a table, when shall I
use nvarchar or varchar? Please help.

Thanks,
MikeThe nvarchar data type provides support for Unicode characters. This is
needed if you are building an international system that must store different
languages. However, if you have no need to store Unicode characters then you
are better using varchar. The nvarchar data type occupies twice the space of
varchar as it uses 2 bytes to encode each character.

HTH,

Plamen Ratchev
http://www.SQLStudio.com|||On 26 Feb, 15:13, "Plamen Ratchev" <Pla...@.SQLStudio.comwrote:

Quote:

Originally Posted by

The nvarchar data type provides support for Unicode characters. This is
needed if you are building an international system that must store different
languages. However, if you have no need to store Unicode characters then you
are better using varchar. The nvarchar data type occupies twice the space of
varchar as it uses 2 bytes to encode each character.
>
HTH,
>
Plamen Ratchevhttp://www.SQLStudio.com

varchar will support a lot of characters from different languages
though (depending on the collation codepage) so no need to rush into
doubling your storage if you dont "really" need to|||On Feb 26, 10:26 am, "oliver" <oraus...@.hotmail.comwrote:

Quote:

Originally Posted by

On 26 Feb, 15:13, "Plamen Ratchev" <Pla...@.SQLStudio.comwrote:
>

Quote:

Originally Posted by

The nvarchar data type provides support for Unicode characters. This is
needed if you are building an international system that must store different
languages. However, if you have no need to store Unicode characters then you
are better using varchar. The nvarchar data type occupies twice the space of
varchar as it uses 2 bytes to encode each character.

>

Quote:

Originally Posted by

HTH,

>

Quote:

Originally Posted by

Plamen Ratchevhttp://www.SQLStudio.com

>
varchar will support a lot of characters from different languages
though (depending on the collation codepage) so no need to rush into
doubling your storage if you dont "really" need to

Plamen, Oliver Thanks a lot!

Mike|||On Feb 26, 9:47 am, haid...@.gmail.com wrote:

Quote:

Originally Posted by

Hi,
>
I am new to MS SQL. When I create a column in a table, when shall I
use nvarchar or varchar? Please help.
>
Thanks,
Mike

Mike,

Clearly you need to go back to reading the manual or get a Dummy's
book if you don't know the difference between unicode and ascii
strings.

HTH,

Carl Tegeder
Master MS-SQL Administrator|||Carl Tegeder wrote:

Quote:

Originally Posted by

Quote:

Originally Posted by

>I am new to MS SQL. When I create a column in a table, when shall I
>use nvarchar or varchar? Please help.

Quote:

Originally Posted by

Clearly you need to go back to reading the manual or get a Dummy's
book if you don't know the difference between unicode and ascii
strings.

Not the most tactful of responses, but hey.

To the original poster: Google and Wikipedia are your friends.

Number of foreign keys

I understand the number of foreign keys allowed is restricted by the DBMS I
use.
In a general relational schema design perspective how many foreign keys a
table shall have?
If I have large number of foreign keys what anamolies it will lead to?
Is this crucial to identify all the foriegn key relationships for a table?

VinodhOn Thu, 2 Dec 2004 13:06:57 +0530, Vinodh Kumar P wrote:

>I understand the number of foreign keys allowed is restricted by the DBMS I
>use.

Hi Vinodh,

For SQL Server 2000 (and 7.0), this limit is 253 foreign key table
references per table. I can't imagine any serious application ever
exceeding this limit.

>In a general relational schema design perspective how many foreign keys a
>table shall have?

Depends. Some tables will have only one or none, other tables might have
more (sometimes evemn much more) foreign keys. There is no general answer,
just as there is no single "one-size-fits-all" database design. That's why
requirements analysis and normalization are the most important stteps in
database design.

>If I have large number of foreign keys what anamolies it will lead to?

None - fooreign keys PREVENT anomalies, as the database will check all
changes to the data to make sure the constraint is not violated. This will
slow down the processing of insert, update and delete statements, though
not by much (if you use proper indexes).

>Is this crucial to identify all the foriegn key relationships for a table?

Yes. Unless you like cleaning up corrupted data. <g
Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)