certes, mais comme j'ai sous entendu : modele relationnel != modele SQL .
J'ai dans de vieux messages, faisait insidieusement un presqu'amalgame entre relationnel et SQL et plus que je regarde les implems SQL dans le détail et entre autre le SQL99 plus il y a des différences flagrantes.
la premiere est tres visible :
- dans un modele relationnel, tout SELECT est en fait un SELECT DISTINCT implicite, ce qui faire qu'il ne peut y avoir de t-uple en doublon, le SQL lui est permissif à ce niveau.
la seconde qui merite un tres grosse explication avec de l'histoire dedans :
- le modele relationnel n'a aucun typage, le modele SQL est tres fortement typé et ne peux plus revenir en arriere sur ce point.
La troisieme est plus subtil et est l'origine de la premiere :
- tout t-uple doit avoir un ID unique dans l'ensemble de la base au sens du modele relationnel, pour le SQL on s'en fout un peu.
cet ID unique n'est pas un ID en temps que tel mais doit etre plus considéré comme une signature du t-uple pour l'identifier. cette subitilité ( non codable à l'origine sans overhead colosale ) à introduit cette abération des INDEX unique d'une table. Si l'on regarde attentivement, la notion de formes normales ( surtout la 5ieme et la 6ieme forme normale ), l'on se rend compte que pour construire cet ID, cela necessite que chaque colone soit en fait un systeme clé/valeur en temps que tel.
pour donner un apercu ( de tres loin et par temps de brouillard ) de la chose :
( "col1", "col2", "col3", "col4" )
( "a", "b", "c", d")
le modele SQL stocke cela tel quel, ce qui permet le contenu dupliqué.
le modele relationnel implique l'unicité des attributs dans chacune des colones puisque chaque colone est en fait un table atomique et que cette "table à 4 colones" est assimilable à une sorte de select codé en dur retournant le contenu ci dessus.
un exemple plus accesible :
faire le stockage d'une "table" avec 2 "colones", une contenant une clé unique et l'autre une valeur, est une bete table de hachage. le modele relationnel devrait permettre cela si l'on regarde les kilometres de texte de Date et Codd.
bizarrement, le modele SQL rajoute à la table un index pour avoir des performances honorables. l'index est une simple table de hachage contenant pour clé, un ID recherché et pour valeur l'adresse du t-uple ... ce qui fait que dans un modele SQL faire une table de hachage revient à rajouter comme overhead ... le moteur SQL lui meme.
merci au revoir, SQL passe ton chemin.
Pour en revenir à la fermeture transitive
que SQL99 essaie tant bien que mal d'expliquer que d'avoir calculer une fermeture transitive permettrait de faire plein de truc cool. il n'empeche que cela necessite de pouvoir resoudre une recherche de type SELECT id_fils FROM arbre WHERE id_pere = ? ; en temps constament constant ( il y a une subtilité dans la formulation ). sinon cela fait partir l'opération dans une panade générale et humiliante pour le systeme ... d'un autre coté avec le point que j'ai évoqué juste avant, je pense que l'on peut imaginer que ce n'est pas pour aujourd'hui que l'on pourra imaginer une implémentation efficace en temps processeur et consommation memoire ( à la rigueur comme pour les INDEX ... perdre du disque pour esperer gagner du temps de lecture sur des table essentiellement en lecture ).
[^] # Re: utilité ?
Posté par Mouns . En réponse à la dépêche Première publication en licence libre du SGBDO EyeDB. Évalué à 3.
J'ai dans de vieux messages, faisait insidieusement un presqu'amalgame entre relationnel et SQL et plus que je regarde les implems SQL dans le détail et entre autre le SQL99 plus il y a des différences flagrantes.
la premiere est tres visible :
- dans un modele relationnel, tout SELECT est en fait un SELECT DISTINCT implicite, ce qui faire qu'il ne peut y avoir de t-uple en doublon, le SQL lui est permissif à ce niveau.
la seconde qui merite un tres grosse explication avec de l'histoire dedans :
- le modele relationnel n'a aucun typage, le modele SQL est tres fortement typé et ne peux plus revenir en arriere sur ce point.
La troisieme est plus subtil et est l'origine de la premiere :
- tout t-uple doit avoir un ID unique dans l'ensemble de la base au sens du modele relationnel, pour le SQL on s'en fout un peu.
cet ID unique n'est pas un ID en temps que tel mais doit etre plus considéré comme une signature du t-uple pour l'identifier. cette subitilité ( non codable à l'origine sans overhead colosale ) à introduit cette abération des INDEX unique d'une table. Si l'on regarde attentivement, la notion de formes normales ( surtout la 5ieme et la 6ieme forme normale ), l'on se rend compte que pour construire cet ID, cela necessite que chaque colone soit en fait un systeme clé/valeur en temps que tel.
pour donner un apercu ( de tres loin et par temps de brouillard ) de la chose :
( "col1", "col2", "col3", "col4" )
( "a", "b", "c", d")
le modele SQL stocke cela tel quel, ce qui permet le contenu dupliqué.
le modele relationnel implique l'unicité des attributs dans chacune des colones puisque chaque colone est en fait un table atomique et que cette "table à 4 colones" est assimilable à une sorte de select codé en dur retournant le contenu ci dessus.
un exemple plus accesible :
faire le stockage d'une "table" avec 2 "colones", une contenant une clé unique et l'autre une valeur, est une bete table de hachage. le modele relationnel devrait permettre cela si l'on regarde les kilometres de texte de Date et Codd.
bizarrement, le modele SQL rajoute à la table un index pour avoir des performances honorables. l'index est une simple table de hachage contenant pour clé, un ID recherché et pour valeur l'adresse du t-uple ... ce qui fait que dans un modele SQL faire une table de hachage revient à rajouter comme overhead ... le moteur SQL lui meme.
merci au revoir, SQL passe ton chemin.
Pour en revenir à la fermeture transitive
que SQL99 essaie tant bien que mal d'expliquer que d'avoir calculer une fermeture transitive permettrait de faire plein de truc cool. il n'empeche que cela necessite de pouvoir resoudre une recherche de type SELECT id_fils FROM arbre WHERE id_pere = ? ; en temps constament constant ( il y a une subtilité dans la formulation ). sinon cela fait partir l'opération dans une panade générale et humiliante pour le systeme ... d'un autre coté avec le point que j'ai évoqué juste avant, je pense que l'on peut imaginer que ce n'est pas pour aujourd'hui que l'on pourra imaginer une implémentation efficace en temps processeur et consommation memoire ( à la rigueur comme pour les INDEX ... perdre du disque pour esperer gagner du temps de lecture sur des table essentiellement en lecture ).