La vérification d'une base de données est conforme à vos attentes

StackOverflow https://stackoverflow.com/questions/495376

Question

J'ai écrit une application java sur ma machine et celle-ci fonctionne parfaitement avec la base de données que j'ai configurée, mais lorsque je l'installe sur le site, elle explose car la base de données est légèrement différente.

Je suis donc en train d'écrire du code pour vérifier que:

  • A: Les détails de la base de données sont corrects

  • B: La base de données contient toutes les tables que j'attends et les bonnes colonnes.

J'ai A mais je ne sais pas par où commencer avec B, des suggestions?

La base de données cible pour le client actuel est Oracle, mais l'application peut également être configurée pour s'exécuter sur SQL Server. Donc, une solution générique serait appréciée, mais ce n’est pas nécéssaire, car je suis sûr de pouvoir comprendre comment utiliser l’un l’autre.

Était-ce utile?

La solution

Vous voudrez interroger le information_schema de la base de données, voici quelques exemples pour Oracle, chaque plate-forme que je connais possède quelque chose de similaire.

http://www.alberton.info/oracle_meta_info.html

Autres conseils

Vous pourrez peut-être utiliser un outil de migration de base de données tel que LiquiBase - la plupart de ces outils permettent de vérifier la base de données. Je n'ai pas l'expérience de première main de l'utiliser, donc c'est une supposition.

J'utilise DbUnit pour tester les bases de données. Il s’agit d’une solution basée sur Java qui s’intègre parfaitement à Junit . Il est possible de l'utiliser avec presque pas de Java. Je ne l'ai pas utilisé exactement dans la même situation que celle que vous avez décrite, mais il devrait être suffisamment proche pour fonctionner.

La solution la plus générique consisterait à exécuter des requêtes avec une clause select ayant les couleurs attendues et une clause from ayant des noms de table, dans le bloc try catch. Vous pouvez mettre la clause where sous la forme 1 = 2 afin de ne pas extraire de données. Si la requête est exécutée sans exception, vous disposez de la table et des colonnes attendues.

La pièce légèrement différente pourrait être mieux gérée en scriptant la création de la base de données en premier lieu. Un processus automatisé vous donne une meilleure chance de rendre les deux identiques.

Un autre point intéressant est que vous réduisez vos risques en rendant vos environnements devl et prod identiques - le même schéma de base de données et le même fournisseur pour les deux. Modifiez les circonstances qui différencient les deux.

Enfin, vous ne dites pas ce qui est & "légèrement &"; différentes, mais elles sont parfois inévitables (par exemple, Oracle utilise des séquences, SQL Server utilise des identités). Peut-être qu'Hibernate peut vous aider à changer de fournisseur de manière plus fiable. Il résume les détails de telle sorte que changer de base de données peut signifier modifier une seule valeur dans un fichier de configuration.

Ce dont vous avez besoin, ce sont essentiellement des tests unitaires pour votre base de données. " Une colonne doit exister nommée FOOBAR, le type doit être Integer. Aucune clé étrangère ne peut exister, etc. & ";

C’est faisable avec JUnit et JDBC (demandez à la table ses métadonnées), car vous voudrez peut-être vous assurer que vous êtes absolument certain de ce qui est fait, ce qui peut être plus difficile lors de l’utilisation, par exemple. dbUnit.

Vous pouvez vérifier la présence de tables, de colonnes, de vues, etc. à l'aide de ces tables dans Oracle

USER_TABLES USER_VIEWS USER_PROCEDURE

(ou pour tout) USER_OBJECTS WHERE OBJECT_TYPE = '??'

Pour continuer ... USER_TAB_COLS pour les colonnes de table

Cordialement K

J'utilise MigrateDB pour cela. Il vous permet de créer des requêtes qui vérifient, par exemple, l'existence de tables, colonnes, lignes, index, etc. donnés pour une base de données donnée et les utilisent comme & Quot; tests. & Quot; Si un test échoue, il déclenche une & Action; & Quot; (qui est juste une autre requête qui sait comment résoudre le problème.)

MigrateDB prend en charge plusieurs plates-formes de base de données (vous pouvez spécifier la " vérification de la requête d’existence de table & "; pour chaque plate-forme, par exemple), des tests entièrement configurables (vous pouvez créer votre propre système), est livré avec des tests Oracle assez complets et pouvant être exécutés dans " audit seulement " mode pour qu'il ne vous dise que les différences.

C'est une belle solution robuste.

Non affilié à StackOverflow
scroll top