Mysql Relationnel et Flat non relationnel

Version imprimable

04/09/2018, 18h53
scamphp

Mysql Relationnel et Flat non relationnel

Bonjour

je travaille sur mon projet de site et je me demandais s'il ne serait pas intéressant de séparer les données relationnelles des données non relationnelles

On a tendance à tout stocker dans la base de données, mais les bases de données ne sont elle pas uniquement pour gérer des relations...

Serait-il intéressant de stocker uniquement dans la base les données que lesquelles on fait des recherches (auteur, date, catégorie, tag...)

et le contenu de l'article, le titre... dans un fichier flat (sauf si l'on souhaite faire des recherches).

Bon il y a ceux qui vont dire que le cache c'est fait pour cela....

On stocke tout dans la DB et après on met en cache

Oui mais cela rend quand même la table plus lourde pour rien

Voila je voulais avoir votre avis ;)
05/09/2018, 09h27
CinePhil

Citation:

je travaille sur mon projet de site et je me demandais s'il ne serait pas intéressant de séparer les données relationnelles des données non relationnelles

Que voulez-vous dire par là ?
Au sens strict, dans une BDD relationnelle, toutes les données sont relationnelles puisque qu'une table est en fait la représentation physique d'une "relation" au sens de la théorie relationnelle (lecture un peu ardue mais très instructive).

Citation:

Serait-il intéressant de stocker uniquement dans la base les données que lesquelles on fait des recherches (auteur, date, catégorie, tag...)

et le contenu de l'article, le titre... dans un fichier flat (sauf si l'on souhaite faire des recherches).

Ça dépend (comme disait Fernand Raynaud :mrgreen: ) !
Si vos articles sont déjà des fichiers (scan d'articles de presse par exemple) ou des liens vers d'autres sites, il vaut mieux enregistrer les fichiers d'articles dans un répertoire et enregistrer le nom du fichier (avec si nécessaire le chemin d'accès) dans la BDD.
Si par contre ce sont des articles plus ou moins courts rédigés par les contributeurs du site, comme dans un CMS, il est plus simple d'enregistrer directement les articles en BDD, dans une colonne de type TEXT, voire MEDIUMTEXT ou LONGTEXT. C'est le SGBD qui se débrouille pour stocker ça. Encore une fois, vous n'avez pas à vous soucier de ça (vous voyez que c'est simple, les SGBD ! :mrgreen: ).

Citation:

Oui mais cela rend quand même la table plus lourde pour rien

Un cas tout de même à examiner sérieusement : les commentaires ou autres colonnes facultatives.
Soit, par exemple, une table destinée à accueillir des données sur des projets :
te_projet_prj (prj_id, prj_numero, prj_id_chef, prj_date_debut, prj_date_fin_prevue, prj_nom, prj_budget, prj_commentaire)

Lors de l'étude, on constate que l'enregistrement de commentaires arrive sur moins de 30% des projets.
=> Il vaut mieux alors faire une table externe pour les commentaires sur les projets :
te_projet_prj (prj_id, prj_numero, prj_id_chef, prj_date_debut, prj_date_fin_prevue, prj_nom, prj_budget)
te_commentaire_projet_cpj (cpj_id_projet, cpj_commentaire)
05/09/2018, 23h54
Artemus24

Salut Scanphp.

Citation:

Envoyé par Scanphp

On a tendance à tout stocker dans la base de données, mais les bases de données ne sont elle pas uniquement pour gérer des relations...

En fait, les bases de données ne sont pas ce qu'il y a de mieux pour gérer des données.
Un SGBDR est un outil standard qui est fait pour une organisation de type relationnelle.
Mais toutes les données ne sont pas de type relationnelle.

Selon moi, le mieux est la structure de données que l'on rencontre dans le langage C/C++.
Elle a surtout l’inconvénient que vous devez créer votre propre moteur de recherche.
Mais au niveau performance, on ne fait pas mieux !

Vous pouvez créer des liens de toutes natures, comme lien avant, lien arrière, lien vers parent, lient vers enfants, lien vers début de chaînage, lien vers fin de chaînage, ...
En fait, ce que je vous décris se nomme l'organisation réseau, connue aussi sous le nom IDS II sous bull.

Citation:

Envoyé par Scanphp

Serait-il intéressant de stocker uniquement dans la base les données que lesquelles on fait des recherches

Une base de données, c'est avant tout une organisation des données. On y met ce que l'on veut y organiser.
Mais la fonctionnalité reste la recherche basée sur des liens, même si ces liens sont de types relationnelles, hiérarchiques, réseaux, ...

Citation:

Envoyé par Scanphp

Oui mais cela rend quand même la table plus lourde pour rien

Pas nécessairement car vous pouvez scinder vos tables en plusieurs autres tables. Le tout étant lié par des relations.

Un SGBDR c'est avant un moteur de recherche basée sur le modèle relationnel.
Il se peut que le modèle relationnel ne soit pas ce que vous désirez.

@+
06/09/2018, 10h51
SQLpro

Citation:

Envoyé par scamphp

et le contenu de l'article, le titre... dans un fichier flat (sauf si l'on souhaite faire des recherches).

Déjà pour cette raison...

Citation:

On stocke tout dans la DB et après on met en cache

Un SGBDR travaille EXCLUSIVEMENT en mémoire. Il met tout ce qui est utilisé en cache naturellement. Il est donc inutile de le faire manuellement.

Citation:

Oui mais cela rend quand même la table plus lourde pour rien

Et alors ? Si vous scindez en deux, le volume sera le même ! Il sera juste répartit dans 2 dispositifs différents vous obligeant à une double maintenance !
Donc, c'est juste stupide en plus d'être limité !

A +
06/09/2018, 11h46
escartefigue

Citation:

Envoyé par Artemus24

En fait, les bases de données ne sont pas ce qu'il y a de mieux pour gérer des données.

Voilà une assertion pour le moins surprenante, qui mériterait des explications

Citation:

Envoyé par Artemus24

Mais toutes les données ne sont pas de type relationnelle.

Dans une base de données relationnelles chaque "relation" ou "tuple" est un ensemble d'attributs, à quel niveau situez vous les "données de type non relationnel" ?

Citation:

Envoyé par Artemus24

Un SGBDR c'est avant un moteur de recherche basée sur le modèle relationnel.

Cette définition est extrêmement réductrice !
Un SGBDR est un SGBD qui répond aux 12 règles de CODD, ou qui en tout cas s'en approche au plus près
Un SGBDR doit garantir les propriétés ACID
07/09/2018, 18h28
Artemus24

Salut Escartefigue.

Citation:

Envoyé par Escartefigue

Voilà une assertion pour le moins surprenante, qui mériterait des explications

J'ai oublié le mot "relationnelle". Désolé.
Je voulais dire qu'il n'existe pas que le modèle relationnelle pour les bases de données.
Comme j'ai pratiqué le modèle réseau (IDS II sous bull, DBMS sous IBM) avant le modèle relationnelle, j'ai encore une certaine sympathie à son sujet.

Citation:

Envoyé par Escartefigue

Dans une base de données relationnelles chaque "relation" ou "tuple" est un ensemble d'attributs, à quel niveau situez vous les "données de type non relationnel" ?

Quand elle déroge à la règle du relationnelle.
Par exemple, une relation à la fois père vers fils et fils vers père. Dans le modèle relationnelle, cela se nomme un verrou mortel.

Les liens entre entités peuvent exister sans restriction à l'inverse du modèle relationnelle.

Citation:

Envoyé par Escartefigue

Un SGBDR est un SGBD qui répond aux 12 règles de CODD,

Et donc, on passe à la trappe le CODASYL.

@+
09/09/2018, 21h05
escartefigue

Citation:

Envoyé par Artemus24

Je voulais dire qu'il n'existe pas que le modèle relationnelle pour les bases de données.
Comme j'ai pratiqué le modèle réseau (IDS II sous bull, DBMS sous IBM) avant le modèle relationnelle, j'ai encore une certaine sympathie à son sujet.

Je comprends pour avoir pratiqué également le hiérarchique (IMS DL1 d'IBM) comme le réseau (TOTAL de CINCOM) de nombreuses années, pour autant, les bases de données relationnelles ont montré leur supériorité à tout point de vue sur ces SGBD canal historique :P
Les 12 règles de codd ont quand même sacrément du bon, je me souviens à quel point il était compliqué de modifier la structure des bases non relationnelles tant le risque d'impact sur les données était lourd !
A l'époque il fallait surtout pas louper la sauvegarde avant modif, sinon on le payait cash !
Sans compter la gestion de l'isolation et des verrous, tellement pauvre sur les bases hiérarchiques et réseaux, bref c'était le paléolithique du SGBD :D

Citation:

Envoyé par Artemus24

Par exemple, une relation à la fois père vers fils et fils vers père. Dans le modèle relationnelle, cela se nomme un verrou mortel.

Le modèle relationnel n'a rien à voir avec le verrou mortel, le verrou mortel est lié aux traitements concurrentiels, pas au modèle de données

Citation:

Envoyé par Artemus24

Les liens entre entités peuvent exister sans restriction à l'inverse du modèle relationnelle.

Les liens du modèle réseau sont de type précédent/suivant sur un critère de rangement physique ce qui est un non sens dans le modèle relationnel puisque l'ordre de restitution est du ressort du traitement, à tel point que dans les premières versions du SQL, ORDER BY n'existait pas !

Citation:

Envoyé par Artemus24

Et donc, on passe à la trappe le CODASYL.

A la trappe non, aux archives oui :P
10/09/2018, 12h04
SQLpro

Citation:

Envoyé par escartefigue

CODASYL....

A la trappe non, aux archives oui :P

Mais CODASYL n'a presque rien à voir avec les bases de données…
1) Conference On DAta SYstemes and Language : explore les différentes voies des langages et des systèmes, mais pas des bases de données !

