Discussion :

[finiderire]

Bonjour,

Je génère un script SQL par SGBD / Générer la base de données puis lorsque je fais SGBD / Exécuter SQL voici le message d'erreur que j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ERROR: cannot drop table matable because other objects depend on it
SQLSTATE = S1000

Comment faire pour générer des commandes DROP CASCADE au lieu de DROP ?

a+, =)
-=Finiderire=-

PowerAMC v11.0.0.1363
PostgreSQL v7.4
Windows XP Pro SP2

[fsmrel]

Delete et Drop ne sont pas la même chose. On peut choisir de supprimer en cascade des lignes dans ses propres tables (delete), mais un restrict en queue de chaîne peut invalider l'opération, parce qu'on en a décidé ainsi. Au niveau de la métabase, c'est-à-dire du catalogue relationnel, on ne peut pas choisir entre cascade et restrict (qui est la règle) on doit commencer par supprimer les objets dont ne dépendent pas d'autres objets (tout du moins tant que le SGBD décide qu'il en est ainsi : je ne connais pas PostgreSQL, mais manifestement il réagit normalement... et sainement : imaginez qu'un Drop d'une table anodine de 3 lignes déclenche en cascade la destruction totale de 1000 tables de 500 000 000 de lignes chacune...)

Vous me direz que vous n'en êtes qu'au stade de la génération de la base de données, mais qu'en sait le SGBD ?

[finiderire]

Bonsoir,

Bizarre cet argument. Un traumatisme lié à la perte d'une base de données ? Car vu comme ça il faudrait supprimer la commande DROP du langage SQL on serait sûr de ne rien perdre.
Je ne demande pas à un outil de penser à ma place mais de me permettre de mieux penser. Je comprend qu'il y ai des règles sûres par défaut mais de là à passer outre des fonctionnalités...
En tous cas si j'ai bien compris la réponse est Non.

a+, =)
-=Finiderire=-

[fsmrel]

Mon argument est en partie lié à la manipulation depuis 20 ans de grandes bases de données relationnelles en production, avec en face des gens très pointilleux quant à la sécurité et à l’intégrité de leurs données. On sort des cas d’école.

Maintenant, en général, une fonction a son inverse. De la même façon puisqu’il existe la fonction Create Table (ou trigger ou index, j’en passe et des meilleures), il doit exister la fonction Drop Table, sinon, au bout de 10 ans, une base de données serait un immense cimetière de tables vidées de leur contenu (par Delete) perturbant les tables vivantes. D’un autre côté, ceux qui développent les SGBDR ont une certaine expérience et savent quels risques on pourrait encourir à permettre des DROP en cascade de tables (ce qui techniquement ne poserait pas de problème). Mettez-vous un instant à leur place et faites le tour complet des conséquences de tels drops. Quand vous aurez 10 ans d’expérience en tant que DBA, responsable de bases de données de plus de 1000 tables comprenant des centaines de millions de lignes, vous comprendrez leur prudence (et bien avant, j’espère !) Qu’un drop de table entraîne un drop d’index, ça n’est pas un problème, mais qu’un drop de table entraîne un drop d’autres tables, imaginez les conséquences si vous vous êtes trompé. Ce que vous pensez être une fonctionnalité est en fait de la dynamite et tout le monde n’est pas artificier, ça vous pète en pleine figure avant que vous ayez compris pourquoi. Ceci explique cela. En tout cas, l’absence de Drop en cascade vous aidera à mieux penser, c'est-à-dire à déclencher les drops selon une séquence rationnelle, en fonction de l’architecture de votre base de données. Et à l’occasion, développez un petit programme récursif vous permettant de savoir par quel Drop Table commencer.

[finiderire]

Bonjour,

Merci, je met en car j'ai ma réponse.

a+, =)
-=Finiderire=-