views:

79

answers:

2

There's an old question that asks this very thing, but a lot has changed in databases and unspoken standards.

I generally live by the rule as to never make a field size text or memo, even if it speeds up the database. Primarily because someone could flood and possibly hack the db if there are no restrictions in the input interface.



That said, what is the general practice these days for name fields in a table?

CREATE TABLE foo (
     name_first  Varchar(64) Not Null
   , name_middle Varchar(64) 
   , name_last   Varchar(64) Not Null
);

I think is my default, but how are others coping with foreign names and more than 3 names?




+1  A: 

That should be plenty. We have millions of names from all nationalities and our longest lastname is 29 characters. I would add a personalsuffix field as well for Jr. Sr. III etc.

HLGEM
That's interesting, how did you acquire these names? 29 is pretty long! Additionally, what did you set your field to be? In most databases these days there is no pre-allocation of space, thus `varchar(30)` has the same performance impact as `varchar(255)`. Conversely, databases do see a performance gain in disambiguating the field size (`text` is better performing than `varchar(n)`) due to less computational overhead. My primal concern is with foreign names, including multi-worded names, which are common in hispanic names.
vol7ron
We import name data from our clients' databases and include many many foreign names as our clients are international companies. Our field is very large as we don't know what we will get from a client, but 50 seems a reasonable choice. You can always make it bigger later if you need to. Speaking for SQL Server, Varchar(max) is a poor choice as there are indexing issues and Text is deprecated and should not be used at all.
HLGEM
A: 

My theroy is, is better to have a lot more than to need a few. why not to use varchar(100)?

Chocolim
I like to think about portability and consistency. Keeping something consistent between databases is ideal. `100` is a consideration. I also like to keep things smaller because with enough bytes, someone could possibly find a way to do something malicious on the database.
vol7ron
Additionally, if you're designing the system to allow 100 characters, then your input fields have to allow 100 characters (otherwise, what's the point). And while it's quite possible to do this without causing the fields on the screen to get unwieldy, it does create extra work if developers are in the habit of letting the database control the display size of the field.
Justin Cave
The developers should never let the database control the display. And they should always clean everything before update the database. I always use varchar of 15, 50, 100, 200. Because i can use the same maxlegth in my controls, and i always remember the size
Chocolim