StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
689623
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2009-03-27T12:41:37.250
FavoriteCount
0
LastActivityDate
2009-03-27T12:48:13.133
LastEditDate
2009-03-27T12:48:13.133
LastEditorUserId
21849
OwnerUserId
21849
ParentId
686633
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
DanVinton
text
Body
At risk of not answering the question at all... You seem to have a business rule that says "this particular field should contain a maximum of N characters." I would argue that both the database column's size and the textbox maximum length are separate consequences of this business rule. Fixing one from the other confuses correlation with causation. In addition, enforcing this business rule by examining the maximum length of the database column has other effects: <ul> <li>you'll hit the database every time for what could otherwise be an in-memory validation operation;</li> <li>if your business rule changes slightly (eg: N goes from 100 to 80 characters) then you need a schema-level change;</li> <li>some databases working with variable-length character encoding like UTF8 only fuzzily define how many characters even fit in a given column;</li> <li>more broadly, you're coupling the business rule to an implementation artifact - what if you later decide to use an object database?</li> </ul> I'm not suggesting that you don't sensibly size your database columns (you should), only that you decouple the business rule from the database implementation. If you can get away with a simple fixed-length-check in the application code, I would suggest that. Edit having read your question a little more carefully, for your text field maximum lengths you need N ahead of validation. Nonetheless, this is still a business rule - can you write a <code>MaximumLength</code> attribute for your field accessors and interrogate that? 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POValidating string lengths based on related database columns
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USDan Vinton
UserOwnerUserId
1. USDan Vinton
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POValidating string lengths based on related database columns
 singulars
 PostTypePostTypeId
 PTQuestion
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
 VTDownMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. This table or related slice is empty.

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.