Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 Question on Datatypes

Author  Topic 

duckkiller53
Starting Member

2 Posts

Posted - 2010-02-16 : 20:57:07
Could someone help me. I am new to actually designing databases with sql server. The following question has me confused. I have a need to store 'paragraph amounts' of data in three separate fields in a table. Currently I have the fields set as Varchar(400). Would I be better of changing them to Text ( which would then allow for a possible blob of data that I may not have prepared for ). Does the 'Text' Datatype consume a massive amount of space in a table and would it be poor design to use it for fields that may or may not have data in them. I hope I have the correct understanding of the 'Text' Datatype. Is it similar to the Access data type 'Blob'.

Any help would be greatly appreciated.

Thanks

Dave.

Dave

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2010-02-17 : 00:01:15
text,ntext etc are deprecated features from SQL 2005 onwards so use datatypes like varchar(max),nvarchar(max) instead. You can store upto 2 GB in a these fields.
If you've very little chance of storing data in them them keep a single max field in separate attribute table and populate it rowwise with associated attribute value also stored in separate field.

------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/

Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-02-17 : 03:09:22
"... keep a single max field in separate attribute table and populate it rowwise with associated attribute value also stored in separate field "

Or a separate 1:1 table linked to the main table on PK and just storing the VARCHAR(MAX) columns. (This may be easier to use in your queries:

SELECT *
FROM MyTable AS T1
JOIN MyBigTextTable AS T2
ON T2.MyPK = T1.MyPK
)

If you are sure that the data will fit in VARCHAR(8000) or Nvarchar(4000) set that limit - rather than VARCHAR(MAX) (it allows you to run some housekeeping routines online, rather than offline - but it is a very small point, so don't let it be the basis of a decision if you think you will need more than that)
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2010-02-17 : 03:16:01
quote:
Originally posted by Kristen

"... keep a single max field in separate attribute table and populate it rowwise with associated attribute value also stored in separate field "

Or a separate 1:1 table linked to the main table on PK and just storing the VARCHAR(MAX) columns. (This may be easier to use in your queries:

SELECT *
FROM MyTable AS T1
JOIN MyBigTextTable AS T2
ON T2.MyPK = T1.MyPK
)

If you are sure that the data will fit in VARCHAR(8000) or Nvarchar(4000) set that limit - rather than VARCHAR(MAX) (it allows you to run some housekeeping routines online, rather than offline - but it is a very small point, so don't let it be the basis of a decision if you think you will need more than that)


you mean keep separate fields as varchar(max). But will that be necessary if chances that you store value in all of them are less?

------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/

Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-02-17 : 03:29:53
Horses-for-courses I think.

If you have an "attribute" table the JOINs can be more problematic (depends how you want to display the data, if "rows" is OK then Attribute table is fine, if "columns" are needed then a 1:1 table is easier).

A VIEW can join the MainTable and 1:1 Table for ease of querying.

1:1 table also reduces the impact of any sloppy SELECT * from the MainTable (i.e. does not pull large Blobs because they are in the 1:1 table)

O/P wants "three paragraph fields", so I think that will work easiest in 1:1 table (or in the main table of course)

If it was "unlimited/large numbers" then I think that would favour the "attribute table" design.
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2010-02-17 : 03:34:27
quote:
Originally posted by Kristen

Horses-for-courses I think.

If you have an "attribute" table the JOINs can be more problematic (depends how you want to display the data, if "rows" is OK then Attribute table is fine, if "columns" are needed then a 1:1 table is easier).

A VIEW can join the MainTable and 1:1 Table for ease of querying.

1:1 table also reduces the impact of any sloppy SELECT * from the MainTable (i.e. does not pull large Blobs because they are in the 1:1 table)

O/P wants "three paragraph fields", so I think that will work easiest in 1:1 table (or in the main table of course)

If it was "unlimited/large numbers" then I think that would favour the "attribute table" design.


Ok that sounds sensible
quite often what we do is to keep an attribute table in cases where we've lot of attributes that rarely store data and then we create a view where we cross tab and show the result as columns when required.
Thanks Kristen for the explanation

------------------------------------------------------------------------------------------------------
SQL Server MVP
http://visakhm.blogspot.com/

Go to Top of Page

duckkiller53
Starting Member

2 Posts

Posted - 2010-02-17 : 08:37:28
Guy's thank you very much for all the information. I am happy to hear your suggestions of storing the varchar(max) datatype info in a seperate table 1:1. That is my how my database is currently designed. I just wasn't sure what to use for the field type.


Thanks


Dave
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2010-02-17 : 09:12:40
If you are stuck with SQL2000 note that TEXT datatype has very limited functions that can interact with it.

Whereas functions that are used on VARCHAR can also be used on VARCHAR(MAX) [SQL2005 onwards] without any issues (AFAIK!)

... quite apart from the fact that TEXT datatypes is deprecated
Go to Top of Page
   

- Advertisement -