Discussion :

[hugo69]

Bonjour,

Travaillant sur des projets sur mesure, je pense à inviter une structure de table et quelques classes qui seraient compatible pour tout type de projet.

J'ai commencé à monter une architecture simple avec 4 tables principales et 3 tables secondaires.

J'ai une table ENTITE qui servira à enregsitré tout objet. 1 champs idEntite, et un champs idEntiteParent, qui servira à définir à quel idEntité l'enfant appartiendra, le cas échéant.

Une table BASE qui contiendra toutes les options récurentes du style, liste des Pays et autres.... Cette table aura un champs libellé, un champs Paramètre String et un champs paramètre Integer.

Une table CRITERE qui affectera une option de la table BASE à une entité. Il y aura également pour chaque ligne, un Champs String et un Integer, qui servira à définir une option particulière.

Une table PARAMETRE qui aura la même utilité que la table CRITERE sauf que l'on affectera une valeur à une entité, et non pas un élément de la table BASE. On aura des colonnes String, Integer, Decimal... qui permettra d'affecter tout type de parametre à une ENTITE.

Et 3 tables de définition des rubriques, 1 pour les ENTITE, 1 pour les CRITERES de la BASE. Et une pour les PARAMETRE.

Je sais que tout ceci est expliqué rapidement, le but étant juste de montrer le principe.

Est que certains d'entre vous ont déja tenté ce genre de conception. Des conseils, un lien internet sur ce genre de projet, ou même peut-etre un projet téléchargeable? niveau performance?


Et puis finalement, je me suis dit. A partir de la, et de cette logique, pourquoi ne faire faire tout simplement une seule table qui aurait tout type de champs, et une TABLE définition des rubrique.
J'ai peur que ca puisse poser de grave problème de performance...

Certains ont ils déja tenté de genre de projet un peu fou?

Je ne sais pas si j'ai été suffisament clair, sinon demandez moi, je préciserai.

Merci

Une ta

[madfu]

Ce que tu souhaites faire n'a rien de "fou", tu veux juste construire un méta modèle

Tiens lis ça : http://sql.developpez.com/modelisation/metadonnees/

[hugo69]

oui, je l'ai déja consulté...

J'ai même commencé à reproduire les tables dans ACCESS.

Mais je n'arrive pas à comprendre comment on peux faire un FROM sur le nom d'une table qui est en fait le String d'une ligne de table.

Code :

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

1
2
3
4
5
6
7
8
9
SELECT *
FROM   TR_PROSPECT_PRP PRP
       LEFT OUTER JOIN T_DONNEE_DON DON
            ON PRP.PRP_ID = DON.CRE_LIGNE
       LEFT OUTER JOIN TR_TABLES_TBL TBL
            ON DON.TBL_ID = TBL.TBL_ID
       LEFT OUTER JOIN TR_CARACTERISTIQUE_CAR CAR
            ON DON.CAR_ID = CAR.CAR_ID
WHERE  TBL.TBL_SQL_NOM = 'TR_PROSPECT_PRP'

je parle de la table TR_PROSPECT_PRP PRP

[elbj]

Bonjour

Une fois que tu as ta meta-table, tu peux très bien constituer des Vues qui représenteront le modèle de données.

Cordialement

[fsmrel]

Est que certains d'entre vous ont déjà tenté ce genre de conception ?

Personnellement non, car les SGBD que j’utilise (DB2 for z/OS, SQL Server, ...) m’offrent déjà le service grâce à leur catalogue relationnel (tables SysTables recensant tables et vues, SysColums recensant les colonnes des précédentes, SyRrels décrivant les contraintes d’intégrité référentielle, SysForeignKeys, etc.)

Par contre, un AGL comme Cool:gen a sa propre métabase, car il gère des objets qui sortent du domaine du SGBD (partie IHM par exemple). Il a même une méta-métabase composée d’un nombre extrêmement réduit de tables (de mémoire, quelque chose comme 5 tables) mais pouvant devenir volumineuses, de l’ordre de la centaine de millions de lignes).