2) pour les bases de données, le CODASYL a créé le DBTF : DataBase Task Group (1967)

Les deux activités ont toujours été séparées…

A +
10/09/2018, 12h15
escartefigue

On s'éloigne un peu du sujet, mais il semble, d'après Wikipédia, que ça ne soit pas tout à fait le cas (extrait) :

Le CODASYL (sigle de Conference on Data Systems Languages, en français « Conférence sur les langages de systèmes de traitement de données ») est l'organisme américain de codification des systèmes de bases de données. Il a publié en 1959 les spécifications du langage COBOL. Par la suite, ses travaux entre 1974 et 1981 ont donné naissance au modèle navigationnel de SGBD (opposé au modèle hiérarchique largement promu par IBM).

L'article complet ici : https://fr.wikipedia.org/wiki/Conference_on_Data_Systems_Languages
10/09/2018, 12h18
escartefigue

Citation:

Envoyé par escartefigue

Le modèle relationnel n'a rien à voir avec le verrou mortel, le verrou mortel est lié aux traitements concurrentiels, pas au modèle de données

Je m'auto-corrige ou plutôt je complète ;)
Une modélisation à plat, propice aux tables obèses, peut toutefois augmenter de façon conséquente les problèmes de concurrences d'accès puisqu'un plus grand nombre de traitements accèdent simultanément aux mêmes ressources (tables, index) faute d'avoir découpé les tables avec rigueur.
10/09/2018, 14h57
fsmrel
Bonsoir,

Permettez-moi de participer au débat.

Escartefigue, nous redondons à l’occasion (verrou mortel par exemple), mais bon !
Fred, en ce qui concerne le DBTG, il est vrai que dans l’organigramme CODASYL, il s’agit d’une instance du comité responsable des langages de programmation, mais quand on parle de DBTG dans le contexte des bases de données on peut faire comme Codd et se cantonner au terme CODASYL, connu de tous. Dans les années soixante-dix, quand je donnais mes cours sur les bases de données, je faisais mention de ce distinguo.

En guise de préambule :

Je rappelle que le SGBD (réseau) IDS a été conçu et développé au milieu des années 60 par un ingénieur de grand talent, Charles Bachman (Prix Turing en 1973, la plus haute distinction, une sorte Nobel en informatique). IDS est l’archétype des SGBD de type réseau (CODASYL).

Je rappelle encore que le modèle relationnel est une théorie qui fut proposée en 1970 par un mathématicien et logicien du nom de E.F. Codd (Prix Turing en 1981), fondée sur la logique du 1er ordre (le calcul relationnel), et pour laquelle il a proposé son alter ego ensembliste (bien qu’il place le calcul relationnel un cran au-dessus), qui nous plus familier, grâce à son algèbre relationnelle laquelle faut-il le rappeler est complète.

Pour Codd, les langages de manipulation des bases de données se positionnent selon 3 niveaux.

Extrait de A data base sublanguage founded on the relational calculus (1971) :

https://www.fsmwarden.com/developpez...age_table1.png

Je cite Codd (toujours dans A data base sublanguage founded on the relational calculus) qui situe IDS (et CODASYL) au niveau inférieur parce que le langage est procédural :

« Most readers of this paper will have some familiarity with the existing systems (and the CODASYL proposal) cited in the top two rows of this table. The data sublanguages for these systems, so far as they can be identified separately* from their host languages, are rather primitive. Not even boolean selection expressions are provided in IDS [9] and CODASYL [4]. Therefore, there is a heavy dependence on the host language for iterative scanning and searching.
...
*The separation in the CODASYL proposal is clear. »

Codd place l’algèbre relationnelle au niveau intermédiaire parce que pour obtenir le résultat voulu, on enquille les opérations (projection, restriction, union, jointure, etc.) les unes à la suite des autres, dans l’ordre qui nous convient, mais de façon non procédurale (pas de IF ou de LOOP et toutes ces sortes de choses propres à la programmation) : une 1re opération appliquée à une relation (par exemple une restriction) produit une nouvelle relation qui peut à son tour participer à une autre opération (par exemple une jointure) pour la production d’une autre relation, etc., jusqu’à l’obtention du résultat voulu qui bien entendu est une relation.

Le calcul relationnel est au niveau supérieur, parce que l’obtention du résultat voulu ne nécessite qu’une seule instruction.

A noter que SQL est à classer à ce niveau, dans la mesure où le résultat (table, tant qu’à faire !) est la combinaison d’un ensemble d’opérations (jointures, unions, restriction (WHERE), etc.) conclue par la projection finale (ligne SELECT).

Citation:

Envoyé par Artemus24

Toutes les données ne sont pas de type relationnel[le] ... Il se peut que le modèle relationnel ne soit pas ce que vous désirez.

Gordon, as-tu un exemple de données que le modèle relationnel serait incapable de prendre en compte alors qu’un sous-langage basé sur la norme CODASYL permettrait de le faire ? Au plan structurel, il n’y a rien qui puisse être représenté par un modèle réseau qui ne puisse être représenté par seulement des relations, et au plan manipulation des données, il n’y a pas de requête qui puisse être satisfaite par un modèle réseau qui ne puisse l’être par le modèle relationnel.

Citation:

Envoyé par Artemus24

Elle a surtout l’inconvénient que vous devez créer votre propre moteur de recherche.

Tu m’étonnes ! Ça a pris entre deux et trois ans pour l’équipe qui a inventé SYSTEM/R (et SQL, du reste intégralement pompé sans vergogne par Ellison), le temps de sortir un 1er jet, remplacé ex nihilo par une 2e version...

Citation:

Envoyé par Artemus24

la fonctionnalité reste la recherche basée sur des liens, même si ces liens sont de types relationnelles, hiérarchiques, réseaux, ...

Il n’y a pas de liens en relationnel ! Je pense que tu as pu être induit en erreur par le concept de clé étrangère, qui n’est pas un lien mais une référence utilisée dans la définition d’une contrainte d’intégrité référentielle, selon laquelle un tuple référençant un autre tuple ne peut exister si le tuple référencé n’existe pas. Il se peut aussi que tu « quiproquotes » dans la mesure où le modèle relationnel est une théorie, tandis que les merisiens et consorts utilisent l’expression « modèle relationnel » pour les « diagrammes relationnels », mais la notion de diagramme est bien entendu totalement absente du modèle relationnel de Codd.

Citation:

Envoyé par Artemus24

Vous pouvez créer des liens de toutes natures, comme lien avant, lien arrière, lien vers parent, lient vers enfants, lien vers début de chaînage, lien vers fin de chaînage, ...
En fait, ce que je vous décris se nomme l'organisation réseau, connue aussi sous le nom IDS II sous bull.

Tu es en train de parler du COMMENT ! Ce qui nous concerne c’est le QUOI !

Par exemple, soit les relvars (variables relationnelles) suivantes :

FOURNISSEUR {FournisseurId, FournisseurNom}

PRODUIT {ProduitId, ProduitNom, Couleur, Poids}

LIVRAISON {FournisseurId, ProduitId, Quantite}

Je te laisse le soin de nous traduire en DML IDS II la requête suivante, écrite en ALPHA en 1973 par Chris Date :
```
RANGE PRODUIT x
RANGE LIVRAISON y
GET RESULTAT (FOURNISSEUR.FournisseurNom) : ∃x∃y(y.FournisseurId = FOURNISSEUR.FournisseurId ∧ y.ProduitId = x.ProduitId ∧ x.Couleur = 'rouge')
```
Les variables x et y sont quantifiées, elles parcourent les tuples des relvars auxquelles ont les a affectées.

En SQL (qui n’était alors qu’en cours de conception), GET a été renommé en SELECT.

Citation:

Envoyé par Artemus24

Mais au niveau performance, on ne fait pas mieux !

Es-tu à même de le prouver ? Je prends un contre-exemple, celui des camions et les livraisons :

https://www.fsmwarden.com/developpez...ions_idrel.png

En inversant le sens des flèches par conformité au diagrammes de Bachman :

https://www.fsmwarden.com/developpez...an_camions.png

Supposons que l'on ait besoin de savoir quels camions sont concernés par les livraisons chez le client Gillou (Siret = 12345678900001).

