Discussion :

[JustMe]

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]

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]

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]

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]

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

[Barbibulle]

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).