Au-delà, vouloir réduire le tout à une seule table, façon relation universelle (RU), n’offre guère d’intérêt quand on sort du cadre de la recherche théorique et vous vous inspirerez plutôt des écrits pragmatiques de SQLpro, évoqués par madfu.

Enfin, je vous engage à produire des tables normalisées au minimum en BCNF.

Je joins quelques unes des observations faites par Ted Codd (voir [Codd1990]), concernant le concept de relation universelle, défendu par l’université de Stanford dans les années quatre-vingts, laquelle reprochait notamment au modèle relationnel de Codd son côté navigationnel (jointure inter-tables) :

1. La nécessité d’effectuer des jointures entre attributs non-clés reste la même et leurs contreparties sont en fait plus compliquées pour le développeur.
   
   
2. Au niveau physique : effet dévastateur quant au disque et la mémoire, du fait de l’inflation de valeurs en réalité marquées nulles (au sens "inapplicable"). (J’ajouterai que non seulement que la RU devient vite un gruyère, mais elle est vouée à être un gruyère obèse.)
   
   
3. Inaptitude aux évolutions quant aux genres d’informations stockées dans la base de données :
   
   
   
   1. Effort supplémentaire pour maintenir la RU quand on crée de nouvelles tables et vues.
      
      
   2. Risque d’effets secondaires sur les programmes d’application, dans la mesure où leur logique n’est pas à l’abri d’une restructuration de la RU.
      
      
   3. Fréquence et charge accrues concernant les tâches de réorganisation et autres tâches de service.

Vous pouvez approfondir le sujet en essayant d’interpréter (à titre d’exercice) ce qui est écrit par exemple dans "Who won the Universal Relation wars?". Vous pouvez aussi fouiller dans la Toile (mots clés : relation universelle, Stanford....)

Référence :
[Codd1990] E. F. Codd. The Relational Model for Database Management: Version 2 (Reading, Mass.: Addison-Wesley, 1990).

[hugo69]

Bonjour

Une fois que tu as ta meta-table, tu peux très bien constituer des Vues qui représenteront le modèle de données.

Cordialement

JE n'ai pas encore utiliser trop les vues.
En fait c'est une requete pour la visualisation?

qui me donne une sorte de table à la lecture c'est ca?

[hugo69]

Personnellement non, car les SGBD que j’utilise (DB2 for z/OS, SQL Server, ...) m’offrent déjà le service grâce à leur catalogue relationnel (tables SysTables recensant tables et vues, SysColums recensant les colonnes des précédentes, SyRrels décrivant les contraintes d’intégrité référentielle, SysForeignKeys, etc.)
....

Un des plus beaux post que l'on ne m'est jamais répondu.

Merci.

Je n'ai pas tout compris, mais votre prose laisse à penser que vous êtes dans le métier et savez de quoi vous parlez.

Si j'ai bien compris, cette stratégie des 5 tables, ne vous attire pas plus que ca?

Maintenant que j'ai un peu développer sur mon premier projet basé sur cetet logique, je tire les conclusions suivantes:

- Tout développement supplémentaire est assez lourd pour la lecture notamment, et demande surtout une vigilance à de multiples niveaux, mais en fait chaque nouvel objet ressemble aux autres. C'est juste qu'il faut faire preuve de grande vigilance à chaque nouveau développement.
- Les fonctions de recherches sont souvent simplifiées
- Les développements de maitenance sont souvent très facile à implémenter

Je reste très séduit par cette méthode, mais c'est vrai que c'est un peu lourd à gérer. Mais sur d'autres points, ca apporte une souplesse assez incroyable. Et le logiciel devient du coup beaucoup moins pyramidal. surtout pour des projets assez gros, ou je suis le seul développeur.

La question que je me pose désormais, maintenant que je dois commencer un autre projet d'envergure, que je souhaiterai peut-être vendre dans le futur, est de savoir si je pars la dessus ou pas.