Déjà faut pas confondre la capacité relationnelle (JOIN etc) avec les clés étrangères.[/quote]
Exact on attends en principe de moteur de base de données relationnel qu’ils soient en mesure de définir des relations avec un certains nombre de garanties. Cela se fait grâces aux clef étrangère. Les JOIN dont tu parle n’étant que le langage de requêtage. Tu parle de la manière de l’utiliser et non du modèle des données.
Pouvoir définir des relations dans ces données, il me semble que oui.
Ce n’est pas parce que quelque chose marche même en production que c’est bien ou que ça implémente ce qu’il faut. Des centaines de milliers d’iPhones ont étaient vendu sans qu’ils aient la capacité de lire des MMS.
Cette incapacité de MySQL à gérer les clefs étrangères est pour moi un point qui ne passeras jamais, se SGBD a un succès qu’il ne mérite pas selon moi, alors que postgre n’a pas le succès qu’il mérite.
Après SQLite est particulier, les développeurs mettent la priorité sur les ressources utilisées, SQLite il gère à sa manière les propriétés ACID et qu’ils ont une gestion des types particulière. Certains le considèrent plus ou moins comme du NoSQL déjà.
[quote=“MisterFreez”]Tu parle de la manière de l’utiliser et non du modèle des données.
Pouvoir définir des relations dans ces données, il me semble que oui.[/quote]
J’admets que j’ai fait un raccourci en donnant le JOIN comme exemple, mais pour moi ça ne change pas le fond.
Puisqu’on est partis à pinailler je dirai simplement que le modèle de données (abstrait) est totalement indépendant du fait que le moteur fasse (ou pas) respecter les contraintes.
La capacité relationnelle d’une base est (comme son nom l’indique) la capacité à mettre les données en relation. La vérification automatique des clés étrangères n’est qu’une toute petite partie de cette capacité, et n’est absolument pas nécessaire à l’intégrité d’une base.
Quand on dit que quelque chose fait partie de « la base » ça veut dire que c’est le strict minimum pour que l’ensemble soit fonctionnel, non ? Partant de là, la vérification des clés étrangères ne fait pas partie de « la base » même si c’est un plus, d’autant que cette fonctionnalité peut très facilement être implémentée avec les outils standard quand on en a vraiment besoin (ici, du pseudo-code) :
[code]if (!execute_query(“INSERT INTO table (champ) VALUES(valeur)”))
{
// erreur SI le moteur supporte la vérification automatique des clés étrangères
}
if (!execute_query(“INSERT INTO table (champ) SELECT valeur FROM table_maitre WHERE id=valeur”) || (affected_rows() != 1))
{
// erreur quelques soient les fonctionnalités du moteur
}[/code]
Ou bien en SQL (ici, du SQLite, mais n’importe quel moteur a des fonctions équivalentes) :
$ sqlite3 test.db
SQLite version 3.7.9 2011-11-01 00:52:41
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> CREATE TABLE master (id INTEGER PRIMARY KEY);
sqlite> CREATE TABLE slave (mid INTEGER);
sqlite> INSERT INTO slave (mid) SELECT 1 FROM master WHERE id=1;
sqlite> SELECT changes();
0
sqlite> INSERT INTO master (id) VALUES (1);
sqlite> INSERT INTO slave (mid) SELECT 1 FROM master WHERE id=1;
sqlite> SELECT changes();
1
Accessoirement, les clés étrangères n’ont été implémentées qu’avec la version 3.6.19 (octobre 2009), ce qui n’a jamais empêché SQLite d’avoir des utilisateurs high-profile avant ça (cf. sqlite.org/famous.html). Si cette fonctionnalité faisait vraiment partie de « la base » (autrement dit, nécessaire pour toute appli digne de ce nom) faudra m’expliquer pourquoi Airbus a osé l’utiliser pour son A350 XWB dont le proto était censé fonctionner dès 2009 (donc, avant que les clés étrangères ne soient implémentées).
Et pour avoir travaillé quelque temps dans le secteur de l’aviation, je peux te garantir que c’est loin d’être des rigolos, et qu’ils ne laissent rien au hasard (encore heureux, vu les vies en jeu…).
Je n’ai jamais envoyé un seul MMS, j’en ai reçu UN (auquel j’ai répondu : renvoie moi le truc par mail, car en l’état ça m’est totalement inutile). Mauvais exemple, car au moins la vérification automatique des clés étrangères peut avoir une utilité, elle, contrairement à ce gadget que sont les MMS… (mauvaise foi inside)
Ça n’a pas la même utilité. MySQL et SQLite (avant qu’il intègre la gestion des clés étrangères) méritent totalement leur succès car ils répondent à des besoins précis, y’a pas à chercher plus loin. En pratique, même sur des grosses applis client/serveur (clients lourds, qui plus est – edit : en 3 tiers, je précise) je n’ai quasiment jamais besoin de vérifier les clés étrangères (que ce soit automatiquement grâce au moteur ou en rusant comme montré ci-dessus) car l’intégrité est respectée bien en amont, la base de données n’est qu’un espace de stockage et les invariants du code lui-même font qu’une vérification des clés étrangères ne serait au final qu’une perte de performances.
Edit : d’ailleurs MySQL gère très bien l’intégrité référentielle à partir du moment où tu utilises des tables InnoDB.
Bon, globalement j’ai bien fais d’installer PostgreSQL??
Sur l’ensemble des websites visités, celui ci est préférable à MySQL mais, peut être lésé par une popularité moindre, les tutos ne sont pas légions sur le web, alors que MySQL…
[quote=“syam”]J’admets que j’ai fait un raccourci en donnant le JOIN comme exemple, mais pour moi ça ne change pas le fond.
Puisqu’on est partis à pinailler je dirai simplement que le modèle de données (abstrait) est totalement indépendant du fait que le moteur fasse (ou pas) respecter les contraintes.[/quote]
Ton modèle défini la relation entre les attributs. Si tu n’es pas capable de restituer la totalité des informations contenu dans ton modèle relationnel dans ta base de données, je ne vois pas comment dire que celle-ci est relationnelle. Note que pour MySQL, tu peut t’en sortir avec des triggers mais c’est se prendre la tête face à une vraie gestion de clef étrangère.
Les bases de données orientées document, orientée colonne, orientée clef-valeur, les bases de données graphes et les bases de données hiérachiques sont toutes relationnelles d’après toi ?
Sans clef-étrangère, le SGBD n’a pas connaissance des relations, donc le concept relationnel deviens bien abstrait pour lui.
C’est un peu comme d’expliquer que l’héritage ne fait pas partie de la base des concepts de l’orienté objet parce qu’on peut très bien le refaire avec de la composition et des interfaces.
Le code que tu montre fonctionne. Le problème c’est que la maintenabilité s’en trouve bien plus lourde. Plus les requêtes sont complexes plus elles sont sujettes aux bugs. Plus le projet est grand plus, plus c’est problématique.
[quote=“syam”]Accessoirement, les clés étrangères n’ont été implémentées qu’avec la version 3.6.19 (octobre 2009), ce qui n’a jamais empêché SQLite d’avoir des utilisateurs high-profile avant ça (cf. sqlite.org/famous.html). Si cette fonctionnalité faisait vraiment partie de « la base » (autrement dit, nécessaire pour toute appli digne de ce nom) faudra m’expliquer pourquoi Airbus a osé l’utiliser pour son A350 XWB dont le proto était censé fonctionner dès 2009 (donc, avant que les clés étrangères ne soient implémentées).
Et pour avoir travaillé quelque temps dans le secteur de l’aviation, je peux te garantir que c’est loin d’être des rigolos, et qu’ils ne laissent rien au hasard (encore heureux, vu les vies en jeu…).[/quote]
Je n’est rien contre SQLite loin de là. SQLite c’est fait pour des cas relativement particulier par rapport aux usages de bases de données comme Oracle, DB2 ou PG et c’est aussi pour cela qu’ils se permettent de ne pas respecter le modèle relationnel (et c’est l’une de leur grande qualité).
Tu a vu la gueule des modèles de données utilisés ? Une grande partie des utilisateurs de MySQL ne savent pas ce que c’est qu’une forme normale à partir de là le fait d’avoir de l’intégrité référentiel deviens secondaire …
MySQL a du succès car il est arrivé au bon moment. SQLite car il traite des cas particulier qu’aucun autre SGBD ne gère (en fait si derby le fait pour Java).
Oui tu n’utilise pas de fonctionnalité relationnelle.
Je n’es jamais dis qu’une base de données n’était bien que si elle était relationnelle (au contraire je m’intéresse beaucoup au NoSQL)(en fait si je l’ai laissé entendre mea maxima culpa). Je dis que la base du relationnel c’est les clefs étrangères.
Je me rend compte maintenant que je suis partie un peu vite ce matin (pas bien réveillé ?). Disons que pour moi un SGBD qui ne gère pas des clef étrangère (donc MySQL avec MyISAM) n’est pas un SGBDR, mais ça ne l’empêche pas d’avoir un grand nombre de qualités.
Bon effectivement, après vérification il apparaît que la définition même de « modèle relationnel » implique que les relations soient stockées dans le catalogue et non pas seulement dans la logique du programme client. Ça m’apprendra à négliger la partie théorique…
Cela dit j’étais pas loin, vu que c’est le seul point sur lequel “ma” définition diffère de la définition officielle.
Bof tu sais je ne m’y suis jamais intéressé non plus, ce qui ne m’empêche pas de constater (après m’être rapidement documenté sur le sujet) que je modélise mes données quasi-systématiquement en FNDC, et toujours à minima en 3FN (avec une concession tout de même : les enregistrements d’archive qui représentent un état à un point donné dans le passé, où j’ajoute souvent de la redondance pour augmenter les performances en consultation – ce qui n’est pas gênant étant donné que ces enregistrements sont immuables).
Je dirais plutôt que c’est comme d’expliquer que la notion d’interface ne fait pas partie de la base des concepts de l’OO, car on peut très bien l’implémenter à coups d’héritage de classes abstraites pures (cf. le modèle objet de C++). (comment ça je cherche ? )
–
Bref, je constate (encore une fois) qu’on est d’accord sur le fond, et que c’est principalement la forme qui pose problème… ce qui n’est pas étonnant étant donné que (vu la manière dont tu t’exprimes et les sujets que tu amènes) tu as très probablement eu une formation théorique conséquente, ce qui n’est absolument pas mon cas (formation 100% sur le tas).
[quote=“syam”]Bon effectivement, après vérification il apparaît que la définition même de « modèle relationnel » implique que les relations soient stockées dans le catalogue et non pas seulement dans la logique du programme client. Ça m’apprendra à négliger la partie théorique…
Cela dit j’étais pas loin, vu que c’est le seul point sur lequel “ma” définition diffère de la définition officielle. [/quote]
Bof tu sais je ne m’y suis jamais intéressé non plus, ce qui ne m’empêche pas de constater (après m’être rapidement documenté sur le sujet) que je modélise mes données quasi-systématiquement en FNDC, et toujours à minima en 3FN (avec une concession tout de même : les enregistrements d’archive qui représentent un état à un point donné dans le passé, où j’ajoute souvent de la redondance pour augmenter les performances en consultation – ce qui n’est pas gênant étant donné que ces enregistrements sont immuables).[/quote]
C’est pas toi qui a eu affaire à des bases qui ne sont même pas en première forme normale (attributs multivalués). Je te garantis que d’avoir des champs de la forme :
clef=valeur;clef=;clef=valeur ; clef= ;
Ça donne envi de jeter par la fenêtre l’auteur (non pas que j’aime pas les expressions rationnelles, au contraire, juste que j’aime utiliser mes outils de manière adaptée).
Je dirais plutôt que c’est comme d’expliquer que la notion d’interface ne fait pas partie de la base des concepts de l’OO, car on peut très bien l’implémenter à coups d’héritage de classes abstraites pures (cf. le modèle objet de C++). (comment ça je cherche ? )[/quote]
Le C++ ne suit pas bien le modèle objet de toute manière (tu peut avoir des fonctions hors de classe, tu en est même obligé pour la fonction main, il possède des types qui ne sont pas des classes, tu peut passer des méthodes en paramètre d’autres méthodes, etc).
Je suis titulaire (enfin je présume) d’un master en génie informatique. Je suis parti un peu vite mais d’une manière général j’aime bien les débats techniques ça permet de remettre en cause certaines idées qu’on a et de se poser des questions.
Effectivement, je n’ai jamais été confronté à ce genre d’aberrations. Le premier qui me pond une saloperie pareille je crois que je réagirais très mal, il a intérêt à courir vite…
En même temps, c’est un peu un langage multi-paradigmes… (et ma remarque précédente à propos des interfaces était un peu un troll )
Oui, ça peut jamais faire de mal. La preuve : je me coucherai moins con maintenant que j’ai un nom à mettre sur la manière dont je modélise mes données, et que je connais la définition correcte de « relationnel ».
J’ai plus qu’à y trouver une utilité pratique maintenant…
J’avoue que je suis comme ça de nature… Et parfois, échanger par écrit ne me facilite pas le “dialogue” car les émotions ne sont pas forcément retranscrites tel que je l’aurais souhaité.
J’avoue que je suis comme ça de nature… Et parfois, échanger par écrit ne me facilite pas le “dialogue” car les émotions ne sont pas forcément retranscrites tel que je l’aurais souhaité. [/quote]
Et puis quand en face t’as un zozo comme moi qui ne lâche rien tant que tu ne m’as pas prouvé que j’ai tort, ça aide pas…
J’avoue que je suis comme ça de nature… Et parfois, échanger par écrit ne me facilite pas le “dialogue” car les émotions ne sont pas forcément retranscrites tel que je l’aurais souhaité. [/quote]
Ma signature n’est pas là par hasard
je dirai simplement que le modèle de données (abstrait) est totalement indépendant du fait que le moteur fasse (ou pas) respecter les contraintes.
(mauvaise foi inside)
je dirai simplement que le modèle de données (abstrait) est totalement indépendant du fait que le moteur fasse (ou pas) respecter les contraintes.[/quote]
)
[/quote]
