2011-06-16 4 views
0

J'ai deux tables, et ce que j'essaie de faire est assez simple mais assez compliqué en même temps - si quelqu'un pouvait m'aider, ce serait génial.Mise à jour de la table MySQL

J'ai les tableaux ci-dessous ...

Table A 
ClientID 
1 
2 
3 

Table B 
ClientID  ID 
1    
1 
3 

Tableau B a les ClientID de la table et le fait A. Tableau Alors, ils se connectent, ce que je dois faire est mise à jour à un ID référence unique.

c.-à-d. ID clientID-UniqueID. Par exemple, si je mis à jour le tableau B, je veux qu'il ressemble à ceci (séquentiel)

Table B 
ClientID   ID 
1     1-1 
1     1-2 
3     3-1 
+0

Pouvez-vous expliquer pourquoi la ligne deux aurait un ID de 1-2? Est-ce le deuxième ClientID de 1? J'essaie de comprendre quelle est votre logique pour créer l'UniqueID. – IAmTimCorey

Répondre

5

Theres pas vraiment aucune raison de le faire. Juste nous une clé primaire auto-incrémentation standard sur table_b.id.

En utilisant InnoDB le schéma ressemblerait à ceci:

CREATE TABLE `table_a` (
    `id` UNSIGNED integer AUTO_INCREMENT, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB; 

CREATE TABLE `table_b` (
    `id` UNSIGNED integer AUTO_INCREMENT, 
    `client_id` UNSIGNED integer, 
    PRIMARY KEY (`id`), 
    KEY (`table_a_id`), 
    CONSTRAINT `table_b_table_a_id_table_a_id` 
    FOREIGN KEY (`table_a_id`) 
    REFERENCES `table_a` (`id`) 
    ON DELETE CASCADE 
) ENGINE=InnoDB; 

Vous remarquerez quelques points clés:

  • InnoDB supporte les clés étrangères et les mesures d'application de l'intégrité associés. En utilisant une contrainte de clé étrangère sur table_b avec ON DELETE CASCADE à chaque fois qu'un formulaire d'entrée table_a est supprimé, toutes les entrées dans table_b ayant l'table_a_id (anciennement ClientID) correspondant à l'entrée supprimée seront également automatiquement supprimées. D'autres actions peuvent être prises à la place si ce n'est pas le comportement souhaité.

  • J'ai normalisé vos noms de colonnes. Pour des raisons de portabilité, vous ne devez JAMAIS utiliser les noms de colonne ou de table de chameau. Au lieu de cela, utilisez toutes les minuscules. Si vous voulez différencier les mots dans la phrase, utilisez un _ comme séparateur de mots.

  • Vous devez avoir une convention de dénomination de colonne/index/clé cohérente. Toutes les clés primaires de chaque table doivent être nommées de la même manière. En outre, les colonnes de clé étrangère doivent utiliser une convention de dénomination qui identifie clairement la table et la colonne étrangères auxquelles elles sont liées. Cela facilite la tâche aux développeurs lorsqu'ils essaient d'écrire/de déboguer/d'optimiser des requêtes, car cela n'a pas nécessairement besoin d'inspecter le schéma pour comprendre les choses.

+1

* 'J'ai normalisé vos noms de colonne. Pour des raisons de portabilité ... '* Pouvez-vous citer une source pour cela, ou l'expliquer? Je n'ai pas entendu cette préoccupation auparavant. – Hammerite

+0

mysql est sensible à la casse sur les systèmes sensibles à la casse (ie * nix) et insensible à la casse sur les systèmes insensibles à la casse (windows).Si vous avez besoin de prendre en charge les deux ou si vous n'êtes pas sûr à 100% de la cible d'installation finale, évitez d'utiliser une sorte de casse mixte (chameau ou autre) pour les noms de tables et de colonnes. Alors que je ne supporte généralement que nix, je m'assure juste que j'utilise la convention que j'ai indiquée juste au cas où et parce que cela rend plus facile d'avoir une seule convention et de ne pas la changer tout le temps. – prodigitalson

0

Vous voudrez peut-être essayer quelque chose comme ce qui suit (en supposant ID est déjà une colonne B):

ALTER TABLE B MODIFY COLUMN ID INT AUTOINCREMENT, ADD PRIMARY KEY (ClientID, ID) 

Si ID est pas encore en B vous pouvez plutôt utiliser

ALTER TABLE B ADD COLUMN (ID INT AUTOINCREMENT), ADD PRIMARY KEY (ClientID, ID) 

Je pense que cela fera ID avoir un compteur d'incrément séparé pour chaque différentdix .

Questions connexes