Quelle est la meilleure stratégie pour générer des identifiants de base de données? Utiliser des générateurs de base de données? Utilisation d'un générateur personnalisé? Quels sont les avantages et les inconvénients de chacun?
3 Réponses :
Générateur DB:
Générateur d'identification de l'application
[EDIT] Etant donné que les uuids sont assez chers (aucun support natif dans de nombreux DBS, la fragmentation d'index, etc.), la plupart des applications utilisent un générateur basé sur la base de données.
Merci pour cette liste. Existe-t-il une bonnes pratiques pour placer le générateur d'identification? Le générateur de DB me semble plus facile.
Voir mes modifications. Sauf si vous écrivez un logiciel de clustering, le générateur est généralement dans la DB.
J'aime cette réponse le plus, car sa liste simple avec des points importants que vous devez envisager. Merci!
La fonction de DB pour attribuer des IDS (E.G. Identity) peut ne pas fournir de numéros contigus (E.G. Si l'insertion est roulée), un point parfois négligé. Si utilisé pour attribuer des numéros de facturation; Bien sûr, vous pouvez écrire votre propre fonction génératrice d'identification :)
Une autre chose à retenir est que tous les insertions de bases de données ne proviennent pas de l'application. Pour utiliser une adresse GUID sur la demande, vous ferez vraiment mal à vous faire mal lorsque vous obtenez un nouveau client et que vous devez migrer 100 000 enregistrements de leur dernier fournisseur.
Je suis désolé de ne pas avoir le point de votre réponse. Quelqu'un peut-il effacer cela s'il vous plaît?
Le point est que vous mettez vos données à risque si vous générez l'identifiant n'importe où sauf la base de données.
+1, selon votre réglage et combien de systèmes différents vous interagissez, il peut ne pas être possible de garantir que tous les enregistrements de votre base de données seront générés dans votre application. Vous pouvez être nécessaire à un moment donné à l'avenir pour intégrer des données à partir d'une source externe, soit comme une migration ponctuelle (comme le suggère HLGEM) ou dans le cadre d'un processus de charge par lots. Dans les deux cas, il serait beaucoup plus difficile de charger ces enregistrements si votre identifiant provient de l'application. Vous pourriez avoir un service Web ou un autre type d'API, mais cela aurait un impact sur la performance.
Il est possible que vous choisissiez la section "possède" la base de données, donc si vous souhaitez y insérer quelque chose dans lequel vous devez utiliser l'application.
@Themuffinman, c'est une chose particulièrement mauvaise à faire si vous avez besoin de faire des importations de données. Je n'importe pas un million de recrges une à la fois par une demande à un coût de verrouillage de mon système pendant plusieurs jours. Ce que vous suggérez n'est pas pratique pour la plupart des grandes applications métier. Il y a de vraies raisons pour lesquelles vous ne pouvez pas et ne doit pas utiliser l'application pour tout.
C'est un problème, mais je ne suis pas une question pertinente. La plupart des gens utilisent un algorithme standardisé pour la génération d'identité implémentée par les DMB et l'application, comme GUID. Tous les DBMS offrent des moyens de générer des GUID de scripts SQL ces jours-ci. Si vous vous souciez de la performance de l'importation de données (qui est généralement une opération ponctuelle, programmée pour fonctionner sur de faibles périodes d'utilisation, de sorte que les performances sont rarement importantes) Certains SGMS offrent même des moyens de générer des guidages séquentiels à partir de scripts. Votre index n'a donc pas t être fragmenté. Vous pouvez également implémenter l'algorithme dans une procédure stockée ou utiliser des API d'extensibilité de DMBS.
@ygorMutti, je gère chaque quotidiennement les importations de données de la mulitmillion des données, donc non, ce n'est pas rare dans un environnement d'entreprise. Je suis payé pour prendre soin de la performance des importations de données, de même que de nombreuses autres personnes depuis ma spécialité une chaude en ce moment. Une équipe d'application a essayé de nous faire utiliser un service Web conçu pour une entrée de données individuelle sur le site Web pour la création de nouveaux profils et nous avons dû l'arrêter après avoir enfreint l'ensemble du système pendant 18 heures et ne pas être presque terminé.
Je pense que la chose la plus importante est que vous choisissez quelque chose qui peut être utilement utilisé par votre entreprise comme identifiant. Par exemple, le DMV met votre numéro de licence directement sur la carte, et si vous oubliez votre portefeuille et que vous vous souviendrez du nombre, il peut être utilisé pour vérifier votre identité (par exemple, lorsqu'il est tiré sur un policier). Vous ne mettriez pas d'UUID sur une carte.
Cacher des identifiants de votre entreprise est susceptible de causer beaucoup de confusion, alors choisissez quelque chose que vous ne voudriez que dire à un client, à un client ou à un partenaire commercial. Je ne dis pas que tout le monde devrait pouvoir la mémoriser, mais vous devriez au moins être capable de le lire à quelqu'un par téléphone si vous envisagez un reçu (par exemple).
Il existe des exceptions pour la performance, bien sûr, mais celles-ci doivent être utilisées avec soin et non confondues avec un identifiant visible d'entreprise.
Voir mon Publication du blog
S'il vous plaît ne mélangez pas les clés de l'entreprise et les clés techniques. Les identificateurs sont des clés techniques pour identifier de manière unique un objet (par exemple dans les clés étrangères). Ils jouent bien avec des index, ils sont petits et cohérents d'une manière ou d'une autre. Les touches commerciales (comme le numéro de licence) sont ce que vous présentez à l'extérieur, mais car ils ne sont pas fiables (ils peuvent changer de quelque manière que ce soit et suivent la réalité, pas les règles), vous ne devez pas en dépendre d'eux comme des clés primaires. Pensez le nom: Votre nom peut changer lorsque vous vous marierez. Ou vous pouvez avoir deux "John Smith" avec la même date de naissance de votre base de données.
@Aaron: "Veuillez ne pas mélanger les clés de l'entreprise et les clés techniques." Je ne les ai pas confondus, j'ai spécifiquement abordé la différence. @Aaron: "Demandez à deux John Smith avec la même date de naissance", c'est une raison d'inventionner un nouvel identifiant, pas une raison technique.