The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Another doubt.
As you can see I used VARCHAR(255).
That was because I didn't want to have eventual future limitations.
I could use VARCHAR(100) for example, but I think that there is no advantage of limiting the size.
Is this true ?!?

randem's right... use a separate id instead since common first and last names are not uncommon (pun intended )

as for your field size... using VARCHAR(100) would be a better idea imho... unless you're expecting really long names, go with the max. length you think possible and then add 50% to that (for more leeway)... this would save you space (obviously!) as well as increase efficiency since larger data is obviously slower to read (like randem said... again )

Natural or Surrogate Key

yup, you're right, pippo, there is no difference in size or speed between varchar(100) and varchar(255)

as for your design, table A is much better, not only because of the uniqueness factor, but also when you want to relate another table

for example, let's say that along with your person table, you also want to have a table to list a person's email ids

since this is a one-to-many relationship, the email table will have to have a foreign key which points back to the person table, linking each email with the person it belongs to

if you use lastname and firstname as the primary key in the person table, you will also have to use it in the email table, and then look at how much space that would take up! never mind squeezing a byte or two out of your varchars, think about Constantine Thistlebottom being repeated eleven times because he has eleven emails!

However, your data structures should match the business requirements. This way the data structure themselves becomes a data dictionary for others to model their applications (report generation and the like). If you have your email address VARCHAR( 255 ) and another application reads/writes to it, they may inadvertantly not adhere to whatever limit you developed in your application, which will break your first application. You would need strict documentation stating "Yeah we have it set to 255 but it MUST be kept under X characters" which every application must remember to adhere to. Defining it VARCHAR( X ) is self-documenting.

Also, indexes may be needlessly wide on a VARCHAR( 255 ) regardless of whether or not you have 255 characters in there. It depends on your RDBMS and how they physically store their indexes so it would be wise to see if inefficiencies exist in a VARCHAR( 255 ) index over a VARCHAR( X ).

Further RDBMS-specific indexing may impose a limit on the number of bytes an index can hold. So if you define your table with username and password of 255 characters and attempt to place an index on those two (since typically authentication is done with username and password) you will not be able to create it if your max index length (as specified by the RDBMS) is 300 bytes.