> mais que le développeur ne devrait plus avoir a se taper toutes les requetes sql bidons update, insert et delete par exemple pour gérer les données.
On est d'accord, mais tu fais du hors-sujet. Ce que tu dis est valable pour tous les développements et n'est absolument pas spécifique aux SGBD.
Si je prend l'exemple de la gestion d'utilisation.
SGBD : stockage et gestion des données. C'est le SGBD qui va vérifier qu'il n'y a pas de doublon dans les ID par exemple. Utilisation de SQL car on est au niveau des données.
Applicatif : utilisation de adduser(), deluser(), etc... et non de SQL car on est au niveau applicatif et pas donné. adduser() ajoute un utilisateur (point de vu applicatif) et n'ajoute pas un enregistrement à une table (sous Unix il y a "adduser" et pas "add_one_record_to_etc_passwd" (alors que cette fonction doit bien exister :-) )). Que ça utilise une base de donnée relationnelle ou que ça tripote /etc/passwd, au niveau applicatif on s'en fout. De même, avant de faire adduser() on ne va pas vérifier s'il y a doublon ou non. C'est le SGBD (ou autre) qui le fera (comme il gèrera les accès en écriture concurrent, etc). C'est ici (niveau applicatif) qu'on ajoutera une aide contextuelle etc car ce n'est pas lié aux données.
Notes que si tu laisses l'applicatif (ou une librairie) s'occuper de l'intégrité des données (par exemples comme avec Mysql) il est impossible de faire un backup à chaud avec des données cohérentes. Dans ce cas il y a toujours des moments ou les données sont incohérentes. C'est obligé ou alors tu as une base vraiment simple.
Si tu prends PostgreSQL et tu l'utilises comme Mysql, tes backups à chaud ne valent presque rien si les contrôles d'intégrités (contrainte/transaction/etc) ne sont pas fait au niveau du SGBD. Que t'utilise un ejb ne change rien à la problématique.
Bref, encore une fois tu décris les avantages d'avoir une abstraction supplémentaire par rapport à SQL. Tu n'as pas à me convaincre de ça mais c'est du hors-sujet.
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
On est d'accord, mais tu fais du hors-sujet. Ce que tu dis est valable pour tous les développements et n'est absolument pas spécifique aux SGBD.
Si je prend l'exemple de la gestion d'utilisation.
SGBD : stockage et gestion des données. C'est le SGBD qui va vérifier qu'il n'y a pas de doublon dans les ID par exemple. Utilisation de SQL car on est au niveau des données.
Applicatif : utilisation de adduser(), deluser(), etc... et non de SQL car on est au niveau applicatif et pas donné. adduser() ajoute un utilisateur (point de vu applicatif) et n'ajoute pas un enregistrement à une table (sous Unix il y a "adduser" et pas "add_one_record_to_etc_passwd" (alors que cette fonction doit bien exister :-) )). Que ça utilise une base de donnée relationnelle ou que ça tripote /etc/passwd, au niveau applicatif on s'en fout. De même, avant de faire adduser() on ne va pas vérifier s'il y a doublon ou non. C'est le SGBD (ou autre) qui le fera (comme il gèrera les accès en écriture concurrent, etc). C'est ici (niveau applicatif) qu'on ajoutera une aide contextuelle etc car ce n'est pas lié aux données.
Notes que si tu laisses l'applicatif (ou une librairie) s'occuper de l'intégrité des données (par exemples comme avec Mysql) il est impossible de faire un backup à chaud avec des données cohérentes. Dans ce cas il y a toujours des moments ou les données sont incohérentes. C'est obligé ou alors tu as une base vraiment simple.
Si tu prends PostgreSQL et tu l'utilises comme Mysql, tes backups à chaud ne valent presque rien si les contrôles d'intégrités (contrainte/transaction/etc) ne sont pas fait au niveau du SGBD. Que t'utilise un ejb ne change rien à la problématique.
Bref, encore une fois tu décris les avantages d'avoir une abstraction supplémentaire par rapport à SQL. Tu n'as pas à me convaincre de ça mais c'est du hors-sujet.