Discussion :

[ganguill]

Bonsoir

Je me pose actuellement une question (à laquelle je pense avoir la réponse), mais je voudrais en avoir la confirmation..!

j'explique très brièvement la situation : je possède une petite application en PHP qui me sert à créer des tables dans une base de données Oracle10g.
Ces tables (8 au total) sont créées par PHP, puis remplies à l'aide d'Sql*Loader (appelé par PHP). En effet, le contenu de mes tables provient exclusivement de données brut contenues dans des fichiers .txt (voilà pourquoi je passe par Sql*Loader).

L'utilisateur est amené à recréer et supprimer ces 8 tables plusieurs fois (parfois 1 fois par jour). L'ancienne table est donc automatiquement supprimée, et la nouvelle est créée puis remplie par Sql*Loader (tout celà automatiquement).

=> Je m'étais débrouillé pour avoir des clés étrangères entre certaines tables.. Seulement je viens de me dire un truc: maintenant que mon application est en place et que l'utilisateur peut supprimer les tables qu'il souhaite dans n'importe quel ordre, ce dernier risque de se retrouver coincé s'il veut supprimer une table reliée à une autre par une clé étrangère!

Voilà ma question (ou plutôt ma supposition) : à votre avis, nous sommes bien d'accord que la création de clés étrangères entre les tables est impossible dans mon cas n'est-ce-pas?

Merci à tous de m'avoir lu

[mnitu]

...
L'utilisateur est amené à recréer et supprimer ces 8 tables plusieurs fois (parfois 1 fois par jour). L'ancienne table est donc automatiquement supprimée, et la nouvelle est créée puis remplie par Sql*Loader (tout celà automatiquement).
...

C’est un approché erroné. Utilisez des tables temporaires à la place crées une seule fois à l’installation de l’application. La création d’une table en Oracle est une opération « lourde ».

[Waldar]

Ou même créez vos tables en tant qu'external table et vous n'aurez peut-être plus rien d'autre à faire.

[ganguill]

C’est un approché erroné. Utilisez des tables temporaires à la place crées une seule fois à l’installation de l’application. La création d’une table en Oracle est une opération « lourde ».

A quoi me servirait des tables temporaires? Une table temporaire se détruira une fois la session fermée. Mais parfois certaines tables sont amenées à rester dans la base pendant 2 ou 3 mois sans modifications :/ D'autres le sont plus fréquemment certes, mais certaines non.

Ou même créez vos tables en tant qu'external table et vous n'aurez peut-être plus rien d'autre à faire.

je viens de me renseigner.. Je ne connaissais pas ces tables.. En gros apparamment ça fait ce que fait SQL*loader en beaucoup plus simple.. Mais bon maintenant que j'en ai finit avec Sql*Loader et les configurations nécessaires...


Sinon pour l'histoire de mes clés étrangères, c'est impossible dans mon cas n'est-ce-pas?

Merci à tous pour votre aide

[ganguill]

En fait après avoir regardé de plus prêt, il semblerait que les tables externes sont pratiquement identiques à Sql*Loader (synthaxiquement en tout cas).
Au niveau performance il semblerait que selon les cas ça se vaut plus ou moins.. Mais bon au final le raisonnement est le même (les fichiers de configuration que j'ai avec Sql*Loader sont également obligatoires pour les tables externes).

Ce qui est étonnant c'est que j'ai toujours entendu parler d'Sql*Loader sur internet et jamais de ces fameuses tables externes
Merci en tout cas, ça m'aura appris des choses

[Pomalaix]

Je m'étais débrouillé pour avoir des clés étrangères entre certaines tables.. Seulement je viens de me dire un truc: maintenant que mon application est en place et que l'utilisateur peut supprimer les tables qu'il souhaite dans n'importe quel ordre, ce dernier risque de se retrouver coincé s'il veut supprimer une table reliée à une autre par une clé étrangère!

Je ne peux qu'être d'accord avec Mnitu sur ce point : ce que vous tentez de faire est incohérent.
Il n'est pas normal de supprimer et recréer régulièrement les mêmes tables.
A la rigueur, si vous voulez les vider intégralement, vous avez le TRUNCATE.

Par ailleurs, si vous mettez des clés étrangères, c'est pour renforcer l'intégrité de vos données : ces clés étrangères assurent que les valeurs que vous entrez dans la table T sont valables, car présentes dans une table de référence TR.
Cela induit donc une certaine chronologie des actions : d'abord on insère la donnée de référence dans TR, puis on insère dans T une valeur y faisant référence.
De même, à la suppression des tables, la cohérence impose que vous supprimiez d'abord T, puis TR.

Quand vous dites que l'utilisateur doit pouvoir supprimer les tables dans n'importe quel ordre, c'est une exigence incohérente. Soit ils ne comprennent rien à la logique de leurs données (ce qu'on peut admettre, dans ce cas il faut leur fournir une procédure unique qui se chargera de supprimer les tables dans le bon ordre), soit ils la comprennent et dans ce cas ils doivent accepter l'erreur, soit c'est votre logique qui est mauvaise.
Si vous voulez bénéficier des contrôles effectués par les clés étrangères, il faut accepter la chronologie imposée lors de la suppression des tables, ce que je vous conseille.
Sinon, ne mettez pas de clés étrangères, ce qui vous permettra de supprimer vos tables n'importe comment, mais acceptez aussi les incohérences potentielles dans vos données !

