J'ai une base de données MySQL qui a 3 tables qui doivent être jointes. Je reçois des bases de données plus petites qui doivent nourrir cette base de données MySQL en ajoutant les nouvelles données que je l'obtiens. Le problème que j'ai est le plus petit DBS que je reçois est généré par une application extérieure et ne sont pas vraiment destinés à être utilisés tous ensemble. Par conséquent, lorsque j'utilise le schéma de la plus petite base de données, je n'ai aucun moyen de savoir comment tous les enregistrements des 3 tables appartiennent ensemble.
Je pensais insérer un GUIG pour servir de clé primaire que je peux ajouter aux tables et insérer lorsque j'insère toutes les nouvelles données.
Cependant, je suis leyery d'utiliser un champ de char (utilisé pour stocker le GUID) comme une clé. Est-ce une préoccupation valable ou utilise-t-elle un champ de caractère sachant que ce sera toujours une solution suffisante? Quelqu'un peut-il recommander une meilleure approche?
merci
4 Réponses :
Je suis désolé Je ne suis pas familier à 100% avec MySQL, dans SQL Express, il existe un type d'identifiant unique que vous pouvez définir une colonne sur laquelle est vraiment un GUID. Vous pouvez même la mettre à l'auto-numéro lui-même afin qu'il choisit des aléatoires.
Mon patron au travail déteste cependant, et nous travaillons beaucoup avec des systèmes hors ligne / en ligne, il est donc proposé avec un autre système dans lequel chaque base de données d'alimentation On a assigné un identifiant (appelé Dept), et chaque fois qu'il insère dans la table principale de l'un des plus petits, il écrit son département dans une colonne entière séparée de sorte qu'elle est facilement trieuse.
Pour implémenter cela, vous feriez une deuxième touche (faisant chaque table que l'importation doit être effectuée sur une table double clé).
Exemple:
Je n'ai pas vu de type d'identifiant unique dans MySQL, mais je vais vérifier à nouveau. J'ai également pensé à faire quelque chose avec la date - éventuellement la convertir en un entier ou une chose de cette nature. C'est une bonne idée, cependant, les DBS que je me nourrissons sont identifiés par un nombre aléatoire à 4 chiffres. Je pense que la probabilité d'y avoir un duplicata est trop pour moi.
N'utilisez pas leur numéro à 4 chiffres, attribuez-leur l'une de vos propres. Si vous devez, prenez le max (Dept) + 1, et insérez tout avec ce numéro.
Certains dB comme MS SQL Server fournissent un type de données GUID, je ne suis pas sûr de MySQL.
En général, le numéro n'est pas un problème de char ou de Varchar comme clé primaire à moins qu'ils ne soient trop longs. Normalement, les entiers sont préférés car ils sont un peu plus rapides, mais cela dépend si cela compte beaucoup. P>
efficacement, vous pouvez également utiliser une clé primaire composite. Un composant pourrait être votre clé primaire d'origine unique dans une DB uniquement. Le deuxième composant pourrait être le numéro de la base de données, si vous êtes capable d'affecter un numéro unique à chaque base de données. P>
Vous pouvez également utiliser le schéma suivant: P>
int newId = dbNumber * 10000 + iDInSmallDb;
MySQL ne fournit pas de type GUID / UUID, vous devez donc générer la clé dans le code que vous utilisez pour insérer des lignes dans la DB. A Char (32) ou CHAR (36) (Si y compris les traits d'union) est le meilleur type de données pour stocker un GUID au lieu d'un type de données GUID réelle.
Si vous ne voulez pas générer le GUID par votre code, définissez la valeur par défaut sur UUID ()! Des trucs assez géniaux merci gars!