J'ai principalement travaillé dans le développement d'applications métier et la gestion de configuration. Votre question est représentative des défis dans un tel environnement ; lorsque vous mettez à niveau par exemple Microsoft Word, vous n'avez pas besoin de changer tous les documents immédiatement de doc à docx. Et les documents ont même une structure plus simple une base de données complète de relations.
Ce n'est pas le cas pour les applications métier ; les utilisateurs ignorent les versions, apportent des modifications non autorisées au modèle de données et le système doit continuer à fonctionner et fournir les bons chiffres...
Nous utilisons pour nos propres applications (la plus grande est comme 600 tables) un outil CASE auto-développé qui inclut la création de branches/fusion, mais l'approche peut également être effectuée manuellement.
Version du modèle de données
Le modèle de données peut être écrit de manière structurée. Par exemple en tant que contenu de table (CSV à charger dans une table avec des métadonnées) ou en tant que code qui détecte la version utilisée et ajoute des colonnes et des tables lorsqu'elles sont manquantes, y compris les migrations non triviales.
Cela permet même à plusieurs utilisateurs en même temps de modifier le modèle de données.
Lorsque vous utilisez la détection automatique (par exemple, nous utilisons un appel nommé "verify_column" au lieu de "add_column"), cela permet même une migration fluide indépendamment du numéro de version à partir duquel le client démarre la mise à niveau. Une telle procédure analyse la table à modifier et émet le DDL correct tel que alter table t1 add col1 number not null lorsqu'une colonne est manquante ou alter table t1 modify col1 not null lorsque la colonne était déjà présente mais nullable.
Pour Oracle et SQL Server, je peux vous fournir quelques exemples de procédures. Dans MySQL, je coderais cela en utilisant un langage côté client, de préférence indépendant du système d'exploitation pour permettre aux installations de s'exécuter sur Windows et Linux. Peut-être utiliser Apache Ant lorsque vous en aurez l'expérience.
Versionnement des données
Nous avons divisé les tableaux en quatre catégories :
- R :données de référence ; données que le site d'application doit fournir avant d'utiliser réellement le système. Par exemple, les codes de compte du grand livre. Les données de référence changent rarement après la mise en ligne et ne grossissent pas continuellement. Le contenu reflète le modèle commercial du site où l'application est utilisée.
- T :données de transaction ; données que le site enregistre, modifie et supprime lors de l'utilisation de l'application. Par exemple, les écritures du grand livre. Les données de transaction commencent à 0 et augmentent continuellement. Lorsque l'entreprise double ses revenus, les données de transaction doublent également.
- S :données prédéfinies ; données NON conservées par l'utilisateur sur le site mais fournies et conservées par le développeur. Il s'agit essentiellement de code transformé en données. Par exemple, 'F' signifie 'Femme'. Des erreurs dans les données prédéfinies peuvent entraîner des erreurs système.
- O :le reste (idéalement pas nécessaire, car ils sont techniques, mais certains systèmes nécessitent une table temporaire A ou une table de travail B).
Le contenu des tables de la catégorie 'S' (données ensemencées) est placé sous contrôle de version. Nous les enregistrons normalement en tant que métadonnées dans notre outil de cas, puis nommés "ensembles de données", mais vous pouvez également utiliser par exemple Microsoft Excel ou même du code.
Par exemple, dans Excel, vous auriez une liste de lignes de données prédéfinies. Dans la colonne A, vous pouvez saisir une fonction Excel telle que =B..&"|"&C..& "|" & ... qui concatène tout et le rend adapté au chargement par un outil de chargement.
Par exemple, dans le code, vous pourriez avoir un appel comme :
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel est un peu difficile à mettre sous contrôle de version permettant à plusieurs utilisateurs de modifier le contenu en même temps. L'approche avec le code est très simple.
N'oubliez pas d'ajouter également des fonctionnalités pour supprimer les données prédéfinies obsolètes. Par exemple, en répertoriant explicitement les données prédéfinies obsolètes ou en supprimant automatiquement toutes les données prédéfinies présentes dans les tables mais non touchées par la dernière installation.