Si en SQL je code :
```
SELECT DISTINCT Camion.CamImmat
FROM   Client JOIN Commande ON Client.CliId = Commande.CliId
              JOIN LigneCde ON Commande.CliId = LigneCde.CliId 
                AND Commande.CdeId = LigneCde.CdeId
              JOIN Engagement ON LigneCde.CliId = Engagement.CliId
                AND LigneCde.CdeId = Engagement.CdeId
                AND LigneCde.LigneId = Engagement.LigneId
              JOIN Livraison  
                ON  Engagement.CliId = Livraison.CliId
                AND Engagement.CdeId = Livraison.CdeId
                AND Engagement.LigneId = Livraison.LigneId
                AND Engagement.EngId = Livraison.EngId
              JOIN Camion  
                ON  Livraison.CamionId = Camion.CamionId
WHERE  CliSiret = '12345678900001' ;
```
Il faut savoir que DB2 (qui est un SGBD relationnel) ne fait pas dans le détail et son optimiseur simplifie ainsi ma requête :
```
SELECT DISTINCT Camion.CamImmat
FROM   Client JOIN Livraison  
                ON  Client.CliId = Livraison.CliId
              JOIN Camion  
                ON  Livraison.CamionId = Camion.CamionId
WHERE  CliSiret = '12345678900001' ;
```
On est donc passé de 5 à 2 jointures...

Clairement, prendre ce raccourci spatio-temporel avec un SGBD réseau est évidemment impossible, puisqu’il faut obligatoirement suivre les pointeurs, via les sets (liens, chemins, mais certainement pas ensembles ! _{_:D} ) S1, S2, S3, S4, S5, bref ça prend du temps ! Je doute que pour leur part, C et C++ sachent transformer le code et prendre le raccourci...

Citation:

Envoyé par Artemus24

Par exemple, une relation à la fois père vers fils et fils vers père. Dans le modèle relationnelle, cela se nomme un verrou mortel.

Tout faux ! La notion de verrou mortel (étreinte fatale, dead lock) est complètement étrangère au modèle relationnel de données ! Jette un coup d’oeil ici et cherche « affectation multiple ». Le verrou mortel concerne en fait les transactions :

Un utilisateur U1 met à jour la table A (transaction T1) pendant qu’un utilisateur U2 met à jour la table B (transaction T2), suite à quoi, dans sa transaction T1, U1 cherche ensuite à mettre à jour la table B pendant qu’au cours de T2, U2 cherche à mettre à jour à son tour la table A. Le dénouement de cette situation de blocage est SGBD dépendant, mais il y a toujours une victime. Par exemple, en IMS (années 70/80), celui des deux utilisateurs qui a fait le moins de mises à jour est pénalisé (ROLLBACK) et l’autre ne l’est pas (COMMIT). Pour DB2, je te renvoie aux ouvrages de Gabrielle Wiorkowski (RIP).

Citation:

Envoyé par Artemus24

Et donc, on passe à la trappe le CODASYL.

Nuance ! Codd montre seulement que IDMS/R (de feue Cullinet) s’est prétendu SGBD relationnel alors qu’il a obtenu la note 0 sur 12 (comme DATACOM/DB qui avait la même prétention). Forcément, IDMS/R reste un SGBD réseau, ni plus, ni moins...

Et, comme il avait déjà compris quel était le sens de l’Histoire, Charles Bachman a mis ses diagrammes au rencart (les fameux diagrammes de Bachman), et mis le voiles de chez Cullinet en 1983 (année de naissance de DB2, tiens, tiens...) pour fonder BACHMAN Information Systems, développer et vendre son produit de migration (re-engineering selon ses propres termes) des SGBD réseau vers les SGBD relationnels SQL... :D
10/09/2018, 17h25
fsmrel
Je poursuis.

A propos du débat réseau / relationnel

Un peu d’Histoire. En mai 1974, eut lieu à Ann Arbor ce qu’on appela « The Great Debate », la confrontation entre Bachman et Codd.

Depuis un bon moment Codd faisait des bonds sur sa chaise tandis qu’il épluchait la documentation originale de CODASYL. Tout en préparant la rencontre, il démontra l’absence d’une définition digne de ce nom d’un modèle réseau, aussi s’appliqua-t-il à combler cette lacune, car à défaut, comparer les spécifications de CODASYL avec le modèle relationnel, revenait à comparer des pommes et des scoubidous, en conséquence de quoi le débat se serait terminé en eau de boudin. Il introduisit le concept d’essentialité, crucial pour la compréhension des modèles de données en général, et du relationnel par rapport au réseau en particulier : qu’est-ce qu’on ne peut pas supprimer dans un modèle théorique, abstrait, sans tout flanquer par terre ? Par exemple il est clair que supprimer la notion de SET (lien) dans le modèle réseau est impensable, mais supprimer le séquencement des enregistrements (SET ... ORDER IS) ? Bien sûr, dans un sous-schéma, ordonner est utile, mais dans un schéma principal ? En tout cas, Codd insiste sur la simplicité : je pense, vu ce qu’on voit chez DVP — ne serait-ce que dans le forum MySQL _;)— qu’un non-programmeur peut se lancer dans le codage de requêtes SQL (comme l’avait prévu Codd il y a 45 ans !), mais ça se complique plus que bigrement pour réaliser l’équivalent en COBOL conforme à CODASYL, en effet, ne faut-il pas d’abord se lancer dans l’apprentissage de COBOL ?

Quoi qu’il en soit, avant d’affronter le récent Turing Award (la plus haute distinction en informatique, une sorte de Prix Nobel), Codd écrivit un article de 20 pages dans lequel il consigna tout cela et compara les deux approches quant à la structure des données et de leur manipulation : Interactive support for non-programmers: the relational and network approaches. A titre d’exemple, (avec la permission des auteurs), l’article comporte en appendice le code COBOL développé par R. L. Frank (University of Utah) et E. H. Sibley (University of Maryland), code initialement hébergé dans The Data Base Task Group Report: An Illustrative Example, ISDOS Working Paper No. 71, February 1973, U.S. National Technical Information Service, Document AD-759-267.

Ce code COBOL (que je ne reproduis pas, car l’autorité gendarmesque pourrait me taper sur les doigts) a pour objet de répondre à la question suivante :

Etant donnés une machine X et une tâche (job) Y planifiée pour la période A, B, chercher quelqu’un (au plus une personne) qui soit compétent pour la machine X, et qui soit disponible dans la période A, B. Si ce quelqu’un existe, l’affecter à la tâche en question.

Codd répond à son tour à cette question, mais évidemment en ALPHA.

Les variables relationnelles :
```
RELATION MACH-SKILL(MACH#,SKILL#) KEY(MACH#,SKILL#)
         PERSON-SKILL(P#,SKILL#) KEY(P#,SKILL#)
         SCHED(JOB#,P#,MACH#,SCHED-START-DATE,SCHED-STOP-DATE) KEY(JOB#)
```
Leur exploitation :
```
GET (into workspace) W (at most) (1) PERSON-SKILL.P#: (such that)
    EXIST MACH-SKILL (with) 
       (MACH-SKILL.MACH#=X)
       & (MACH-SKILL.SKILL#=PERSON-SKILL.SKILL#)
       & NOT EXIST SCHED (with)
             (SCHED.P#=PERSON-SKILL.P#)
             & (SCHED.SCHED-START-DATE LESS-THAN B)
             & (SCHED.SCHED-STOP-DATE GREATER-THAN A)

MOVE W INTO SCHED-RECORD 

PUT SCHED-RECORD SCHED
```
Les statistiques comparatives établies par Codd et Date sont édifiantes quant au nombre d’instructions exécutées :
```
 
                        CODASYL         relational

GO TO                      15               0
PERFORM UNTIL               1               0
currency indicators        10               0
IF                         12               0
FIND                        9               0
GET                         4               1
STORE / PUT                 2               1
MODIFY                      1               0
MOVE CURRENCY               4               0
other MOVEs                 9               1
SUPPRESS CURRENCY           4               0

total statements          >60               3
```
Dans The Database Relational Model: A Retrospective Review and Analysis, Chris Date note que la solution relationnelle aurait pu être réduite au seul PUT, le GET et le MOVE n’étant pas strictement nécessaires. En effet, Codd a pris COBOL comme langage hôte, en vertu de quoi GET produit le résultat dans une variable (W) du langage, MOVE recopie le résultat dans une variable imposée (SCHED-RECORD) et envoie le résultat (PUT) dans la base de données.

Comme l’écrit Codd, il ne s’agit pas de critiquer Frank et Sibley, car leur objectif était de fournir un tutoriel sur les bases de données CODASYL. Ce qui est important de retenir est l’absence en ALPHA de branchements, d’itérations explicites, de contrôles de positionnement, condition essentielle, sine qua non, pour l’utilisation des bases de données par l’utilisateur non-programmeur, et pour débarrasser le programmeur du fardeau d’un monceau de code inutile.

Et le « Great Debate » eut donc lieu au début du mois de mai 1974, à Ann Arbor...

