Méthode : un fichier par table ? [Résolu]

[developman]

reBonjour j'ai une question encore qui me taraude
a ce propos nuke_y j'ai une question:
En cour de bases de données je suis un T.P. sous oracle avec unix:
-l'un des profs me dit qu'il faut créer chaque table séparément les un des autres genre si j'ai 4 tables il faut créer 4 fichiers différents pour mieux repérer les érreurs s'il y en a.
Puis faire un fichier ".sql" pour des alter table pour rajouter les contraintes genre:un attribut en "not null" ect...
-Mais un autre prof quelques jour après me dit qu'il faut faire simple et créer qu'un seul fichier avec toutes les tables en même temps ainsi que toutes les contraintes ect....
qu'en pense tu?
Merci d'avance

[SheikYerbouti]

Pas terrible comme titre...

Je partage parfaitement l'avis de votre premier prof.
On créé d'abord toutes les tables, puis on ajoute les contraintes et les indexes.
Comme cela vous être certain, par example, de créer un clé étrangère lorsque la table cible existe.
Imaginez le message d'erreur si vous créez cette foreign key en même temps que la table, alors la table cible n'a pas encore été créée...

[nuke_y]

Je suis d'accord aussi, 1 seul fichier c'est plus simple mais si une erreur a lieu à la première instruction, les autres se déroulent sans qu'on puisse les arrêter (à part un kill sauvage).

De plus ça apprend à diviser les modifications par lots.

[developman]

D'accord alors je récapitule:
-Créer les tables avec les clés primaires mais sans les clés étrangères
-Créer ensuite les clés étrangères
-Puis les nom des contraintes pour pouvoir repérer les erreurs s'il y en as
-Enfin créer les requêtes.
Et pour chaque créer un nouveau fichier sql.

Est ce comme cela qu'il faut procéder?

[Wurlitzer]

Envoyé par nuke_y

Je suis d'accord aussi, 1 seul fichier c'est plus simple mais si une erreur a lieu à la première instruction, les autres se déroulent sans qu'on puisse les arrêter (à part un kill sauvage).

Oui enfin le problème si on a plusieurs fichiers c'est d'oublier d'en passer 1. Ce qui est moins visible que 10 erreurs.....

[orafrance]

oui enfin tu peux être rigoureux aussi

[Yorglaa]

Envoyé par developman

...
Puis faire un fichier ".sql" pour des alter table pour rajouter les contraintes genre:un attribut en "not null" etc...

Perso je dirais que je gère tout de même les NOT NULL dans le premier fichier, c'est à dire lors de la création de la table.

suivant le nb de tables et le nb d'attributs par table, il est facile d'en manquer un ensuite. Pour des "contraintes" de type NOT NULL je trouve plus simple de les intégrer, au niveau de la réflexion déjà, au moment de la création de la table.
Rien n'empêche de modifier qqchose ensuite d'ailleurs.

[nuke_y]

Remarque intéressante de Wurlitzer. Si ça t'embête moins d'avoir un seul fichier que de risquer d'en oublier un, alors n'hésite pas.

L'idéal dans ce cas étant d'avoir plusieurs fichiers ET un script qui les lance tous (comme ça tu peux les lancer un par un ou tous à la suite si vraiment tu es sûr de toi).

De plus je fais toujours des scripts de rollback qui me permettent en un script d'annuler ce que j'ai fais et de revenir exactement dans la configuration précédente. De plus ça t'oblige à être plus rigoureux et ça t'évite "d'oublier" des objets.

[developman]

Merci pour vos remarques toutes intéressantes,
je crois que je vais opter pour le fichier unique avec les "not null" et faire ensuite les contraintes.
@+