Après, il reste la solution malpropre qui permet de supprimer une table brutalement en supprimant les clés étrangères qui y feraient référence :

Code :

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

DROP TABLE TR CASCADE CONSTRAINTS;

Concernant les tables temporaires suggérées par Mnitu, il faut rappeler qu'une table temporaire est une table permanente dont le contenu est temporaire. Ce contenu, dans le meilleur des cas, disparaîtra à la fin de la session, ce qui ne vous convient probablement pas.

[ganguill]

Je ne peux qu'être d'accord avec Mnitu sur ce point : ce que vous tentez de faire est incohérent.
Il n'est pas normal de supprimer et recréer régulièrement les mêmes tables.
A la rigueur, si vous voulez les vider intégralement, vous avez le TRUNCATE.

Je comprends où vous voulez en venir. Ce que je ne comprends pas c'est pourquoi il n'est pas normal de supprimer et de recréer une table? L'opération est instantannée (du moins la suppression), et la ré-insertion d'informations ne prend que quelques minutes (il y a plusieurs millions de lignes à ré-insérer à chaque fois).

Par ailleurs, la logique à suivre lors de la suppression des tables ne peut être appliquée ici... En effet même si celà peut paraître improbable, l'utilisateur doit pouvoir supprimer ces tables pour les recréer, et ce dans n'importe quel ordre et indépendamment des autres (j'entends par là que si l'utilisateur veut supprimer une table T2 référencé par une table T1, on ne doit en aucun cas supprimer ou modifier des valeurs de T1 pour ça)..
Bref le tout est assez problématique.. Au final je me retrouve avec des tables contenant des valeurs qui n'apparaissent pas dans d'autres (elles le devraient), mais celà est "normal" d'après l'entreprise..

Enfin bon, c'est sûr que le tout n'est pas très propre, mais je crains de ne pas avoir le choix

[ganguill]

Je tiens à préciser que je ne suis pas contre le TRUNCATE, mais si je ne l'utilise pas c'est pour une bonne raison : si un jour quelqu'un venait à toucher à la base de données et supprimait une table par mégarde.. Il pourrait toujours la recréer avec le script SQL, mais à la base c'est un utilisateur lambda qui est censé toucher à cette application.. Donc je ne suis pas convaincu qu'il serait capable de recréer cette table par lui-même.. (même si c'est vrai que ce n'est qu'un script à exécuter)..

[Pomalaix]

Ce n'est pas parce que j'ai décidé de changer tous mes meubles que je dois détruire ma maison, puis la reconstruire, avant d'installer mes nouveaux meubles.

Pourquoi diable voulez-vous supprimer vos tables pour les recréer ensuite ?
Quelle bonne raison avez-vous pour ça ?

Un utilisateur, en temps normal, modifie les données, c'est à dire le contenu des tables, pas la structure. Une application a besoin d'une structure stable, dans laquelle les objets sont connus à l'avance, même si à la rigueur il peuvent être vides de temps en temps.
Si vous supprimez des tables à la volée, vous aurez forcément des fonctionnalités qui, temporairement, seront inaccessibles.

