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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Molina
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 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.
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
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 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 ?
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
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.
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.
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.
