Tables avec des relations & procédures dynamiques

JustMe · 12/12/2004, 21h42

Est ce qu'il est possible de créer des tables avec les mêmes trigger les mêmes procedures les mêmes relations (avec FireBird) sans a avoir à les réécrire.
exemple :
des magasins pour une gestions des stocks de nouvelles tables pour la même structure les mêmes relations les mêmes procedures et les mêmes triggers.
Merci.

Barbibulle · 13/12/2004, 10h47

Il faut le faire mannuellement.

Si ce n'est pas prévu c'est surtout qu'il est très rare de devoir le faire. Lorsqu'on a des tables identiques ou très semblables, il faut se poser la question si elles ne peuvent pas être fusionnées avec une colonne supplémentaire pour différencier les enregistrement qui auraient été dans la table 1 des enregistrements qui auraient étés dans la table2.

Genre :
Table 1 :ARTICLES_STOCK_MAGASIN1
{ID_ART, LIBELLE, QUANTITE, ... }
Table 2 :ARTICLES_STOCK_MAGASIN2
{ID_ART, LIBELLE, QUANTITE, ... }
N'est pas du tout optimisé et va poser plein de problemes par la suite pour la maintenance et les évolutions de la base.
De plus il sera moins performant et plus difficile de faire des stats sur l'ensemble des magasins. De gérer la création d'un nouveau magasin etc...

Ce qu'il vaut mieux :
Table : MAGASIN
{ID_MAG, NOM}
Table :ARTICLE_STOCK
{ID, FK_ID_MAG, ID_ART, LIBELLE, QUANTITE, ... }
ID étant un numéro unique la clé primaire
FK_ID_MAG une clé étrangère désignant le magasin
ID_ART l'identifiant article (on créera un index non unique sur cette colonne)

Avec cette méthode tout le stock se trouve dans une seule table. On peut très facilement ajouter/supprimer la gestion d'un magasin sans devoir toucher à la structure de la base.

Donc à moins d'avoir une contrainte technique vous obligeant de duppliquer les tables, je vous conseil d'étudier votre modèle de données, pour qu'il colle plus à ce que doit être une base de données relationnelle.

JustMe · 13/12/2004, 22h51

Désolé d'avoir donnée un exemple de stock (tu t'es investis à me le faire comprendre merci

)

En fait mes tables sont des ecritures comptables où chaque tables va représenter un dossier avec un exercice.
Exemple : societe1_2004, societe2_2004, etc...
Et c'est pour des comptables ou il peut avoir des dizaines de dossiers chaque année mais avec quelque tables en commun pour tous les dossiers.
On peut toucher la barre des 500 000 enregistrements chaque année par table si on mettais tous les dossiers ensemble.
C'est pour celà que j'ai penser qu'il fallait mieu les séparer. je ne sais plus maintenant.

Barbibulle · 14/12/2004, 10h21

D'un point de vue analyse il faut toutes les mettres dans la même table.

Cette table aurait bien entendu une colonne "FK_ID_Dossier" (Clé étrangère vers la table des dossiers) qui te permettrait de ne pas mélanger les écritures.

Ou même peut être (si tu n' as pas de table dossier) une colonne FK_ID_SOCIETE et une colonne FK_ID_EXERCICE.

Donc ce qui ferait une table unique avec des triggers et procédures uniques. Bien plus facile à maintenir. L'unicité des informations et traitement c'est un des buts d'une analyse de la création d'une base de données. Cette étape s'appel la normalisation des données.

Après en effet il peut arriver qu'on soit obliger de dénormaliser. Pour réduire ne nombre de table, pour améliorer certains traitements.

La table contiendra 500 000 * 10 dossiers = environ 5 milions d'enregistrement. Ce qui commence à être une quantité respectable. Firebird / Interbase sont tailés pour ce genre de volume mais par contre il faut bien entendu être plus attentif aux traitements, requetes qui vont être effectués sur cette table.

En d'autre terme tant que vous n'avez pas étudié la partie traitement sur cette table il n'y a aucunne raison de l'éclater en plusieures.

Quand vous développerez vos procédures je vous conseil de générer vos 5 millions d'enregistrements afin de mieux apprécier vos optimisations.

JustMe · 14/12/2004, 21h50

Merci.
J'espère de ne pas paniquer avec une telle quantité de données.

Barbibulle · 15/12/2004, 09h58

Commencez par l'analyse de vos besoins en terme de traitements et après vous y verrez plus clair et pourrez décidez des optimisations possibles de la base.
La création d'index en est une mais la séparation des données dans des tables différentes peut en être une autre (un peu extreme à mon sens).

12/12/2004, 21h42	#1
JustMe Membre éprouvé Inscription : juillet 2002 Messages : 432 Détails du profil Informations forums : Inscription : juillet 2002 Messages : 432 Points : 441 Points : 441	Tables avec des relations & procédures dynamiques Est ce qu'il est possible de créer des tables avec les mêmes trigger les mêmes procedures les mêmes relations (avec FireBird) sans a avoir à les réécrire. exemple : des magasins pour une gestions des stocks de nouvelles tables pour la même structure les mêmes relations les mêmes procedures et les mêmes triggers. Merci. __________________ <On fait la science avec des faits, comme on fait une maison avec des pierres : mais une accumulation de faits n'est pas plus une science qu'un tas de pierres n'est une maison> Poincaré http://www.mobile-tactile.com/
	00

13/12/2004, 22h51	#3
JustMe Membre éprouvé Inscription : juillet 2002 Messages : 432 Détails du profil Informations forums : Inscription : juillet 2002 Messages : 432 Points : 441 Points : 441	Désolé d'avoir donnée un exemple de stock (tu t'es investis à me le faire comprendre merci ) En fait mes tables sont des ecritures comptables où chaque tables va représenter un dossier avec un exercice. Exemple : societe1_2004, societe2_2004, etc... Et c'est pour des comptables ou il peut avoir des dizaines de dossiers chaque année mais avec quelque tables en commun pour tous les dossiers. On peut toucher la barre des 500 000 enregistrements chaque année par table si on mettais tous les dossiers ensemble. C'est pour celà que j'ai penser qu'il fallait mieu les séparer. je ne sais plus maintenant. __________________ <On fait la science avec des faits, comme on fait une maison avec des pierres : mais une accumulation de faits n'est pas plus une science qu'un tas de pierres n'est une maison> Poincaré http://www.mobile-tactile.com/
	00

