ID de base de données par défaut ;valeurs du système et de l'utilisateur

Question

Dans le cadre de notre travail actuel sur les bases de données, nous étudions le processus de mise à jour des bases de données.

Un point qui a été évoqué de manière récurrente est celui de la confrontation entre système et système.valeurs de l'utilisateur ;dans notre projet, les valeurs utilisateur et système sont stockées ensemble.Par exemple...

Nous avons une liste de modèles.

1, <system template>

2, <system template>

3, <system template>

Ceux-ci sont mappés dans l'application à une énumération (1, 2, 3)

Ensuite, un utilisateur entre et ajoute...

4, <user template>

...et...

5, <user template>

Alors..nous émettons une mise à niveau..et insérer dans le cadre de nos scripts de mise à niveau...

<new id> [6], <new system template>

ALORS!!...nous trouvons un bug dans le nouveau modèle système et devons le mettre à jour...Le problème est comment ?Nous ne pouvons pas mettre à jour l'enregistrement en utilisant ID6 (car nous l'avons peut-être inséré sous la forme 9 ou 999, nous devons donc identifier l'enregistrement à l'aide d'un autre mécanisme)

Nous sommes donc arrivés à deux solutions possibles pour cela.

Dans le coin rouge (vitesse)....

Nous commençons simplement les identifiants utilisateur à 5 000 (ou une autre valeur) et testons les données à 10 000 (ou une autre valeur).Cela nous permettrait d'apporter des modifications aux valeurs du système et de les tester jusqu'à la limite inférieure de la plage d'ID suivante.

Avantage...Rapide et simple à mettre en œuvre,

Désavantage...nous pourrions manquer de valeurs si nous ne choisissons pas une plage suffisamment grande !

Dans le coin bleu (évolutivité)...

Nous stockons les données système et utilisateur séparément, utilisons les GUID comme identifiants et fusionnons les deux listes à l'aide d'une vue.

Avantage...Évolutif..Aucune limite en ce qui concerne la taille de la base de données.

Désavantage..Plus compliqué à mettre en œuvre.(plusieurs à une vue actualisable, etc.)

---

Je opte carrément pour la première option, mais je cherche des munitions pour me soutenir !

Quelqu'un a-t-il des idées sur ces approches, ou même sur une ou plusieurs que nous avons manquées ?

Answer 1

Je n'ai jamais eu de problèmes (performances ou développement - TDD et tests unitaires inclus) en utilisant les GUID comme ID pour mes bases de données, et j'ai travaillé sur des bases de données assez importantes.Regarde ici, ici et ici si vous souhaitez en savoir plus sur l'utilisation des GUID (et des GOTCHAS potentiels impliqués) comme clés primaires - mais je ne saurais trop le recommander car déplacer des données en toute sécurité et la synchronisation de la base de données devient aussi simple que de se brosser les dents le matin : -)

Pour votre question ci-dessus, je recommanderais soit une troisième colonne (si possible) qui indique si le modèle est basé sur l'utilisateur ou le système, soit vous pouvez au moins générer des GUID pour les modèles système au fur et à mesure que vous les insérez et conserver une liste de ceux disponibles, de sorte que si vous devez mettre à jour le modèle, vous pouvez simplement cibler ce même GUID dans vos bases de données DEV, UAT et/ou PRODUCTION sans craindre d'écraser d'autres modèles.La troisième colonne serait cependant utile pour sélectionner à volonté tous les modèles système ou utilisateur, sans avoir besoin de les séparer en deux tableaux (c'est excessif à mon humble avis).

J'espère que cela aide,

Rob G.

Answer 2

Je recommande d'utiliser le second avec la modification que vous stockez les valeurs système et utilisateur dans une seule table.Le GUID est assez fiable de cette manière.

Une autre idée:utilisez n'importe quel ID textuel (pas nécessaire GUID), que vous donnez pour les valeurs système et qui est généré par une chaîne aléatoire ou une chaîne basée sur une sorte de logique personnalisée pour les valeurs utilisateur.

Une autre idée:utilisez la première approche, mais étendez le tableau avec un indicateur qui indique si une valeur est système ou utilisateur.C'est peut-être le plus simple.Ok, vous devez écrire une sorte de mécanisme pour mettre à jour la valeur système correcte, mais cela peut être fait facilement.

Answer 3

+1 pour l'ID basé sur le texte de Biri - définissez une colonne basée sur le texte "template_mnemonic" et faites-en la clé primaire.Ce sera une valeur connue lorsque vous l'insérerez comme vous, les développeurs l'auront décidé (ou l'auront généré automatiquement) et vous pourrez toujours référencer un modèle par son mnémonique quel que soit le nombre de modèles spécifiés par l'utilisateur.Cela permet également aux utilisateurs d'avoir une convention de dénomination significative pour leurs modèles.

Answer 4

Peut-être que je n'ai pas compris, mais ne pourriez-vous pas utiliser les GUID comme identifiants tout en conservant les données utilisateur et système ensemble ?Ensuite, vous pouvez accéder aux données système via les GUID (non modifiables).

Answer 5

Je ne pense pas que le GUID devrait poser un problème.

Si vous voulez l'éviter, utilisez un indicateur :

ID entier

modèle peu importe

drapeau énumération/int/bool

L'indicateur indique si la valeur réelle est une valeur système ou une valeur utilisateur.

Si vous souhaitez mettre à jour une valeur système, demandez uniquement les valeurs système classées par ID, et cela vous montrera l'ordre réel d'insertion (vous devriez avoir un bigint ou quelque chose pour ID pour vous assurer qu'il ne soit pas plein et cela ne remet pas les identifiants supprimés au travail).Avec cette liste, le x.l'enregistrement est le x.valeur système insérée.

Answer 6

Je pense qu'il existe une meilleure troisième solution.Il me semble que vous stockez deux choses différentes dans la même table et qu'il serait peut-être préférable de créer 2 tables distinctes, une pour les modèles utilisateur et une pour les modèles système.Vous pourrez alors peut-être créer une vue sur les deux tables pour les faire apparaître comme un objet unique dans votre application.Évidemment, je n'ai pas une connaissance complète de votre application et cela peut vous être impossible pour un certain nombre de raisons, mais je pense que c'est une solution plus intéressante que les GUID et bien plus sûre que les plages d'ID (sérieusement, ne faites pas de plages d'ID, cela va te mordre un jour)