Sur ce point, soyez rassuré :

j'entends par là que si l'utilisateur veut supprimer une table T2 référencé par une table T1, on ne doit en aucun cas supprimer ou modifier des valeurs de T1 pour ça.

Avec la clause CASCADE CONSTRAINTS, on ne touche absolument pas les valeurs de T1. On se contente juste de supprimer la contrainte de clé étrangère (pointant de T1 vers T2) ce que signifie que désormais, on ne veut plus du contrôle de cohérence.

[Pomalaix]

Je tiens à préciser que je ne suis pas contre le TRUNCATE, mais si je ne l'utilise pas c'est pour une bonne raison : si un jour quelqu'un venait à toucher à la base de données et supprimait une table par mégarde.. Il pourrait toujours la recréer avec le script SQL, mais à la base c'est un utilisateur lambda qui est censé toucher à cette application.. Donc je ne suis pas convaincu qu'il serait capable de recréer cette table par lui-même.. (même si c'est vrai que ce n'est qu'un script à exécuter)..

Non, ça n'est absolument pas une bonne raison.
Une base de données Oracle est en principe gérée par un DBA qui garantit, par les sauvegardes, la capacité à obvier aux problèmes matériels et aux erreurs humaines, telles que le suppression de la table par l'abruti de service.

Que vous souhaitiez mettre à disposition un script permettant de recréer les tables, pourquoi pas, mais ça n'en fait pas une raison justifiant de supprimer et recréer ces tables à la volée dans l'usage normal de l'application.

[ganguill]

Ce n'est pas parce que j'ai décidé de changer tous mes meubles que je dois détruire ma maison, puis la reconstruire, avant d'installer mes nouveaux meubles.

A retenir ça
Moi je n'ai rien décidé du tout Mon maître de stage voulait que je fasse ceci, ce que j'ai fait (si je suis venu ici c'est parce qu'en effet je trouve que quelque chose clochait..).
Je vais donc m'arranger pour faire un bon TRUNCATE Si celà me permet d'avoir quelque chose de plus propre alors je le ferai, même si ça me prendra du temps pour modifier mon code
La clause CASCADE CONSTRAINTS est valable avec TRUNCATE?
Quelque chose du genre :

Code :

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

TRUNCATE table t1 CASCADE CONSTRAINTS

Merci beaucoup pour ces précisions

[mnitu]

Quelques petits remarques:

• Il n'est pas possible de mettre des contraintes sur des tables externes
  

  Restrictions on Altering External Tables You can add, drop, or modify the columns of an external table. However, for an external table you cannot:
  
  Add a LONG, LOB, or object type column or change the datatype of an external table column to any of these datatypes.
  
  Add a constraint to an external table.
  
  

• il y des restrictions pour le truncate.
  

  Restrictions on Truncating Tables This statement is subject to the following restrictions:
  
  You cannot individually truncate a table that is part of a cluster. You must either truncate the cluster, delete all rows from the table, or drop and re-create the table.
  
  You cannot truncate the parent table of an enabled foreign key constraint. You must disable the constraint before truncating the table. An exception is that you can truncate the table if the integrity constraint is self-referential.
  
  

D'autre part

...
Donc je ne suis pas convaincu qu'il serait capable de recréer cette table par lui-même.. (même si c'est vrai que ce n'est qu'un script à exécuter

Si vous doutez que les utilisateurs sont capables de récréer les tables alors pourquoi tenez-vous à les détruire ?

[ganguill]

Quelques petits remarques:
Si vous doutez que les utilisateurs sont capables de récréer les tables alors pourquoi tenez-vous à les détruire ?

Je les détruisait pour les recréer directement après
Mon script PHP faisait un "drop...", et directement après exécutait un "create table...".
Du coup ce que je vais faire est un truncate (comme ça je ne m'occupe plus du create ni du drop). En revanche je vais prévoir un petit formulaire pour créer la table choisie au cas où un jour elle venait à être détruite (bien entendu celà n'arrivera probablement pas, et les tables ne seront créées que si elles n'existent pas déjà ).

Par ailleurs, je ne passe pas par des tables externes, mais bien par des tables normales remplies ensuite par Sql*Loader