J'ai hérité de la tâche de maintenir un site de commerce électronique très mal codé et je travaille à refactoriser beaucoup de code et à essayer de réparer les bugs en cours.
Chaque insertion de base de données (l'ajout d'un élément au panier, etc.) commence par une fonction GRAB_New_ID qui compte le nombre de lignes dans la table, puis commençant par ce numéro, interroge la base de données pour trouver un numéro d'index inutilisé. En plus d'être terrible performance-sage (il y a déjà plus de 40 000 lignes déjà, et les index sont régulièrement supprimés, il faut donc parfois plusieurs secondes simplement pour trouver un nouvel identifiant) Ceci rompre régulièrement lorsque deux opérations sont préformées simultanément, comme deux entrées sont ajoutées. avec des numéros d'identification en double.
Cela semble imbécile pour moi - pourquoi pas simplement utiliser automatiquement l'incrément automatique sur le champ d'index? J'ai testé les deux manières et ajouter des lignes à la table sans spécifier un identifiant d'index est (évidemment) plusieurs fois plus rapidement. Ma question est la suivante: Quelqu'un peut-il penser à une raison quelconque le programmeur d'origine aurait pu faire cela? Y a-t-il une certaine école de pensée où Auto_Increment est en quelque sorte considéré comme une mauvaise forme? Y a-t-il des bases de données qui n'ont pas de capacités d'incrémentation automatique?
8 Réponses :
J'ai vu cela avant de partir de quelqu'un qui ne savait pas cette fonctionnalité existait. Utilisez définitivement la fonction Auto-Incrément.
Certaines personnes prennent l'approche "rouler la vôtre" de tout, souvent parce qu'elles n'ont pas pris le temps de voir si cela est une caractéristique disponible ou si quelqu'un d'autre l'avait déjà arrivé. Vous verrez souvent des solutions de contournement folle ou un code performant / fragile de ces personnes. Hériter d'une mauvaise base de données n'est pas amusant du tout, bonne chance!
Une fois, j'ai rencontré une fonction dans C # appelée Realbooloan. Tout ce que cela a fait était d'accepter un Boolean comme paramètre et retourner l'inverse en conséquence. C'était trop compliqué et tout simplement muet. Tous parce que le développeur n'était pas au courant de la non-opérateur.
Une fois, j'ai déjà vu le code sur chaque requête apportée à une application Web qui oblige tout le trafic à HTTPS si un drapeau était défini dans la base de données. Et cela se battrait avec la manipulation automatique de l'IIS sur HTTPS et créé une boucle de redirection infinie. C'était 2 jours d'awesomesauce avant de découvrir ce qui se passait.
Wtfs ftw! C'est ce que j'ai pensé ... Je voulais juste voir si je risquerais de manquer quelque chose, ou s'il y avait une raison cachée de cette fonction.
Eh bien oracle a des séquences mais pas des identifiants générés automatiquement comme je le comprends. Cependant, généralement ce type de choses se fait par Devs qui ne comprennent pas la programmation de la base de données et qui détestent de voir des lacunes dans les données (comme vous obtenez des retournements). Il existe également des personnes qui aiment créer l'ID, de sorte qu'elles l'ont donc disponible avant d'utiliser des tables d'enfants, mais la plupart des bases de données avec ID autogenéré ont également un moyen de renvoyer cet identifiant à l'utilisateur au moment de la création.
Ils peuvent seulement avoir été inexpérimentés et inconnus avec incrément automatique. Une des raisons que je peux penser, mais elle n'a pas nécessairement de sens, est-ce qu'il est difficile (pas impossible) de copier des données d'un environnement à un autre lors de l'utilisation d'un identifiant d'auto-incrément automatique.
Pour cette raison, j'ai utilisé des GUDS séquentiels comme ma clé principale avant de faciliter les données de transition, mais de compter les lignes pour renseigner l'identifiant est un peu wtf .
Je pouvais voir si les identifiants ont été générés sur le client et poussés dans la base de données, il s'agit d'une pratique courante lorsque la vitesse est nécessaire, mais ce que vous avez décrit semble sur le dessus et inutile. Supprimez-le et démarrez un identifiant d'incrémentation automatique.
Cela a probablement été fait de cette façon pour des raisons historiques; I.E. Les versions antérieures n'ont pas eu de variables d'autoincointes. J'ai écrit du code qui utilise des champs d'autoincication manuelle sur les bases de données qui ne prennent pas en charge les types d'autoincointes, mais mon code n'était pas aussi inefficace que de tirer un compte ().
Un problème avec l'utilisation de champs AutoInc comme une clé primaire est que le déplacement des enregistrements dans et hors des tableaux peut entraîner une modification de la clé principale. Donc, je vous recommanderais de concevoir dans un champ «héritabilité» en haut devant lequel peut être utilisé comme stockage futur pour la clé primaire des temps lorsque vous déplacez des enregistrements dans et hors de la table.
Le seul problème que j'ai trouvé partiellement raisonnable (mais totalement évitable!) contre les champs Auto_Inc est que certains outils de sauvegarde par défaut incluent des valeurs auto_inc dans la définition de tableau même si vous n'incluez pas les données dans une décharge de DB qui peut être gênante.
Selon la situation spécifique, il existe clairement de nombreuses raisons pour ne pas utiliser de nombres consécutifs comme clé primaire.
Toutefois, sous la donnée que je do veut des nombres consécutifs comme clé primaire, je ne vois aucune raison de ne pas utiliser l'intégré auto_incrènement fonctionnalité MySQL offre
Deux choses à regarder pour:
1.votre RDBMS définit intelligemment la valeur d'incrémentation automatique lors du redémarrage. Nos ingénieurs roulaient leur propre clé d'incrémentation automatique pour contourner le champ Auto-Incrément Sauter par une commande de 100 000 à chaque fois que le serveur redémarre. Cependant, à un moment donné, Sybase a ajouté une option pour définir la taille de l'incrément automatique.
2.L'autre endroit où l'incrément automatique peut devenir méchant est si vous répliquez des bases de données et utilisez une configuration maître-maître. Si vous écrivez sur les deux bases de données (non conseillée), vous pouvez rencontrer une collision d'identité.
Je doute que l'un ou l'autre de ceux-ci soit le cas, mais des choses à prendre conscience.