Ce que vous avez semble être plutôt bon. Mon entreprise a parfois, pour des bases de données suffisamment volumineuses, décomposé encore plus, peut-être au niveau de l'objet individuel. Ainsi chaque table/index/... a son propre fichier. Peut être utile, peut être exagéré. Cela dépend vraiment de la façon dont vous l'utilisez.

@Justine

Par domaine est généralement toujours suffisant. Je suis d'accord qu'il y a certaines complexités à gérer en procédant de cette façon, mais cela devrait être assez facile à gérer.

Je pense que cette méthode fournit un peu plus de séparation (ce que vous apprécierez dans une grande base de données) tout en restant assez gérable. Nous écrivons également des scripts Perl qui effectuent une grande partie du traitement de ces fichiers DDL, ce qui pourrait être une bonne façon de gérer cela.

@Adam

Ou que diriez-vous simplement par domaine -- un regroupement utile de tables liées dans le même fichier, mais séparé du reste ?

Le seul problème est que certains domaines (dans ce système quelque peu hérité) sont étroitement couplés. De plus, vous devez maintenir les dépendances entre vos différents sous-scripts.

Si vous recherchez un outil d'automatisation, j'ai souvent travaillé avec EMS SQLManager, qui permet de générer automatiquement un script ddl à partir d'une base de données.

Les insertions de données dans les tables de référence peuvent être obligatoires avant de mettre votre base de données en ligne. Cela peut même être considéré comme faisant partie du script ddl. EMS peut également générer des scripts pour les insertions de données à partir de bases de données existantes.

Le besoin d'index peut ne pas être correctement estimé à l'étape ddl. Vous aurez juste besoin de les déclarer pour les clés primaires/étrangères. D'autres index devraient être créés ultérieurement, une fois les vues et les requêtes définies