La rencontre David (Codd) contre Goliath (Bachman) se termina clairement par la victoire du premier qui s’était très minutieusement préparé avec son article, plus un second, rédigé par Chris Date (The relational and network approaches: Comparison of the application programming interfaces) : ceinture, bretelles et épingles à nourrice tant qu’à faire. Quant à Bachman, il était arrivé disons les mains dans les poches, mais l’Histoire n’en resta pas là, l’arrivée au début des années quatre-vingts des SGBDR avait donné des sueurs froides à d’aucuns (Cullinet et consorts) qui mirent un zest de SQL dans leur SGBD, puis beaucoup (voyez le DML Reference Guide for COBOL d’IDMS, devenu CA IDMS depuis qu’il a été racheté par Computer Associates (prononcer : Compieuteur à chaussettes, c’est plus facile), et Bachman se mit à développer son produit de migration des bases de données réseau aux bases de données relationnelles, O tempora, o mores, mais il faut bien vivre...
10/09/2018, 22h54
Artemus24

Salut Fsmrel.

Citation:

Envoyé par Fsmrel

Permettez-moi de participer au débat.

Avec plaisir ! Vous avez dû prendre beaucoup de temps pour répondre.
Comme toujours, vous êtes prolixes dans vos explications et très pertinent. J'apprécie grandement votre retour d'expérience.
A l'inverse de certain, vous n'êtes pas dans la critique permanente et vous argumentez.

Comme le sujet dévie sur la pertinence du SGBD relationnel vis-à-vis du SGBD réseau, comme vous le savez certainement, je ne suis pas un expert, mais juste quelqu'un qui a pratiqué ces deux SGBD.
Mes réponses sont dues à mon expérience et de ce que j'ai entendu dire ou fait, à l'époque, sur la pertinence de ces deux types de SGBD. Autrement dit, ma parole ne fait pas le poids, face à un expert comme vous.

Mais n'empêche que j'ai mon opinion à ce sujet. J'aimerai abordé les points suivants :

1) A moins de me tromper, un SGBD est d'abord un extracteur de données. Est-ce vrai ou pas ?

C'est sur ce point que je me suis focalisé, à savoir la performance dans l'obtention de l'extraction.
Je ne parle pas des fonctionnalités qui ont été ajoutés par la suite, histoire d'enrichir le SGBD.

2) à l'origine, la différence entre un SGBD réseau et un SGBD relationnel reposait pour le premier, sur une organisation basée sur des liens alors que le second ne nécessitait aucune organisation en particulier, juste des lignes en vrac.
Sauf qu'en terme de performance, le SGBD réseau surpassait, à l'époque, le SGBD relationnel.
Depuis, le SGBD relationnel a amélioré ses performances par l'ajout des index entre autre. Ce que aussi, le SGBD réseau a adpoté par la suite.

Ma question concerne la performance de l'extraction des données selon les deux types de SGBD.
D'après vous, c'est le SGBD relationnel qui est le plus performant. Et cela m'étonne ?

3) la grande différence de ces deux SGBD, le SGBD relationnel est beaucoup plus souple dans son usage, à l'inverse du SGBD réseau qui est rigide et nécessite de gros efforts de réorganisation.
Sur ce point, je ne viendrais pas contredire qui que ce soit.

Ma question reste sur la performance, à partir du moment où l'organisation des données est optimale pour ces deux SGBD. Lequel est le plus performant ?
Je sais, c'est une question rhétorique mais pour la résoudre, seul l'expérimentation fera preuve.

4) si je désire simuler, par exemple en langage C/C++, une organisation de type base de données, je choisirai sans hésitation l'organisation basée sur les liens, celle utilisé par le SGBD réseau.
A l'inverse, il serait trop lourd et compliquer de simuler une organisation relationnelle.

J'en viens à la lourdeur de l'écriture d'un SGBD relationnel vis-à-vis d'un SGBD réseau.
Ne croyez-vous pas que choisir seulement un SGBD relationnel pour sa souplesse d'usage est coûteux en terme d'occupation mémoire ?

5) d'après ce que vous dites, je ne suis pas convaincu que le SGBD relationnel soit plus performant que le SGBD réseau.
Je rappelle que la fonctionnalité première est l'extraction des données, et non des traitements procéduraux, qui reste l'appanage des langages informatique.

Citation:

Envoyé par Fsmrel

Therefore, there is a heavy dependence on the host language for iterative scanning and searching.

6) Et en quoi est-ce un mal ?

Je n'ai pas très bien compris l'introduction des procédures stockées, et des fonctions dans une base de données.
N'est-ce pas le rôle du programme applicatif de gérer le traitement des données et de laisser au SGBD le rôle de l'extraction ?

D'ailleurs, c'est ce que vous dites au travers des paroles de Codd :

Citation:

Envoyé par Fsmrel

on enquille les opérations (projection, restriction, union, jointure, etc.) les unes à la suite des autres, dans l’ordre qui nous convient, mais de façon non procédurale (pas de IF ou de LOOP et toutes ces sortes de choses propres à la programmation)

Je maintiens, en reprenant vos propos, que le rôle d'un SGBD est d'extraire les données ! En d'autre terme, le SGBD est un navigateur et rien de plus.

Citation:

Envoyé par Fsmrel

Le calcul relationnel est au niveau supérieur, parce que l’obtention du résultat voulu ne nécessite qu’une seule instruction.

7) N'appelle-t-on pas cela un moteur de recherche ? Et en quoi cela donne plus d'avantage au SGBD relationnel vis-à-vis du SGBD réseau ?
Ne me dites pas la performance car je n'y crois pas pour la simple raison de la lourdeur du moteur de recherche du SGBD relationnel qui doit gérer des données en vrac.

Citation:

Envoyé par Fsmrel

A noter que SQL est à classer à ce niveau, dans la mesure où le résultat (table, tant qu’à faire !) est la combinaison d’un ensemble d’opérations (jointures, unions, restriction (WHERE), etc.) conclue par la projection finale (ligne SELECT).

8) D'où le langage SQL pour venir interroger la base de données relationnelle qui repose sur le moteur de recherche.
Dans le SGBD réseau, nous n'avons pas besoin d'un langage, juste des routines pour parcourir la base de données.

Citation:

Envoyé par Fsmrel

Gordon, as-tu un exemple de données que le modèle relationnel serait incapable de prendre en compte alors qu’un sous-langage basé sur la norme CODASYL permettrait de le faire ?

9) Vous me prenez au dépourvu. A priori, non.
Comme le réseau gère des liens, j'ai toujours pensé qu'une collection de données était mieux définie en terme d’appartenance, que le relationnel qui gère des données en vrac.

Citation:

Envoyé par Fsmrel

Il n’y a pas de liens en relationnel !

10) D'où le fait que les données sont stockées en vrac et non organisées.

Citation:

Envoyé par Fsmrel

Je pense que tu as pu être induit en erreur par le concept de clé étrangère

11) Non.

Citation:

Envoyé par Fsmrel

Il se peut aussi que tu « quiproquotes »

12) Pas du tout. J'essaye d'exprimer une autre façon de voir les choses, au risque de ne pas partager la vision global sur la question du modèle relationnel.
Je n'ai jamais affirmé que le modèle relationnel est mauvais. Il est très bien pour son usage souple basé sur la théorie des ensembles.
Au même titre, je ne critique pas non plus la théorie des ensembles.

Ce qui me dérange est cette vision purement mathématique qui vient s'insérer dans le monde informatique comme étant la seule ayant un intérêt viable.

Je ne suis pas un théoricien comme vous, mais plutôt quelqu'un de pragmatique.
Si on me demande de créer une base de données à partir de rien, je ne vais pas adopter le modèle relationnel qui me semble compliquer à mettre en oeuvre, mais bien le modèle réseau qui de toute évidence est logique dans sa façon de lier les données entre elles.

Citation:

Envoyé par Fsmrel

Tu es en train de parler du COMMENT ! Ce qui nous concerne c’est le QUOI !

13) Excusez-moi d'être naïf, mais c'est quoi la différence ?

La théorie ne m'intéresse pas ou peu. Ce qui m'intéresse, c'est comment résoudre mon problème, avec la vision optimale de la performance et de l'occupation mémoire.
Si pour gérer des données, j'ai deux solutions qui se propose, je vais choisir celle qui sera la plus optimale.
Inversement, je suis bien obliger de rentrer dans le rang quand tout le monde fait le choix de la souplesse au détriment de la performance.

Citation:

Envoyé par Fsmrel

Es-tu à même de le prouver ?

14) Si on me laisse le temps de faire le développement en C/C++, je suis capable d'écrire les routines permettant de parcourir la structure des données basées sur le modèle réseau.
Mes routines seront spécifiques à la structure que j'aurai choisi et de ce fait, elles seront plus performantes que d'utiliser un moteur standard de parcours d'une organisation relationnel standard.

C'est comme si vous me disiez qu'un costume sur mesure ne peut pas avoir la qualité de conception d'un costume standard alors que ma morphologie n'a rien de standard.

Citation:

Envoyé par Fsmrel

Je doute que pour leur part, C et C++ sachent transformer le code et prendre le raccourci...

