StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
564811
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
14
CommunityOwnedDate
2009-02-19T13:55:25.187
CreationDate
2009-02-19T11:07:59.037
FavoriteCount
0
LastActivityDate
2012-03-05T19:41:32.507
LastEditDate
2012-03-05T19:41:32.507
LastEditorUserId
186971
OwnerUserId
55159
ParentId
564755
PostTypeId
2
Score
267
ViewCount
0
LastEditorDisplayName
Quassnoi
text
Body
<code>TEXT</code> is used for large pieces of string data. If the length of the field exceeed a certain threshold, the text is stored out of row. <code>VARCHAR</code> is always stored in row and has a limit of 8000 characters. If you try to create a <code>VARCHAR(x)</code>, where x > 8000, you get an error: <blockquote> Server: Msg 131, Level 15, State 3, Line 1 The size () given to the type ‘varchar’ exceeds the maximum allowed for any data type (8000) </blockquote> These length limitations do not concern <code>VARCHAR(MAX)</code> in SQL Server 2005, which may be stored out of row, just like <code>TEXT</code>. Note that <code>MAX</code> is not a kind of constant here, <code>VARCHAR</code> and <code>VARCHAR(MAX)</code> are very different types, the latter being very close to <code>TEXT</code>. In prior versions of SQL Server you could not access the <code>TEXT</code> directly, you only could get a <code>TEXTPTR</code> and use it in <code>READTEXT</code> and <code>WRITETEXT</code> functions. In SQL Server 2005 you can directly access <code>TEXT</code> columns (though you still need an explicit cast to <code>VARCHAR</code> to assign a value for them). <code>TEXT</code> is good: <ul> <li>If you need to store large texts in your database</li> <li>If you do not search on the value of the column</li> <li>If you select this column rarely and do not join on it.</li> </ul> <code>VARCHAR</code> is good: <ul> <li>If you store little strings</li> <li>If you search on the string value</li> <li>If you always select it or use it in joins.</li> </ul> By selecting here I mean issuing any queries that return the value of the column. By searching here I mean issuing any queries whose result depends on the value of the <code>TEXT</code> or <code>VARCHAR</code> column. This includes using it in any <code>JOIN</code> or <code>WHERE</code> condition. As the <code>TEXT</code> is stored out of row, the queries not involving the <code>TEXT</code> column are usually faster. Some examples of what <code>TEXT</code> is good for: <ul> <li>Blog comments</li> <li>Wiki pages</li> <li>Code source</li> </ul> Some examples of what <code>VARCHAR</code> is good for: <ul> <li>Usernames</li> <li>Page titles</li> <li>Filenames</li> </ul> As a rule of thumb, if you ever need you text value to exceed 200 characters AND do not use join on this column, use <code>TEXT</code>. Otherwise use <code>VARCHAR</code>. P.S. The same applies to <code>UNICODE</code> enabled <code>NTEXT</code> and <code>NVARCHAR</code> as well, which you should use for examples above. P.P.S. The same applies to <code>VARCHAR(MAX)</code> and <code>NVARCHAR(MAX)</code> that SQL Server 2005+ uses instead of <code>TEXT</code> and <code>NTEXT</code>. You'll need to enable <code>large value types out of row</code> for them with <code>sp_tableoption</code> if you want them to be always stored out of row. As mentioned above and <a href="http://technet.microsoft.com/en-us/library/ms189087.aspx" rel="noreferrer">here</a>, <code>TEXT</code> is going to be deprecated in future releases: <blockquote> The <code>text in row</code> option will be removed in a future version of SQL Server. Avoid using this option in new development work, and plan to modify applications that currently use <code>text in row</code>. We recommend that you store large data by using the <code>varchar(max)</code>, <code>nvarchar(max)</code>, or <code>varbinary(max)</code> data types. To control in-row and out-of-row behavior of these data types, use the <code>large value types out of row</code> option. </blockquote>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POSQL Server Text type vs. varchar data type
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USMichael
UserOwnerUserId
1. USQuassnoi
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.