Discussion :

[SQLpro]

Ok je veux bien reconnaitre que le sysobjet et ses amis permettent de vérifier pas mal de choses.

[...]
Un jour, la règle métier change avec un motif légal qui fait que n attributs de l'entité existent sur une plage de date valide. Cette règle spécifie un moyen de déterminer à J+3 les nouvelles données, sachant qu'il faut que chaque règle métier soit modifiée de façon à tenir compte des nouveaux attributs, correctement inscrits dans le temps.
Naturellement, il existe aussi une relation fonctionnelle avec d'autres éléments.

Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?

1) il suffit de regarder les impacts d'un changement d'objet sur l'existant à l'aide des méta données de la table.
Exemple (Microsoft SQL Server) : vue sys.sql_expression_dependencies qui tient à jour les informations croisées des objets de la base en permanence (cette vue propre à SQL Server existe dans d'autres SGBDR sous d'autres noms)
Voire aussi :
sys.dm_sql_referenced_entities
sys.dm_sql_referencing_entities

Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)

2) Il existe des outils pour ce faire.

Personnellement j'utilise Power AMC Designer qui permet de faire des scripts de mise à jour et d'archiver des modèles de base entre toutes les combinaisons de versions.

Autres produits : Win Design, Rational Rose....

A +

[Serguei_TARASSOV]

Je suis plutôt d'accord avec Frédéric.
Techniquement, il n'y a que 2 raisons pour "NoSQL" :
1. SGBD spécifique est nécessaire (bien évidemment que SGBDR existantes ont été mis en examens avant)
2. Incompétence sur SGBD et notamment sur SQL sans vouloir/possibilité en monter