[Db] [mySQL] se non c è crealo!

[Angelo Galleja]

Cristiano Verondini ha scritto:
>> no, sto chiedendo se ci sono dati a supporto del fatto che una join
>> sia più performante con chiavi numeriche piuttosto che con 
>> altri tipi  di dato (e.g stringhe)
> 
>    Bhe, questo mi sembra evidente, se non altro per gli acessi ad indice.

mi è rimasta una parola sulla tastiera :) intendevo "chiavi non numeriche"

> 

>> -   una primary key deve avere una corrispondenza nella realtà,
>>   quindi evitare id numerici sempre e comunque, salvo eccezioni
>> ovviamente :) -   l'eventuale vantaggio ottenuto dall'utilizzo di pk
>>   numeriche sia trascurabile se il prezzo da pagare è la mancata
>> corrispondenza di cui sopra
> 
>    Sinceramente non vedo il motivo di creare una 'relazione' fra una PK 
> e la realtà, ma de gustibus ... :)

vedi risposta all'altro tuo post,

>    Qui c'è comunque  un articolo che elenca un po' di pro e contro: 
> http://www.bcarter.com/intsurr1.htm

"The biggest disadvantage for intelligent keys, and a corresponding
advantage for surrogate keys, is that primary keys are hard to change.
Whenever a primary key changes in value, or columns are added to or
dropped from a primary key, the effects cascade down through foreign key relationships.

Intelligent keys suffer from this problem because not only are they used as primary
and foreign keys but they also have some business meaning associated with them.
When the business changes, so do the primary key values or structure,
with all the problems associated with such a change.

questo non è assolutamente uno svantaggio ed è palese:
la realtà cambia -> i dati che rappresentano la realtà cambiano