POSTGRESQL et Heritage

Le
Chris
Bonjour,

Qqun a t il utilisé meme en labo le principe d'heritage de Postgresql ?

Ainsi je me posais la question suivante :

<ame sensible s'abstenir ya peut etre une grosse connerie la dessous et
peut etre de gros morceaux de troll >

pourquoi ne pas declarer une table ENREG qui serait la mere de toutes
les autres ainsi il serait simple de developper certaine fonctions
commme l'export incrementale
des fonctions de MAJ automatique de date de modif / de creation de user
de modif de creation si courante en informatique de Gestion

Exemple :

ENREG:
Id : integer
DATCRE: date (mise a jour par un trigger par exemple)
DATMOD: date
USRMOD: varchar


CLIENT INHERITS ENREG
NOM
ADRESSE


PRODUIT INHERITS ENREG
CLE
DESIG
PRIX


Ainsi je pourrais parcourir l'ensemble des données de ma base avec un
select * from ENREG where datmod = today() pour connaitre ce qui a ete
cree / modifie depuis un certain temps

Bref centraliser certaine fonction de base penible a faire

qu'en pensez vous ?


A+
chris
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Marc Molina
Le #21862831
Chris wrote:
Qqun a t il utilisé meme en labo le principe d'heritage de Postgresql
?



Oui, je me suis principalement intéressé à PostgreSQL pour sa fonctionnalité
d'héritage de tables. Mais ça ne m'empêche de rester fidèle à MySQL. Un
autre gros avantage de PS est de permettre de créer ses propres types, donc
il est normal de pouvoir les hériter. D'autres SGBD comme Oracle et MS SQL
Server supportent aussi l'héritage, enfin je l'ai lu, jamais expérimenté sur
ces deux mastodontes... que j'admire de loin pour l'instant.

pourquoi ne pas declarer une table ENREG qui serait la mere de toutes
les autres ainsi il serait simple de developper certaine fonctions
commme l'export incrementale
des fonctions de MAJ automatique de date de modif / de creation de
user de modif de creation si courante en informatique de Gestion



Bonne idée, cela rejoint complètement les concepts de POO (Programmation
Orienté Objet). Par contre les capacités d'héritage de PS restent très
limitées comparé à ce qu'on peut trouver en C++ ou Java par exemple.

Exemple :

ENREG:
Id : integer
DATCRE: date (mise a jour par un trigger par exemple)
DATMOD: date
USRMOD: varchar



Yummy :)

Ainsi je pourrais parcourir l'ensemble des données de ma base avec un
select * from ENREG where datmod = today() pour connaitre ce qui a ete
cree / modifie depuis un certain temps

Bref centraliser certaine fonction de base penible a faire

qu'en pensez vous ?



Que du bien sauf qu'il ne faut pas considérer qu'une sélection sur la table
ENREG (Table de base, Object dans certains langages...) ne s'applique pas
aux tables héritées. Il ne s'agit que d'héritage au niveau des types créées,
des tables, et non pas des données. L'héritage permet donc principalement
d'améliorer sensiblement la complexité potentielle d'une application et de
classifier les objets du système d'information (instances d'objet, tables de
données...).

Après rien n'empêche de faire une jointure multiple et de grouper les
données pour avoir un historique des CRE et MOD. Mais ça reste assez
abstrait car il n'est pas évident de faire la différence entre les entrées
des tables sélectionnés. Il manque le polymorphisme du C++ par exemple. Mais
rien n'empêche de "mapper" les tables à des classes (PHP 5, Java...), on
parle d'ORM (Object Relational Mapping.
Chris
Le #21862811
Jean-Marc Molina a écrit :
Bonne idée, cela rejoint complètement les concepts de POO (Programmation
Orienté Objet). Par contre les capacités d'héritage de PS restent très
limitées comparé à ce qu'on peut trouver en C++ ou Java par exemple.

Exemple :

ENREG:
Id : integer
DATCRE: date (mise a jour par un trigger par exemple)
DATMOD: date
USRMOD: varchar



Yummy :)





Oui surtout que juste aprés si je veux gerer un export incremental au
niveau enreg et pas base il suffirait de rajouter une zone sur ENREG
pour que les tables filles en profite

mais bon, sinon autre question ou on en est sur les base de données Objet ?


A+
chris
Jean-Marc Molina
Le #21862401
Chris wrote:
mais bon, sinon autre question ou on en est sur les base de données
Objet ?



Je m'intéressais beaucoup au sujet il y a quelques années mais comme
l'actualité parle plus des RDBMS et de l'ORM, je me suis un peu détourné du
sujet. O2 était un gros projet de ODBMS mais il n'a plus été commercialisé à
la fin des années 90 je crois. Le sujet est aussi bien couvert dans
l'ouvrage "Bases de données" de Georges Gardarin chez Eyrolles. Il existe
sinon Zope Object Database (ZODB), un ODBMS pour le serveur d'applications
Zope, technologie Python. Tu peux lire l'article "Introduction to the Zope
Object Database" [1] pour en apprendre plus.

Comme je développe avec des technologies objet (UML, C++/Java, PHP 5...) je
croyais vraiment en l'avenir des ODBMS à mes débuts mais au fil du temps
j'ai découvert que des ORDMBS comme PostgreSQL ou de simples RDBMS comme
MySQL offrent un très bon rapport scalability/performance. Ces dernières
années on parle aussi beaucoup des technologies d'ORM comme Hibernate. Elles
permettent de faire du développement orienté objet et de gérer la
persistence de ses objets (instances des classes) à travers de simples bases
relationnels. L'avènement des SGBD natif XML offrent aussi de nouvelles
opportunités pour les développeurs de BDD. Je pense que l'avenir est
vraiment là, la fusion des deux mondes. La POO et la gestion "relationnel"
des données.

Après tous ces sujets sont un grand débat. Je pense par exemple à celui qui
oppose les partisans de la programmation fonctionnelle (C, PHP 4...) à ceux
qui sont pros OO (C++, Java...). Tout le monde criait à une mort imminente
des dinosaures et il y a 10 ans, et moi le premier car j'en étais un, mais
finalement leur extinction se fait encore attendre. Je crois que l'actualité
ou les rumeurs ont trop tendance à vouloir tout enterrer du jour au
lendemain lorsqu'une nouvelle tendance voit le jour. Il faut vraiment faire
la différence entre une mode (AJAX ?) et l'acceptation par la communauté des
développeurs.

Comme vous pouvez le voir tous ces sujets me passionnent donc n'hésitez pas
à intervenir pour partager vos remarques avec nous.

Notes :
* [1]
http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html
Publicité
Poster une réponse
Anonyme