15) Je pense que nous ne nous comprenons pas sur l'optimisation.
Vous mettez en premier la souplesse de l'accès aux données, en utilisant un moteur de recherche standard.
Vous utilisez un optimiseur qui va rechercher la meilleur façon d'accéder aux donner.

A l'inverse, je ne cherche pas jouer sur la souplesse dans l'accès aux données, quitte à ne pas savoir traiter un accès qui n'aurait pas été prévue dès le départ, mais bien à optimiser les requêtes qui ont été demandées par le travail que je dois réaliser.
Oui, il y aura un manque de souplesse, mais mes requêtes seront beaucoup plus performantes que les votre.

En fait, le choix du SGBD relationnel a été de rechercher la souplesse à l'usage au détriment de la performance.

Citation:

Envoyé par Fsmrel

Tout faux ! La notion de verrou mortel (étreinte fatale, dead lock) est complètement étrangère au modèle relationnel de données !

16) Désolé si le mot deadlock n'est pas adapté à ce que je voulais dire.
Si je désire créer une clef étrangère entre une entité fils vers père et une autre clef étangère entre une entité père vers fils (les mêmes entités), MySql va gueuler comme quoi, ce que je demande est impossible.
Il faudra introduire dans MySql, un nouvel outil (je n'ai pas le mot adéquate non plus), pour résoudre ce problème alors que dans le standard, on ne peut pas le faire.

A l'inverse, dans le modèle réseau, cela est possible car le remplissage peut se faire sans rencontrer ce genre de problème.

Citation:

Envoyé par Fsmrel

Le verrou mortel concerne en fait les transactions

17) Je le sais, mais je n'ai pas trouvé la bonne expression pour désigner le fait que je me retrouve bloqué dans ce que je veux faire.

Citation:

Envoyé par Fsmrel

Forcément, IDMS/R reste un SGBD réseau, ni plus, ni moins...

18) Qu'est-ce que vous voulez que ça soit d'autre ?

Citation:

Envoyé par Fsmrel

Et, comme il avait déjà compris quel était le sens de l’Histoire, Charles Bachman a mis ses diagrammes au rencart

19) Oui et alors ?

Faut-il que je vous parle dans le cadre de la SNCF, du développement du TGV fait par des polytechniciens, à grand coup de publicité au détriment du TER ?
C'est un choix politique et rien de plus ! Et nous savons tous que ce n'est pas ce qu'il y a de mieux en matière de gestion du territoire.

C'est le même débat entre le costume standard et le costume sur mesure.
Pour des raisons de coûts, le standard est le moins cher tant que vous êtes dans la norme.
A partir du moment où vous n'êtes plus dans la norme, ou si vous avez les moyens, le mieux est de faire un costume spécifique.

Ce qui me dérange dans votre approche, c'est le manque de diversité dans les solutions proposées.

Je vais encore me ramasser des -1. :(

@+
11/09/2018, 09h51
escartefigue

Bien que la dernière réponse soit adressée à François, je me permets de rebondir, après tout nous sommes sur un forum ;)

Citation:

Envoyé par Artemus24

1) A moins de me tromper, un SGBD est d'abord un extracteur de données. Est-ce vrai ou pas ?

Un SGBD est bien plus que ça. Avant d'extraire les données, il faut les stocker, les structurer, en garantir la cohérence, en permettre l'accès via des autorisations, en permettre le partage en gérant les concurrences d'accès, fournir les utilitaires permettant son administration...
Toutes ces fonctions font partie intégrante d'un SGBD

Citation:

Envoyé par Artemus24

2) à l'origine, la différence entre un SGBD réseau et un SGBD relationnel reposait pour le premier, sur une organisation basée sur des liens alors que le second ne nécessitait aucune organisation en particulier, juste des lignes en vrac.
Sauf qu'en terme de performance, le SGBD réseau surpassait, à l'époque, le SGBD relationnel.
Depuis, le SGBD relationnel a amélioré ses performances par l'ajout des index entre autre. Ce que aussi, le SGBD réseau a adpoté par la suite.

Mon expérience dans les grandes entreprises qui ont implémenté des SGBD-R en remplacement des bases hiérarchiques ou réseau, me forcent à constater que les piètres performances parfois constatées ne sont pas dues au SGBD-R lui même, mais à méconnaissance de la mise en œuvre de celui-ci, notamment en terme de modélisation.
Les grands comptes chez lesquels j'interviens (banque, assurance, industrie, retraite complémentaire) ont pour point commun une modélisation catastrophique (non respect des formes normales, tables obèses, typage des données incohérent, requêtes non ensemblistes ou mal construites...)
Intrinsèquement, un SGBD-R bien utilisé a toujours été au moins aussi performant qu'un SGBD réseau ou hiérarchique et le plus souvent beaucoup plus.

Citation:

Envoyé par Artemus24

5) d'après ce que vous dites, je ne suis pas convaincu que le SGBD relationnel soit plus performant que le SGBD réseau.
Je rappelle que la fonctionnalité première est l'extraction des données, et non des traitements procéduraux, qui reste l'appanage des langages informatique.

NON. La fonctionnalité première n'est pas l'extraction des données, voir plus haut ! Mais même sur le seul critère de restitution des informations de la BDD, le SGBD-R est très supérieur à toute autre organisation. Fsmrel a proposé un exemple particulièrement parlant, on pourrait en citer bien d'autres.
De plus il ne faut pas raisonner sur un traitement accédant seul à la BDD, mais dans un contexte concurrentiel, multi-utilisateur et multi-thread, contexte dans lequel les SGBD-R sont autrement mieux armés que leurs ancêtres non -R.

Citation:

Envoyé par Artemus24

Je ne suis pas un théoricien comme vous, mais plutôt quelqu'un de pragmatique.
Si on me demande de créer une base de données à partir de rien, je ne vais pas adopter le modèle relationnel qui me semble compliquer à mettre en oeuvre, mais bien le modèle réseau qui de toute évidence est logique dans sa façon de lier les données entre elles.

Pour quelqu'un de pragmatique, vouloir mettre en œuvre un modèle réseau en 2018 est un paradoxe !
S'il reste un éditeur qui propose encore de nos jours un SGBD réseau, je serai curieux de le connaitre...

Je ne vais pas répondre point par point car ça prendrait trop de temps, mais pour résumer
- Sur l'aspect strictement performances et toutes choses égales par ailleurs, un SGBD-R bien utilisé est supérieur à un SGBD hiérarchique ou réseau, et ce d'autant plus que les accès concurrents sont nombreux
- Sur tous les autres aspects, les apports du modèle relationnel sont tellement énormes qu'il n'y a plus débat depuis bien longtemps. Ce combat d'arrière garde est complètement anachronique.
12/09/2018, 21h16
fsmrel
Je redonde encore avec Escartefigue _:D

Citation:

Envoyé par Artemus24

A moins de me tromper, un SGBD est d'abord un extracteur de données. Est-ce vrai ou pas ?

Je confirme évidemment ce que dit Escartefigue. Considérer au premier chef un SGBD comme un « extracteur » de données, c’est plutôt réducteur. En son temps, IBM proposait DXT (Data Extract), que je n’ai jamais vu être utilisé, mais qui a peut-être intéressé des gens ne connaissant rien à DB2, pour effectivement récupérer des données gérées par ce dernier. DXT est manifestement un extracteur, mais en aucun cas un SGBD.
Maintenant, si tu extraies des données de la base, avec quoi alimentes-tu celle-ci ? Comme son nom l’indique, un SGBD est un gestionnaire de données, il a le contrôle sur tous les accès à la base de données.

Le SGBD fournit les moyens pour :
- définir les données ;
- opérer sur ces données ;
- optimiser les opérations (l’optimiseur est le cerveau qui améliore ma programmation, je te renvoies à ma requête comportant 5 jointures, ramenées à 2 par DB2, associant seulement CLIENT, LIVRAISON, CAMION) ;
- le SGBD est garant de l’intégrité des données ;
- il est garant de la sécurité des données ;
- de leur restauration ;
- il gère la concurrence des accès ;
- il gère dynamiquement le dictionnaire des données (notamment les statistiques), essentiel pour l’optimiseur (la métabase, faisant cruellement défaut dans les systèmes pré-relationnels, avec lesquels le dictionnaire est statique) ;
- il doit permettre la distribution des données ;
- etc., etc.
Si l’objet premier d’un SGBD est l’extraction des données, à quoi servent les propriétés ACID des transactions ? Ainsi, un SGBDR garantit leur atomicité (COMMIT / ROLLBACK ≡ tout ou rien en mise à jour), etc.

Citation:

Envoyé par Artemus24

C'est sur ce point que je me suis focalisé, à savoir la performance dans l'obtention de l'extraction.

Pourquoi pas... Pour ma part, j’ai conservé des résultats de tests de performance que j’ai effectués en 1987, sous le contrôle de Cullinet (éditeur du SGBD IDMS/R). On est dans un contexte réseau (IDMS/R version 10.1, sous JES2, unité centrale IBM 3090-180, disques IBM 3380).