14/12/2004, 21h50	#5
JustMe Membre éprouvé Inscription : juillet 2002 Messages : 432 Détails du profil Informations forums : Inscription : juillet 2002 Messages : 432 Points : 441 Points : 441	Merci. J'espère de ne pas paniquer avec une telle quantité de données. __________________ <On fait la science avec des faits, comme on fait une maison avec des pierres : mais une accumulation de faits n'est pas plus une science qu'un tas de pierres n'est une maison> Poincaré http://www.mobile-tactile.com/
	00

13/12/2004, 10h47	#2
Barbibulle Membre Expert Frédéric Inscription : octobre 2002 Messages : 1 722 Détails du profil Informations personnelles : Nom : Frédéric Âge : 42 Informations forums : Inscription : octobre 2002 Messages : 1 722 Points : 2 025 Points : 2 025	Il faut le faire mannuellement. Si ce n'est pas prévu c'est surtout qu'il est très rare de devoir le faire. Lorsqu'on a des tables identiques ou très semblables, il faut se poser la question si elles ne peuvent pas être fusionnées avec une colonne supplémentaire pour différencier les enregistrement qui auraient été dans la table 1 des enregistrements qui auraient étés dans la table2. Genre : Table 1 :ARTICLES_STOCK_MAGASIN1 {ID_ART, LIBELLE, QUANTITE, ... } Table 2 :ARTICLES_STOCK_MAGASIN2 {ID_ART, LIBELLE, QUANTITE, ... } N'est pas du tout optimisé et va poser plein de problemes par la suite pour la maintenance et les évolutions de la base. De plus il sera moins performant et plus difficile de faire des stats sur l'ensemble des magasins. De gérer la création d'un nouveau magasin etc... Ce qu'il vaut mieux : Table : MAGASIN {ID_MAG, NOM} Table :ARTICLE_STOCK {ID, FK_ID_MAG, ID_ART, LIBELLE, QUANTITE, ... } ID étant un numéro unique la clé primaire FK_ID_MAG une clé étrangère désignant le magasin ID_ART l'identifiant article (on créera un index non unique sur cette colonne) Avec cette méthode tout le stock se trouve dans une seule table. On peut très facilement ajouter/supprimer la gestion d'un magasin sans devoir toucher à la structure de la base. Donc à moins d'avoir une contrainte technique vous obligeant de duppliquer les tables, je vous conseil d'étudier votre modèle de données, pour qu'il colle plus à ce que doit être une base de données relationnelle.
	00

14/12/2004, 10h21	#4
Barbibulle Membre Expert Frédéric Inscription : octobre 2002 Messages : 1 722 Détails du profil Informations personnelles : Nom : Frédéric Âge : 42 Informations forums : Inscription : octobre 2002 Messages : 1 722 Points : 2 025 Points : 2 025	D'un point de vue analyse il faut toutes les mettres dans la même table. Cette table aurait bien entendu une colonne "FK_ID_Dossier" (Clé étrangère vers la table des dossiers) qui te permettrait de ne pas mélanger les écritures. Ou même peut être (si tu n' as pas de table dossier) une colonne FK_ID_SOCIETE et une colonne FK_ID_EXERCICE. Donc ce qui ferait une table unique avec des triggers et procédures uniques. Bien plus facile à maintenir. L'unicité des informations et traitement c'est un des buts d'une analyse de la création d'une base de données. Cette étape s'appel la normalisation des données. Après en effet il peut arriver qu'on soit obliger de dénormaliser. Pour réduire ne nombre de table, pour améliorer certains traitements. La table contiendra 500 000 * 10 dossiers = environ 5 milions d'enregistrement. Ce qui commence à être une quantité respectable. Firebird / Interbase sont tailés pour ce genre de volume mais par contre il faut bien entendu être plus attentif aux traitements, requetes qui vont être effectués sur cette table. En d'autre terme tant que vous n'avez pas étudié la partie traitement sur cette table il n'y a aucunne raison de l'éclater en plusieures. Quand vous développerez vos procédures je vous conseil de générer vos 5 millions d'enregistrements afin de mieux apprécier vos optimisations.
	00

15/12/2004, 09h58	#6
Barbibulle Membre Expert Frédéric Inscription : octobre 2002 Messages : 1 722 Détails du profil Informations personnelles : Nom : Frédéric Âge : 42 Informations forums : Inscription : octobre 2002 Messages : 1 722 Points : 2 025 Points : 2 025	Commencez par l'analyse de vos besoins en terme de traitements et après vous y verrez plus clair et pourrez décidez des optimisations possibles de la base. La création d'index en est une mais la séparation des données dans des tables différentes peut en être une autre (un peu extreme à mon sens).
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email