je pense que l'approche que tu exposes pour differencier un modele SQL d'un modele Objet n'est pas des plus pertinant pour des raisons de modelisations.
Oui, ce que tu exposes permet de montrer à celui qui ne connait pas grand chose aux bases de données ( le cas de beaucoup de monde ) qu'il est possible d'avoir une approche autre avec les données.
Maintenant, ton exposé contient une lacune :
- si l'on considere les foreignkeys comme des references symboliques sur des objets dont les attributs sont les attributs du tuple.
- si l'on fourni deux classes racines l'une modélisation une liste et l'autre un élément de la liste
alors toute structure découlant d'une requete SQL aussi complexe soit elle sera soit une liste d'élément soit un element représentant un résultat.
Apres tu dérives par table, chacunes des deux classes racines, et tu as une modélisation qui commence à prendre forme.
Par contre, là ou le modele SQL et le modele relationnel commence à avoir des lacunes se trouve :
- sur la fermeture transitive
- sur un acces navigationnel aux données
le second point est le simple constat que si l'on connait une information auquel on veut acceder dans ces modeles, il est necessaire de faire une recherche de l'information ( bien que le SQL soit plus permissif que le relationnel, le probleme reste qu'il n'y a pas d'adressage des éléments en tant que tel, uniquement des recherches contraintes ).
pour le premier point, c'est un peu plus touchy :
la fermeture transitive est une opération qui retourne l'ensemble des éléments concerrnés de manière récursive "à l'infini" par une requete.
un exemple concret de cette impossibilité est de sortir l'ensemble d'une discussion threadée avec une opération relationnelle. le seul moyen de contourner cela est de faire appel à d'autres langage que l'algebre relationnelle.
à contrario, les bases objets fournissent sur ce point des solutions assez elegante.
A l'inverse, le modele objet dispose lui aussi d'une lacune execrable : l'impossiblité d'agreger les informations, c'est à dire à construire des tables batardes issues de jointures et d'élagage de tables.
donc le choix d'une base de données doit se faire en sachant ce que l'on va faire avec.
[^] # Re: utilité ?
Posté par Mouns . En réponse à la dépêche Première publication en licence libre du SGBDO EyeDB. Évalué à 7.
Oui, ce que tu exposes permet de montrer à celui qui ne connait pas grand chose aux bases de données ( le cas de beaucoup de monde ) qu'il est possible d'avoir une approche autre avec les données.
Maintenant, ton exposé contient une lacune :
- si l'on considere les foreignkeys comme des references symboliques sur des objets dont les attributs sont les attributs du tuple.
- si l'on fourni deux classes racines l'une modélisation une liste et l'autre un élément de la liste
alors toute structure découlant d'une requete SQL aussi complexe soit elle sera soit une liste d'élément soit un element représentant un résultat.
Apres tu dérives par table, chacunes des deux classes racines, et tu as une modélisation qui commence à prendre forme.
Par contre, là ou le modele SQL et le modele relationnel commence à avoir des lacunes se trouve :
- sur la fermeture transitive
- sur un acces navigationnel aux données
le second point est le simple constat que si l'on connait une information auquel on veut acceder dans ces modeles, il est necessaire de faire une recherche de l'information ( bien que le SQL soit plus permissif que le relationnel, le probleme reste qu'il n'y a pas d'adressage des éléments en tant que tel, uniquement des recherches contraintes ).
pour le premier point, c'est un peu plus touchy :
la fermeture transitive est une opération qui retourne l'ensemble des éléments concerrnés de manière récursive "à l'infini" par une requete.
un exemple concret de cette impossibilité est de sortir l'ensemble d'une discussion threadée avec une opération relationnelle. le seul moyen de contourner cela est de faire appel à d'autres langage que l'algebre relationnelle.
à contrario, les bases objets fournissent sur ce point des solutions assez elegante.
A l'inverse, le modele objet dispose lui aussi d'une lacune execrable : l'impossiblité d'agreger les informations, c'est à dire à construire des tables batardes issues de jointures et d'élagage de tables.
donc le choix d'une base de données doit se faire en sachant ce que l'on va faire avec.