Prenons le cas d’un record IDMS, appelons-le CONTRAT (les contrats d’une personne). On a 400 000 occurrences de 80 octets chacune.

Lecture des 400 000 occurrences
```
                                            Durée constatée
                                    
Sans index                                       2'00"
Avec index sur la db-key (DIR)                   2'11"
Avec index sur le numéro de contrat (CALC)      77'17"  
```
Autrement dit, la performance de l’« extraction » varie grandement avec le mode d’accès.

(Pour mémoire, ce qu’on appelle la db-key est la clé calculée par le SGBD, correspondant à l’emplacement physique d’une occurrence : numéro de page physique + numéro de ligne dans la page.)

Citation:

Envoyé par Artemus24

Je ne parle pas des fonctionnalités qui ont été ajoutés par la suite, histoire d'enrichir le SGBD.

C’est-à-dire ? De quelles fonctionnalités parles-tu ?

Pour ma part, je n’appréciais pas trop la V1R1 de DB2, parce qu’il manquait l’instruction EXPLAIN, chère au DBA (et attention à la production !) On l’a eue avec la V1R2 : ouf ! Il manquait l’intégrité référentielle : on a dû attendre la V2R1 (1988) pour l’avoir : ouf ! J’attends toujours de pouvoir définir mes propres types et les opérateurs qui vont avec, mais bon... Quel que soit le SGBD, on attend toujours l’instruction CREATE ASSERTION, présente dans le prototype SYSTEM/R (1974-1976) et dans la norme SQL, mais bon, on se raccroche aux branches à coups de triggers...

Mais les fonctionnalités essentielles ont toujours été présentes.

Citation:

Envoyé par Artemus24

à l'origine, la différence entre un SGBD réseau et un SGBD relationnel reposait pour le premier, sur une organisation basée sur des liens alors que le second ne nécessitait aucune organisation en particulier, juste des lignes en vrac.

J’espère que tu as compris qu’avec un (vrai) SGBD relationnel on manipule des relations (dans le sens mathématique du terme, à ceci près qu’une relation mathématique est invariante et que ses colonnes ne sont pas nommées, elles se distinguent par leur position, voir The Relational Model for Database Management, Version 2, page 4.)

Le terme « en vrac » est évidemment impropre, pour ne pas dire dévalorisant, car une relation est aussi un ensemble et ne contient donc jamais de doublons, et comme pour tout ensemble, l’ordre des tuples est sans objet. C’est du reste sur ce point qu’achoppent ceux qui abordent le sujet et n’arrivent pas à se défaire de leur culture séquentielle.

Citation:

Envoyé par Artemus24

Sauf qu'en terme de performance, le SGBD réseau surpassait, à l'époque, le SGBD relationnel.

En quelle année ? Quel SGBD réseau ? Quel SGBD relationnel ? En tout cas, encore une légende à détruire, en 1976, SYSTEM/R cartonnait !

Citation:

Envoyé par Artemus24

Depuis, le SGBD relationnel a amélioré ses performances par l'ajout des index entre autre.

Une fois de plus tu réécris l’Histoire à ta façon ! Dès leur naissance, DB2 et son aîné SQL/DS (industrialisation de SYSTEM/R) étaient évidemment équipés de l’instruction CREATE INDEX ! Les DBA SQL/DS pleuraient parce que DB2 permettait le partitionnement des index, mais pas son aîné...

Et bien sûr, en 1974-1976, l’ancêtre, le prototype SYSTEM/R permettait d’indexer, à ceci près que l’instruction s’appelait CREATE IMAGE (avec options UNIQUE et CLUSTERING s’il vous plaît, comme ses descendants). Je vois mal un SGBD réseau « surpasser » SYSTEM/R, lequel était doté de son catalogue relationnel et de son optimiseur, constitutifs du coeur du système, clés de la performance.

Et tous ces index et images sont des arbres B+ (équilibrés, avec chaînage des feuilles).

Citation:

Envoyé par Artemus24

Ce que aussi, le SGBD réseau a adpoté par la suite.

Il était donc grand temps, pour essayer de rattraper SYSTEM/R et sa descendance !

Je confirme qu’en 1987 IDMS/R avait de bonnes performances pour « extraire » les contrats (cf. le record CONTRAT ci-dessus) mais, par construction (ah ! que les pointeurs !), il restera toujours à la traîne pour les requêtes optimisées par DB2 (revois l’exemple des camions et des livraisons)...

Citation:

Envoyé par Artemus24

Ma question reste sur la performance, à partir du moment où l'organisation des données est optimale pour ces deux SGBD. Lequel est le plus performant ?
Je sais, c'est une question rhétorique mais pour la résoudre, seul l'expérimentation fera preuve.

L’optimisation par DB2 de la requête à laquelle je viens de faire référence est une preuve. DB2 a pris un raccourci grâce à l’optimiseur, alors que les SGBD réseaux sont dans l’obligation sine qua non de suivre les pointeurs, les liens qui les entravent _:P, S1, S2, S3, S4 et S5 que j’ai fait figurer dans le diagramme de Bachman : non entravé par ces liens, DB2 a évité S2 et S3, et effectué une jointure (l’opérateur JOIN est un « dinosaur killer »), façon saut quantique en quelque sorte…

Citation:

Envoyé par Artemus24

Ne croyez-vous pas que choisir seulement un SGBD relationnel pour sa souplesse d'usage est coûteux en terme d'occupation mémoire ?

On ne choisit pas un SGBD seulement pour sa « souplesse d’usage » ! Je répète : l’intégrité et de la sécurité des données, leur restauration, la distribution des données, la concurrence des accès, l’ACIDité (au fait où en sont les SGBD réseau à ce sujet ?) Quant à la performance... Tiens, toujours en 1987 à l’occasion de mes tests (toujours sous le contrôle de Cullinet), ne serait-ce que pour ces humbles mais précieux auxiliaires que sont les utilitaires, pour réorganiser la table CONTRAT (400 000 lignes) + 1 index, 6 minutes avec DB2 V1R2, 26 minutes avec IDMS/R V10 ! Pour réorganiser l’index seul, 1 minute 20 secondes pour DB2, 11 minutes pour IDMS ! Pour sauvegarder la table (ça peut servir...) 40 secondes avec DB2, 6 minutes 30 secondes avec IDMS/R, etc., etc. Histoire de voir leur bobine, un peu provocateur, j’ai proposé aux gens de chez Cullinet que je leur réécrive leurs utilitaires (à l’époque, j’avais quand même plus de 20 ans d’assembleur quotidien dans les jambes).

Et tu viens nous parler d’occupation mémoire, à une époque où le PC (5 cm d’épaisseur) dont je suis en train de me servir a une mémoire 1000 fois celle du gros « mainframe » que j’ai secoué il y a trente ans !

Citation:

Envoyé par Artemus24

Ce qui me dérange est cette vision purement mathématique qui vient s'insérer dans le monde informatique comme étant la seule ayant un intérêt viable.

Le modèle relationnel est effectivement bâti sur les maths et la logique du 1er ordre. Ainsi, les mathématiciens ont pu nous fournir en théorèmes rassurants (ne serait-ce que pour la construction des optimiseurs ou la normalisation des relations). Mais les informaticiens restent partie prenante, il faut les bâtir tous ces SGBD relationnels, et les mathématiciens passent le relais aux ingénieurs.

Il ne s’agit pas d’intérêt viable, je rappelle que Codd a constaté que CODASYL avait tout simplement oublié de produire le modèle réseau et qu’il a fallu que ce soit Codd en personne qui le fasse, avant d’affronter Goliath, afin de comparer des choses comparables.

Citation:

Envoyé par Artemus24

Excusez-moi d'être naïf, mais c'est quoi la différence ?

