Quote:
Originally Posted by BentBastard
My 2 cents
ID: best porn name that we here at VEF prefer, if we are in agreement in the first place then this should rarely if ever change, obviously if it is changed then all other csv's linking to the model need to be updated. In many cases this will be the same as Professional Name: but need not be.
BB
|
Sorry for entering this thread so late in the piece, but:
When designing a database where the potential primary key is not immutable, one should instead create a surrogate primary key field, e.g. numeric.
Benefit: other tables linking to this one can then rely upon that primary key field. Allows all model names/ID to be altered as/when desired. Also allows different models with the same name, i.e. "Tina" or whatever is not a very good choice for primary key. NB, would need additional info. to distinguish this "Tina" from another of the same name, e.g. photo/nationality/filmography/whatever.
Cost: slightly greater complication to data structure, as would have something like:
modelKey [primary key, numeric, unique]
ID [agreed best name at VEF]
...
A normalised database, as opposed to a simple CSV, would have a related table of model names/aliases, and the ID field would be a foreign key pointing to whichever was the agreed best name:
Models table:
modelKey [primary key, numeric, unique]
ID [foreign key, corresp. nameKey selected for this model, perhaps null if undecided?]
Nationality
...
Names table:
nameKey [primary key, numeric, unique]
modelKey [foreign key to Models table]
name [string]
"Aliases" would be a lookup query/join based on Names with corresp. modelKey as their FK.
Sorry, my SQL is getting rust through lack of use.
Late edit:
A Names table would, however, only be useful if other data were being associated with those individual names/aliases.