Utiliser auto_increments pour rejoindre des tables MyISAM dans MySQL

Question

Alors que j'écris depuis longtemps sur php, c'était toujours une compétence que j'ai apprise moi-même et je viens de frapper une crise de confiance mineure sur les jointures de tables!

En supposant une base de données mysql auth contenant les tables MyISAM users et permissions:

users 
- id (auto increment) 
- email 

permissions 
- id (auto increment) 
- name 

Pour vous joindre à ces tables dans un grand nombre à plusieurs (ou un à plusieurs), je l'ai toujours utilisé les tables de bridge comme ceci:

user_permissions 
- id (auto increment) 
- user_id 
- permission_id 

(Je sais que innoDB est capable de relations, mais il est aussi plus complexe et des porcs plus de mémoire, donc dans le but de q Je voudrais rester avec MyISAM)

Ma question particulière est la suivante: est-il sage de joindre les tables en utilisant la clé auto-incrémentée, ou devrais-je générer ma propre clé supplémentaire?

Je suis conscient que des problèmes peuvent se produire si une table est corrompue et que je dois reconstruire ou si je commence à mettre en miroir à deux dbs et les clés sont désynchronisées. Je suis également conscient que si je génère un hachage unique pour chaque ligne (à utiliser dans les jointures), il y a la surcharge de générer un hachage et de vérifier qu'il est nouveau avant chaque insertion de données.

Comment les autres le font-ils? Ces problèmes sont-ils des problèmes que vous avez vus dans des situations pratiques?

Merci pour votre temps!

Adam

Answer 1

Il s'agit généralement d'une décision d'utiliser des clés de substitution (valeurs inventées ou attribuées automatiquement qui n'ont aucune signification au-delà du fait qu'elles sont uniques), et les clés naturelles (clés ayant une signification sémantique par rapport à l'entité stockée, comme un nom ou un numéro de compte bancaire).

Dans votre cas, il n'est pas clair qu'il existe une touche naturelle qui fonctionne (tous les aspects de la table utilisateur peuvent changer - changement de nom après le mariage, etc.). vous voudriez une clef naturelle s'il n'y a aucune possibilité que la clef se transforme tout en gardant les relations. un exemple serait quelque chose comme des noms d'éléments (Au, He, Es, etc.) dans le tableau périodique des éléments (qui ne sont pas susceptibles de changer en plus d'en ajouter de nouveaux, mais bon, tout pourrait arriver ...). En ce qui concerne la corruption de données, les sauvegardes sont vraiment la meilleure protection car tout peut être corrompu. et dans les opérations typiques, vous pouvez toujours conserver la clé primaire lors de la migration ou de la synchronisation. l'utilisation d'une clé de substitution complexe complexe à la place de l'incrémentation automatique fournie par la base de données serait plus risquée car elle complique les insertions (vous devez assurer son unique, et éventuellement gérer les collisions d'une manière sûre de transaction) ...et en effet, une clé de substitution généreusement élaborée n'aiderait pas dans le cas de la corruption de données (aucun moyen de la corréler avec l'enregistrement). Un PK naturel sur l'email de l'utilisateur serait beaucoup de frais généraux - avoir à mettre à jour chaque relation chaque fois que l'email change, l'échange d'adresses e-mail entre deux comptes est compliqué, les index sont beaucoup moins efficaces sur des valeurs larges. les compromis s'inclinent en faveur de la clé d'incrémentation automatique.

un bon writeup est ici:

http://decipherinfosys.wordpress.com/2007/02/01/surrogate-keys-vs-natural-keys-for-primary-key/

Answer 2

La jointure pour l'autorisation et les utilisateurs irait comme:

SELECT  u.*, p.* 
FROM  user_permissions up 
INNER JOIN users   u 
ON   up.user_id = u.id 
INNER JOIN permissions  p 
ON   up.permission_id = p.id 

La colonne id dans user_permission est pas vraiment nécessaire, sauf si vous voulez faire référence à cette d'une autre table. Si vous laissez cette identification, (user_id, permission_id) sera la clé primaire (pas d'incrémentation automatique dans ce cas).