Revenons sur le tableau que j’ai fourni dans le post #12. Regarde la ligne « total statements ». La différence est là :
```
 
                        CODASYL         relational

GO TO                      15               0
PERFORM UNTIL               1               0
currency indicators        10               0
IF                         12               0
FIND                        9               0
GET                         4               1
STORE / PUT                 2               1
MODIFY                      1               0
MOVE CURRENCY               4               0
other MOVEs                 9               1
SUPPRESS CURRENCY           4               0
total statements          >60               3
```
Codd a traité seulement du QUOI en répondant en une seule instruction à la question posée (médite sur cette partie du post #12), alors que le pavé procédural COBOL (PROCEDURE DIVISION) est truffé de IF, de GO TO, de FIND, de tests de codes-retour, de positionnement dans la structure (currency) etc. :

Logique du 1er ordre = QUOI (une instruction) , code procédural = COMMENT (toile d’araignée d’instructions).

Citation:

Envoyé par Artemus24

Si on me laisse le temps de faire le développement en C/C++, je suis capable d'écrire les routines permettant de parcourir la structure des données basées sur le modèle réseau.
Mes routines seront spécifiques à la structure que j'aurai choisi et de ce fait, elles seront plus performantes que d'utiliser un moteur standard de parcours d'une organisation relationnel standard.

Tu persistes dans le COMMENT et tes certitudes. Si tu as une base de données de 1000 tables, avec le relationnel tu maîtrises, avec C/C++ c’est moins sûr, même si on te laisse beaucoup, beaucoup, beaucoup de temps, et même plus...

Citation:

Envoyé par Artemus24

Oui, il y aura un manque de souplesse, mais mes requêtes seront beaucoup plus performantes que les votre.

Voeu pieux ! Les liens (sets) CODASYL t’entravent les pieds...

Citation:

Envoyé par Artemus24

En fait, le choix du SGBD relationnel a été de rechercher la souplesse à l'usage au détriment de la performance.

C’est un peu le discours que me tenaient les gens de chez Cullinet en 1987, rabâchant que DB2 était une brouette (ils avaient dû lire ça dans la presse du coeur informatique). Mes tests (effectués sous leur contrôle, je le rappelle), leur ont prouvé que la brouette était plutôt chez eux, et ça leur a fait mal, mais ils l’avaient bien cherché.

Citation:

Envoyé par Artemus24

Oui et alors ?

Bachman (RIP) était un homme intelligent, et il a bien compris que les SGBDR allaient supplanter les systèmes pré-relationnels. Ce qu’il a fait lui a permis de continuer à gagner son pain quotidien, je peux en témoigner en tant que témoin direct.

Citation:

Envoyé par Artemus24

Ce qui me dérange dans votre approche, c'est le manque de diversité dans les solutions proposées.

C’est-à-dire ? Tu parles de solutions, mais à quels problèmes ?

A suivre.
15/09/2018, 12h20
Artemus24

Salut à tous.

Citation:

Envoyé par Escartefigue

Un SGBD est bien plus que ça.

Vous m'indiquez la gestion des données au sein du SGBD. Je parle de son exploitation, à savoir les lectures.
C'est pourquoi, je ne comprends pas l'introduction des procédures stockées qui sert à faire du procédurale au sein d'un SGBD.
Ce genre de traitement est réservé à un langage de développement.

Vous ne vous souvenez pas de l'équation de Nicklaus Wirth : Structures de données + algorithmes = programmes.
S'il y a séparation entre "données" et "algorithme", ce n'est pas sans raison.

Citation:

Envoyé par Escartefigue

... me forcent à constater que les piètres performances parfois constatées ne sont pas dues au SGBD-R lui même, mais à méconnaissance de la mise en œuvre de celui-ci, notamment en terme de modélisation.

Nous sommes d'accord ! Et donc, comment vérifier la performance d'un SGBD réseau vis-à-vis d'un SGBD relationnel ?
La réponse est : on ne peut pas car la modélisation n'est pas optimale.

Citation:

Envoyé par Escartefigue

Intrinsèquement, un SGBD-R bien utilisé a toujours été au moins aussi performant qu'un SGBD réseau ou hiérarchique et le plus souvent beaucoup plus.

Sur ce point, je ne suis pas convaincu. Cela dépend fortement des requêtes et de la modélisation.

Citation:

Envoyé par Escartefigue

Mais même sur le seul critère de restitution des informations de la BDD, le SGBD-R est très supérieur à toute autre organisation.

Expliquez moi comment une organisation peut avoir une quelconque influence sur la performance ?
La performance est liée au temps d'accès mis pour lire les données.

Citation:

Envoyé par Escartefigue

De plus il ne faut pas raisonner sur un traitement accédant seul à la BDD, mais dans un contexte concurrentiel, multi-utilisateur et multi-thread, contexte dans lequel les SGBD-R sont autrement mieux armés que leurs ancêtres non -R.

Vous croyez que quand je travaillais sous IDS II, on avait qu'un seul utilisateur qui accédait à la base de données et que nous travaillons en mono tâche ? N'importe quoi !

Citation:

Envoyé par Escartefigue

Pour quelqu'un de pragmatique, vouloir mettre en œuvre un modèle réseau en 2018 est un paradoxe !

Relisez ma phrase. J'ai bien dit à partir de rien.
Donc, dans un langage comme le "C/C++", vous êtes capable de recréer les mêmes routines que ceux qui sont utilisés dans un SGBD de type relationnel ???
Bravo ! Moi, j'en suis incapable à cause de la complexité de cette mise en oeuvre et pourtant, j'ai un bon niveau en développement.

Citation:

Envoyé par Escartefigue

Sur tous les autres aspects, les apports du modèle relationnel sont tellement énormes qu'il n'y a plus débat depuis bien longtemps.

Le seul argument du SGBD relationnel est la souplesse de son organisation à l'inverse de celle du SGBD réseau.

Citation:

Envoyé par Fsmrel

Considérer au premier chef un SGBD comme un « extracteur » de données, c’est plutôt réducteur.

Si vous n'extrayez rien du tout, à quoi peut vous servir un SGBD ?

Citation:

Envoyé par Fsmrel

En son temps, IBM proposait DXT (Data Extract), que je n’ai jamais vu être utilisé

Je n'ai jamais entendu parlé de ce produit. A l'inverse, j'ai connu en son temps QBDE (query by example).

Citation:

Envoyé par Fsmrel

Maintenant, si tu extraies des données de la base, avec quoi alimentes-tu celle-ci ?

Vous êtes hors du contexte dont je parle.Voire mon premier commentaire ci-dessus.
C'est Escartefigue qui a fait la remarque que l'extraction des données n'est pas la seule fonctionnalité d'un SGBD.
Je ne le contredis pas sur ce point, mais ce n'est pas de cela dont je voulais parler.

Citation:

Envoyé par Fsmrel

Si l’objet premier d’un SGBD est l’extraction des données, à quoi servent les propriétés ACID des transactions ?

Je ne parle pas de l'atomicité, la cohérence, l'isolation et durabilité mais simplement de l'accès aux données, la lecture, c'est-à-dire le temps nécessaire pour les extraire.

Citation:

Envoyé par Fsmrel

Pourquoi pas...

Enfin, on y arrive.

Citation:

Envoyé par Fsmrel

Autrement dit, la performance de l’« extraction » varie grandement avec le mode d’accès.

Je le sais et donc choisir à bon escient le mode d'accès.

Citation:

Envoyé par Fsmrel

(Pour mémoire, ce qu’on appelle la db-key est la clé calculée par le SGBD, correspondant à l’emplacement physique d’une occurrence : numéro de page physique + numéro de ligne dans la page.)

J'ai toujours eu en tête qu'un index utilise la db-key, à savoir la position de la page dans le disque dur.
Et comme les index sont aussi bien utilisés dans le SGBD relationnel que dans le SGBD réseau, en quoi, le SGBD réseau serait moins performant ?

Citation:

Envoyé par Fsmrel

Le terme « en vrac » est évidemment impropre, pour ne pas dire dévalorisant, car une relation est aussi un ensemble et ne contient donc jamais de doublons, et comme pour tout ensemble, l’ordre des tuples est sans objet.

Il n'y a rien de péjoratif dans l'expression "en vrac". Je veux simplement dire que la ligne est insérée n'importe où dans le disque dur.
De ce fait, il n'y a pas de regroupement des lignes selon un ordre particulier, par exemple selon la primary key.
Ce qui implique que l'on va trouver toutes les lignes ayant un critère proche dans les mêmes pages et non pas n'importe où sur le disque.
D'où le fait de lire un index et quelques pages car toutes les lignes sont y regroupés et non dispersés dans le disque dur..

Citation:

Envoyé par Fsmrel

C’est du reste sur ce point qu’achoppent ceux qui abordent le sujet et n’arrivent pas à se défaire de leur culture séquentielle.

Pourquoi me parler de culture séquentielle ? Je ne suis pas débutant en informatique !
Le fait de regrouper dans une même page, des données qui sont disons proche selon un critère, pourquoi cela serait absurde ?

Citation:

Envoyé par Fsmrel

Quel SGBD réseau ?

Dans les années fin 70 et début 80, je travaillais sur IDS II en gcos 7.& 7000 sous CII-HB qui deviendra par la suite Bull.
Je m'en souviens très bien car cela m'a fortement marqué.

Citation:

Envoyé par Fsmrel

Quel SGBD relationnel ?

Je crois que c'étais du SQL/DS mais je n'en suis pas sûr. Le DB2 est venu après, lors d'une de mes missions vers les années 1985.

Citation:

Envoyé par Fsmrel

DB2 a pris un raccourci grâce à l’optimiseur, alors que les SGBD réseaux sont dans l’obligation sine qua non de suivre les pointeurs, les liens qui les entravent

Ce n'est pas tout à fait vrai car j'ai le souvenir que l'on pouvait entrer dans la base de données réseau autrement que par la racine.
Nous avions même des adresses calculées que l'on pouvaient stockées dans nos traitement, afin de reprendre la lecture, là on on s'était arrêté, suite à ce que je pourrais qualifier de débranchement dans la séquentialité de nos lectures.
Je suppose que c'est ce que vous nommez un saut quantique. Non, IDS II était très performant pour l'époque.

Citation:

Envoyé par Fsmrel

à l’époque, j’avais quand même plus de 20 ans d’assembleur quotidien dans les jambes

Le seul assembleur sur gros système que j'ai fait, est l'assembleur IBM 370. Je n'ai jamais fait d'assembleur sous BULL. Sinon, j'ai fait beaucoup de cobol mais pas que cela.

Citation:

Envoyé par Fsmrel

Et tu viens nous parler d’occupation mémoire, à une époque où le PC ...

On avait des terminaux pour accéder à BULL ou à IBM et non des PC.
Les premiers PC étaient des IBM avec le simulateur EXTRA, pour simuler des terminaux 3270.

Citation:

Envoyé par Fsmrel

Logique du 1er ordre = QUOI (une instruction) , code procédural = COMMENT (toile d’araignée d’instructions).

Il y a certainement un programme assembleur, voire une macro instruction ou de la micro-programmation qui réalise ce que vous nommez une instruction.
Ce que vous nommez "toile d'araignée d'instructions" reste un traitement qui dépend de celui qui l'a programmé.
Et j'ignore totalement ce que font ce QUOI et ce COMMENT. La comparaison s'arrête là.

Citation:

Envoyé par Fsmrel

Tu persistes dans le COMMENT et tes certitudes.

Bien sûr que je persiste car je sais comment gérer en mémoire des données.
Et en quoi les listes chaînées seraient si difficile à programmer ?

Citation:

Envoyé par Fsmrel

Si tu as une base de données de 1000 tables, avec le relationnel tu maîtrises, avec C/C++ c’est moins sûr, même si on te laisse beaucoup, beaucoup, beaucoup de temps, et même plus...

Comme je l'ai dit précédemment, faire du relationnel en "C/C++", je ne sais pas faire.
Je précise que je parle de développer une application qui simule du relationnel, c'est-à-dire réécrire les routines que l'on trouve dans un SGBD relationnel.
A l'inverse, faire des listes chaînes en simulant un SGBD réseau, je sais faire. Mais je pense que l'on ne se comprend pas bien sur ce sujet.

Citation:

Envoyé par Fsmrel

Voeu pieux ! Les liens (sets) CODASYL t’entravent les pieds...

Mais encore une fois, je ne dis pas le contraire sur la rigidité qu'offre le modèle réseau.
Je ne fais que parler des temps d'accès sur une organisation adaptée, c'est-à-dire basée sur une gestion des listes chaînées, à un problème donnée !
En quoi est-ce si difficile de croire que c'est moins performant que le modèle relationnel ?
Et ce n'est pas à tous les problèmes données que je vais appliquer cette organisation.

Citation:

Envoyé par Fsmrel

C’est un peu le discours que me tenaient les gens de chez Cullinet en 1987, rabâchant que DB2 était une brouette

A l'époque, j'aurai dit la même chose, vu que j'avais une compétence BULL, plutôt qu'IBM.
Quand vous parlez de votre expérience avec Cullinet, est-ce bien aux états-unis et non en France ?
Je ne me souviens pas d'un Cullinet en France, mais d'un Computer Associate ?

@+
15/09/2018, 19h33
escartefigue

Reconnaitre ses erreurs est toujours un peux douloureux, mais juste après, comprendre pourquoi on a fait fausse route et quel bénéfice on peut tirer de l'expérience nouvellement acquise est un moment d'enthousiasme, et une opportunité de progresser.
Il est temps de passer à l'étape 2 !
17/09/2018, 00h04
Artemus24

Salut Escartefigue.

Reconnaître quelles erreurs ?
Il ne faudrait pas faire du nombrilisme en croyant qu'il n'y a rien de mieux que le modèle relationnel.

Au travers du SGBD réseau, j'ai découvert la structure arborescente qui permet de gérer les relations entre données.
Elle a l'avantage de pouvoir structurer les données sur une représentation multidimension, ce que ne peux faire le relationnel qui est limité à 2.
Je ne me suis pas cantonné uniquement au SGBD réseau, et j'ai étudié la structure des données, la recherche opérationnelle et un peu l'intelligence artificielle.
Cette organisation, l'arborescence, je l'ai trouvé optimale, en terme de performance, au travers de procédure récursive.

Qu'est-ce qui empêche de structurer une base de données sur une organisation arborescente ?

Par la suite, en pratiquant le "C/C++", j'ai découvert la notion d'objet que je pratiquais déjà, sans le savoir avec les modules.
Dans cet notion d'objet, on pouvait définir des traitements (des classes) qui étaient associées à des données.
C'était une amélioration de l'approche de Wirth.
Le gros avantage était de pouvoir utiliser ces traitements (les instances) avec toute la souplesse que ne propose justement pas la programmation procédurale classique.
Ce qui donne une souplesse à la programmation, que l'on ne retrouve pas avec l'approche procédurale.

Il n'y avait qu'un pas pour associer au travers des bases de données, les objets avec une structure arborescente. C'est à cela que je veux arriver.

Il serait temps de comprendre les limites de l'approche ensembliste dans la résolution de certains problèmes.
Quand la volumétrie devient considérable, la performance devient exponentielle.
Tout ne peut pas se faire avec cette approche, même si elle couvre une grande majorité des problèmes rencontrés.
Je prends le cas de tout ce qui est combinatoire où l'arborescence est bien meilleure que l'approche ensembliste.

@+
17/09/2018, 01h42
fsmrel

Citation:

Envoyé par Artemus24

Cette organisation, l'arborescence, je l'ai trouvé optimale, en terme de performance, au travers de procédure récursive.

Même SQL permet évidemment de faire du récursif, avec même des structures d’arbres entremêlés...

Je te conseille d’étudier le relationnel avec Databases, Types, and the Relational Model, The Third Manifesto (je ne parle pas de SQL, que tu pratiques, mais qui est loin d’adhérer au relationnel).

Escartefigue,

Comme dit Saint Paul ( (Tt 3.10), laissons tomber. Artemus a une idée fixe et il n’en démordra pas. Il affirme sans rien démontrer (le relationnel s’écroule face à des « volumétries considérables »), il mélange les concepts (par exemple il confond traitement et classe).

Bref nous avons perdu assez de temps.
17/09/2018, 02h14
Artemus24

Salut Fsmrel.

Je ne cherche pas à polémiquer comme vous semblez le croire.
Le SGBD relationnel est puissant parce qu'il est souple à la modélisation et est performant dans la mesure où l'on sait modéliser correctement.
Il répond aux besoins de la plupart des entreprises du tertiaire, mais dès que l'on s'intéresse à l'industrie, les problèmes sont différents où la performance est critique.
Vous sembler convaincu qu'il n'y a rien de mieux que le relationnel. On peut se demander pourquoi il y a encore des recherche sur la modélisation.

Bien sur que j'ai une idée fixe, comme vous dites, mais je suis surpris que vous n'arrivez pas à me convaincre du bien fait du relationnel.
Cela ne veut pas dire que je rejette tout en bloc mais que j'essaye d'avoir une autre approche.
Oui, comme je l'ai déjà dit, je reconnais que l'approche par les liens chaînées et autres pointeurs est rigide.
Mais vous n'allez pas me faire croire que l'on va modifier tous les cinq minutes une modélisation de type relationnelle.
Donc l'argument souplesse est a revoir quand celle-ci est au détriment de la performance.

Je n'ai pas une connaissance poussée des bases de données comme vous, mais pourquoi une approche arborescente serait-elle moins performante que le relationnel ?
Et la théorie des graphes ? Les problèmes basées sur la recherche de chemin, comme le classique voyageur de commerce.
Plus la structure devient lourde et plus la performance devient exponentielle et non polynomiale comme elle se devrait.

Je pensais que vous auriez pu m'éclairer sur d'autres approches, sur d'autres organisations, sur d'autres façon de modéliser les données.
Je ne cherche pas des chiffres prouvant, il y a fort longtemps, que le concept SGBD réseau est moins performant.
Je cherche des arguments démontrant les limites du modèle relationnel.
Or je ressens une frustration car quoi que je dise, j'ai nécessairement tort.
Je ne m'exprime peut être pas comme vous le désirez, mais j'ai déjà connu sur un autre forum ce genre de communication à sens unique.
C'est dommage d'avoir vous aussi des idées arrêtés.

@+
19/09/2018, 01h37
SQLpro

Citation:

Envoyé par fsmrel

Comme dit Saint Paul ( (Tt 3.10), laissons tomber. Artemus a une idée fixe et il n’en démordra pas. Il affirme sans rien démontrer (le relationnel s’écroule face à des « volumétries considérables »), il mélange les concepts (par exemple il confond traitement et classe).

Bref nous avons perdu assez de temps.

Tu m'étonne, il y a longtemps que j'ai laissé tomber les âneries de notre Artémuse Gordon… Il est trop… comment dire ? - tiens un trou de mémoire !!! … pour que ça vaille la peine de perdre son temps !

Mais heureusement il ne sévit que dans le forum MySQmerde qui est à peu près en matière de BD relationnelle ce que la musique d'un pot d'échappement de torpédo est au bruit d'un orchestre symphonique…. J'ai par exemple tenté de lui faire comprendre ce qu'est l'optimisation sémantique… en vain !!!

A +