Comparatif SGBD (in Cahiers du Programmeur Mac OS X)
39 réponses
cfranco
Bonjour à tous,
J'ai sous les yeux un exemplaire du livre "Cahiers du Programmeur Mac OS
X" - excellente lecture, n'est-ce pas ? ;-) - et j'y lis (p.220) qu'on
peut trouver un comparatif des fonctionnalités des principaux SGBD
libres et commerciaux du marché sur le site de MySQL, à l'adresse :
http://www.mysql.com/crash-me-choose.html
Problème : l'adresse en question ne mène plus à rien, et j'ai eu beau
fouiller autant que possible le site de MySQL, je n'ai rien retrouvé de
tel.
Est-ce que quelqu'un aurait éventuellement archivé cette page à l'époque
où elle était là, ou bien aurait d'autres liens sur le même sujet ?
Tu mélanges tout parce qu'avec 4D ou FMP (ou autres, WinDev par exemple) tu as ensemble la base de donnée, et un front-end préprogrammé,
mais justement, c'est ce que je me tue à dire. cette dissociation est idiote ! je sais bien, justement, qu'il y a plein de gens qui, quand ils parlent de base de données, ne s'occuppe que de la base elle-eme, et ne s'occupent ni du front end ni du requeteur. Or, le front end est fondamental pour la qualité de la saisie (et donc des données). Et surtout, pour l'utilisation intelligente des données et donc l'utilité de la base, c'est la souplesse et l'ergonomie du requeteur qui est le plus important ! En fait, la base elle-meme n'a qu'une importance tout à fait secondaire.
Sauf que, un front-end de base de données, c'est fait pour afficher le contenu de la base, en lecture ou en édition, et puis c'est à peu près tout. Jusque là, ça va, et si l'utilisation de la base se limite à ça, et qu'il n'y a pas trop de contraintes de nombre d'utilisateurs ou de taille de base, ça peut rouler avec ce genre de produits, parce qu'effectivement les développements seront très limités (juste des écrans correspondant aux différentes vues). Là en effet, que ça soit fait avec Access, FMP, 4D ou autre, pourvu que ça soit bien fait et qu'on ne cherche pas à faire plus, ça devrait aller.
Maintenant, là où ça commence à être nettement plus génant, c'est quand on quitte ce mode de développement pour faire un logiciel qui utilise cette base certes, mais qui fait des tas d'autres choses. Du calcul scientifique par exemple, de la visualisation graphique 2D ou 3D avancée, des connexions avec du matériel... Là on sort franchement du domaine pour lequel ces front-ends ont été conçus, et c'est là qu'arrivent généralement les ennuis.
Or il est clair que dans la plupart des cas, avoir une base de données juste pour faire des requêtes dessus, aussi complexes soient-elles, est bien trop limité pour la plupart des applications. De plus en plus, la base de données n'est plus une fin en soi, mais un outil comme un autre, au même titre qu'un logiciel de calcul numérique, qu'un moteur de rendu 3D, qu'un système d'acquisition de mesures... C'est l'ensemble de tout ça qui est intéressant pour l'utilisateur.
Dès lors, l'erreur monumentale à ne pas faire est de partir du principe qu'il y a une base de données dans l'affaire, pour tout centrer dessus, en utilisant des outils qui certes peuvent limiter le volume de travail pour la base et sa consultation, mais qui l'augmentent dans des proportions exagérées (voir l'entravent) pour d'autres domaines de développement.
-- Christophe Franco
manet <pmanet@invivo.edu> wrote:
Christophe Franco <cfranco@pobox.com> wrote:
Tu mélanges tout parce qu'avec 4D ou FMP (ou autres, WinDev
par exemple) tu as ensemble la base de donnée, et un front-end
préprogrammé,
mais justement, c'est ce que je me tue à dire. cette dissociation est
idiote ! je sais bien, justement, qu'il y a plein de gens qui, quand ils
parlent de base de données, ne s'occuppe que de la base elle-eme, et ne
s'occupent ni du front end ni du requeteur. Or, le front end est
fondamental pour la qualité de la saisie (et donc des données). Et
surtout, pour l'utilisation intelligente des données et donc l'utilité
de la base, c'est la souplesse et l'ergonomie du requeteur qui est le
plus important !
En fait, la base elle-meme n'a qu'une importance tout à fait secondaire.
Sauf que, un front-end de base de données, c'est fait pour afficher le
contenu de la base, en lecture ou en édition, et puis c'est à peu près
tout. Jusque là, ça va, et si l'utilisation de la base se limite à ça,
et qu'il n'y a pas trop de contraintes de nombre d'utilisateurs ou de
taille de base, ça peut rouler avec ce genre de produits, parce
qu'effectivement les développements seront très limités (juste des
écrans correspondant aux différentes vues). Là en effet, que ça soit
fait avec Access, FMP, 4D ou autre, pourvu que ça soit bien fait et
qu'on ne cherche pas à faire plus, ça devrait aller.
Maintenant, là où ça commence à être nettement plus génant, c'est quand
on quitte ce mode de développement pour faire un logiciel qui utilise
cette base certes, mais qui fait des tas d'autres choses. Du calcul
scientifique par exemple, de la visualisation graphique 2D ou 3D
avancée, des connexions avec du matériel... Là on sort franchement du
domaine pour lequel ces front-ends ont été conçus, et c'est là
qu'arrivent généralement les ennuis.
Or il est clair que dans la plupart des cas, avoir une base de données
juste pour faire des requêtes dessus, aussi complexes soient-elles, est
bien trop limité pour la plupart des applications. De plus en plus, la
base de données n'est plus une fin en soi, mais un outil comme un autre,
au même titre qu'un logiciel de calcul numérique, qu'un moteur de rendu
3D, qu'un système d'acquisition de mesures... C'est l'ensemble de tout
ça qui est intéressant pour l'utilisateur.
Dès lors, l'erreur monumentale à ne pas faire est de partir du principe
qu'il y a une base de données dans l'affaire, pour tout centrer dessus,
en utilisant des outils qui certes peuvent limiter le volume de travail
pour la base et sa consultation, mais qui l'augmentent dans des
proportions exagérées (voir l'entravent) pour d'autres domaines de
développement.
Tu mélanges tout parce qu'avec 4D ou FMP (ou autres, WinDev par exemple) tu as ensemble la base de donnée, et un front-end préprogrammé,
mais justement, c'est ce que je me tue à dire. cette dissociation est idiote ! je sais bien, justement, qu'il y a plein de gens qui, quand ils parlent de base de données, ne s'occuppe que de la base elle-eme, et ne s'occupent ni du front end ni du requeteur. Or, le front end est fondamental pour la qualité de la saisie (et donc des données). Et surtout, pour l'utilisation intelligente des données et donc l'utilité de la base, c'est la souplesse et l'ergonomie du requeteur qui est le plus important ! En fait, la base elle-meme n'a qu'une importance tout à fait secondaire.
Sauf que, un front-end de base de données, c'est fait pour afficher le contenu de la base, en lecture ou en édition, et puis c'est à peu près tout. Jusque là, ça va, et si l'utilisation de la base se limite à ça, et qu'il n'y a pas trop de contraintes de nombre d'utilisateurs ou de taille de base, ça peut rouler avec ce genre de produits, parce qu'effectivement les développements seront très limités (juste des écrans correspondant aux différentes vues). Là en effet, que ça soit fait avec Access, FMP, 4D ou autre, pourvu que ça soit bien fait et qu'on ne cherche pas à faire plus, ça devrait aller.
Maintenant, là où ça commence à être nettement plus génant, c'est quand on quitte ce mode de développement pour faire un logiciel qui utilise cette base certes, mais qui fait des tas d'autres choses. Du calcul scientifique par exemple, de la visualisation graphique 2D ou 3D avancée, des connexions avec du matériel... Là on sort franchement du domaine pour lequel ces front-ends ont été conçus, et c'est là qu'arrivent généralement les ennuis.
Or il est clair que dans la plupart des cas, avoir une base de données juste pour faire des requêtes dessus, aussi complexes soient-elles, est bien trop limité pour la plupart des applications. De plus en plus, la base de données n'est plus une fin en soi, mais un outil comme un autre, au même titre qu'un logiciel de calcul numérique, qu'un moteur de rendu 3D, qu'un système d'acquisition de mesures... C'est l'ensemble de tout ça qui est intéressant pour l'utilisateur.
Dès lors, l'erreur monumentale à ne pas faire est de partir du principe qu'il y a une base de données dans l'affaire, pour tout centrer dessus, en utilisant des outils qui certes peuvent limiter le volume de travail pour la base et sa consultation, mais qui l'augmentent dans des proportions exagérées (voir l'entravent) pour d'autres domaines de développement.
-- Christophe Franco
Hubert Figuiere
Hormis le fait que le modèle de la base doit être du relationnel. SQL n'est pas du tout adapté pour l'interrogations de SGBD objets, par exemple. D'où d'ailleurs les OQL et variantes.
effectivement, ça s'interface assez mal avec Java...
Hormis le fait que le modèle de la base doit être du relationnel. SQL
n'est pas du tout adapté pour l'interrogations de SGBD objets, par
exemple. D'où d'ailleurs les OQL et variantes.
effectivement, ça s'interface assez mal avec Java...
Hormis le fait que le modèle de la base doit être du relationnel. SQL n'est pas du tout adapté pour l'interrogations de SGBD objets, par exemple. D'où d'ailleurs les OQL et variantes.
effectivement, ça s'interface assez mal avec Java...
A priori t'a pas suivi récemment un cours de base de données.
je dirais meme que je n'en ai jamais suivi !
bon, on t'apprendre autre chose que SQL.
ah, mais il existe certainement des tas de concepts interessant dans les labos ! mais des trucs qui existent réellement, je n'en ai jamais vu dans la réalité vraie. par exemple, ça fait un temps infini que j'entends parler de base objet. mais des produits qui tournent avec , je n'en ai jamais vu.
-- Philippe Manet
Hubert Figuiere <hub@free.fr> wrote:
A priori t'a pas suivi récemment un cours de base de données.
je dirais meme que je n'en ai jamais suivi !
bon, on t'apprendre autre chose que SQL.
ah, mais il existe certainement des tas de concepts interessant dans les
labos !
mais des trucs qui existent réellement, je n'en ai jamais vu dans la
réalité vraie.
par exemple, ça fait un temps infini que j'entends parler de base objet.
mais des produits qui tournent avec , je n'en ai jamais vu.
A priori t'a pas suivi récemment un cours de base de données.
je dirais meme que je n'en ai jamais suivi !
bon, on t'apprendre autre chose que SQL.
ah, mais il existe certainement des tas de concepts interessant dans les labos ! mais des trucs qui existent réellement, je n'en ai jamais vu dans la réalité vraie. par exemple, ça fait un temps infini que j'entends parler de base objet. mais des produits qui tournent avec , je n'en ai jamais vu.
-- Philippe Manet
pmanet
Hubert Figuiere wrote:
Et oui, 4D ca date de 1985 et ca a presque pas évolué.
c'est completement faux, mais ce n'est pas le problème. ce qui est très en retard, ce n'est pas les subtilités du langage utilisé, c'est le concept d'unicité du système qui en facilite la maintenance, la globalité de l'accès aux données qui en facilite l'interrogation et l'exploitation.
faire une requete dans FMP, la trier, et en exporter un sous ensemble quelconque et facilement redéfinissable pour l'utiliser dans un autre outil est disponible en standard sans programmation depuis que FMP existe, et c'est un truc qui sert vachement. je connais enormement de bases faite avec les outils dont tu parle, ouvert et tout ce que tu veux, avec lesquels c'est tout simplement inimaginable. Peux-tu m'expliquer en quoi c'est mieux ? Pour moi, ça disqualifie tout simplement ce genre d'outil, et ça marque un retard fonctionnel fondamental.
Et explique moi aussi pourquoi il est normal qu'on soit obligé de payer des DBA pour surveiller les index d'Oracle.
Parce que ce que tu dis (avec Christophe) est certainement vrai, mais je n'en vois pas l'interet pratique. Et aucun d'entre vous ne fait de vraie réponse à des critiques aussi simples. -- Philippe Manet
Hubert Figuiere <hub@free.fr> wrote:
Et oui, 4D
ca date de 1985 et ca a presque pas évolué.
c'est completement faux, mais ce n'est pas le problème.
ce qui est très en retard, ce n'est pas les subtilités du langage
utilisé, c'est le concept d'unicité du système qui en facilite la
maintenance, la globalité de l'accès aux données qui en facilite
l'interrogation et l'exploitation.
faire une requete dans FMP, la trier, et en exporter un sous ensemble
quelconque et facilement redéfinissable pour l'utiliser dans un autre
outil est disponible en standard sans programmation depuis que FMP
existe, et c'est un truc qui sert vachement.
je connais enormement de bases faite avec les outils dont tu parle,
ouvert et tout ce que tu veux, avec lesquels c'est tout simplement
inimaginable. Peux-tu m'expliquer en quoi c'est mieux ? Pour moi, ça
disqualifie tout simplement ce genre d'outil, et ça marque un retard
fonctionnel fondamental.
Et explique moi aussi pourquoi il est normal qu'on soit obligé de payer
des DBA pour surveiller les index d'Oracle.
Parce que ce que tu dis (avec Christophe) est certainement vrai, mais je
n'en vois pas l'interet pratique.
Et aucun d'entre vous ne fait de vraie réponse à des critiques aussi
simples.
--
Philippe Manet
pmanet@invivo.edu
Et oui, 4D ca date de 1985 et ca a presque pas évolué.
c'est completement faux, mais ce n'est pas le problème. ce qui est très en retard, ce n'est pas les subtilités du langage utilisé, c'est le concept d'unicité du système qui en facilite la maintenance, la globalité de l'accès aux données qui en facilite l'interrogation et l'exploitation.
faire une requete dans FMP, la trier, et en exporter un sous ensemble quelconque et facilement redéfinissable pour l'utiliser dans un autre outil est disponible en standard sans programmation depuis que FMP existe, et c'est un truc qui sert vachement. je connais enormement de bases faite avec les outils dont tu parle, ouvert et tout ce que tu veux, avec lesquels c'est tout simplement inimaginable. Peux-tu m'expliquer en quoi c'est mieux ? Pour moi, ça disqualifie tout simplement ce genre d'outil, et ça marque un retard fonctionnel fondamental.
Et explique moi aussi pourquoi il est normal qu'on soit obligé de payer des DBA pour surveiller les index d'Oracle.
Parce que ce que tu dis (avec Christophe) est certainement vrai, mais je n'en vois pas l'interet pratique. Et aucun d'entre vous ne fait de vraie réponse à des critiques aussi simples. -- Philippe Manet
pmanet
Christophe Franco wrote:
Du calcul scientifique par exemple, de la visualisation graphique 2D ou 3D avancée, des connexions avec du matériel... Là on sort franchement du domaine pour lequel ces front-ends ont été conçus, et c'est là qu'arrivent généralement les ennuis. Or il est clair que dans la plupart des cas, avoir une base de données juste pour faire des requêtes dessus, aussi complexes soient-elles, est bien trop limité pour la plupart des applications. De plus en plus, la base de données n'est plus une fin en soi, mais un outil comme un autre, au même titre qu'un logiciel de calcul numérique, qu'un moteur de rendu 3D, qu'un système d'acquisition de mesures...
effectivement, on est alors obligé d'utiliser (ou de developper) des plugins, et on retrouve alors tous les défauts d'évolutivité que je signalais ; s'ils sont plus limités (seulement le plugin), ils sont effectivement plus difficile à traiter du fait de la mauvaise documentation.
mais dans l'immense champs des bases de données, ces cas restent l'exception. Des solutions différentes comme des connexions avec des outils spécifiques par message standardisé sont souvent préférables ; chez nous, on renonce de plus en plus aux API. -- Philippe Manet
Christophe Franco <cfranco@pobox.com> wrote:
Du calcul
scientifique par exemple, de la visualisation graphique 2D ou 3D
avancée, des connexions avec du matériel... Là on sort franchement du
domaine pour lequel ces front-ends ont été conçus, et c'est là
qu'arrivent généralement les ennuis.
Or il est clair que dans la plupart des cas, avoir une base de données
juste pour faire des requêtes dessus, aussi complexes soient-elles, est
bien trop limité pour la plupart des applications. De plus en plus, la
base de données n'est plus une fin en soi, mais un outil comme un autre,
au même titre qu'un logiciel de calcul numérique, qu'un moteur de rendu
3D, qu'un système d'acquisition de mesures...
effectivement, on est alors obligé d'utiliser (ou de developper) des
plugins, et on retrouve alors tous les défauts d'évolutivité que je
signalais ; s'ils sont plus limités (seulement le plugin), ils sont
effectivement plus difficile à traiter du fait de la mauvaise
documentation.
mais dans l'immense champs des bases de données, ces cas restent
l'exception. Des solutions différentes comme des connexions avec des
outils spécifiques par message standardisé sont souvent préférables ;
chez nous, on renonce de plus en plus aux API.
--
Philippe Manet
pmanet@invivo.edu
Du calcul scientifique par exemple, de la visualisation graphique 2D ou 3D avancée, des connexions avec du matériel... Là on sort franchement du domaine pour lequel ces front-ends ont été conçus, et c'est là qu'arrivent généralement les ennuis. Or il est clair que dans la plupart des cas, avoir une base de données juste pour faire des requêtes dessus, aussi complexes soient-elles, est bien trop limité pour la plupart des applications. De plus en plus, la base de données n'est plus une fin en soi, mais un outil comme un autre, au même titre qu'un logiciel de calcul numérique, qu'un moteur de rendu 3D, qu'un système d'acquisition de mesures...
effectivement, on est alors obligé d'utiliser (ou de developper) des plugins, et on retrouve alors tous les défauts d'évolutivité que je signalais ; s'ils sont plus limités (seulement le plugin), ils sont effectivement plus difficile à traiter du fait de la mauvaise documentation.
mais dans l'immense champs des bases de données, ces cas restent l'exception. Des solutions différentes comme des connexions avec des outils spécifiques par message standardisé sont souvent préférables ; chez nous, on renonce de plus en plus aux API. -- Philippe Manet
nospam
manet wrote:
Et explique moi aussi pourquoi il est normal qu'on soit obligé de payer des DBA pour surveiller les index d'Oracle.
En même temps on ne gère pas la même chose (en termes de volume , complexité) avec FMP et Oracle ...
Et explique moi aussi pourquoi il est normal qu'on soit obligé de payer des DBA pour surveiller les index d'Oracle.
Parce que FMP, avec 1756823468436 enregistrements, il perd les pédales.
-- Jacques
pmanet
Romuald Brunet wrote:
En même temps on ne gère pas la même chose (en termes de volume , complexité) avec FMP et Oracle ...
peut-etre. Ne parlons pas des secteurs dans lesquels oracle et DB2 se disputent le marché, mais des bases utilisées dans des boites petites et moyennes, jusqu'à quelques milliers d'employés et une gestion de données standards.
mais je vois de plus en plus oracle utilisé pour des systèmes dans lesquelles aucune table ne dépasse le million d'enregistrement et le volume total reste inférieur à quelques GO. Et ça, FMP le gère très tranquillement.
En revanche, je n'ai pas l"expérience de FMP serveur et de sa tenue à la charge, mais les gens qui s'en servent sur de gros systèmes NT en semblent contents. Notons que jusqu'ici, le fonctionnement en serveur sur OSX semblait assez aléatoire...
-- Philippe Manet
Romuald Brunet <nospam@chivil.com> wrote:
En même temps on ne gère pas la même chose (en termes de volume ,
complexité) avec FMP et Oracle ...
peut-etre. Ne parlons pas des secteurs dans lesquels oracle et DB2 se
disputent le marché, mais des bases utilisées dans des boites petites et
moyennes, jusqu'à quelques milliers d'employés et une gestion de données
standards.
mais je vois de plus en plus oracle utilisé pour des systèmes dans
lesquelles aucune table ne dépasse le million d'enregistrement et le
volume total reste inférieur à quelques GO.
Et ça, FMP le gère très tranquillement.
En revanche, je n'ai pas l"expérience de FMP serveur et de sa tenue à la
charge, mais les gens qui s'en servent sur de gros systèmes NT en
semblent contents. Notons que jusqu'ici, le fonctionnement en serveur
sur OSX semblait assez aléatoire...
En même temps on ne gère pas la même chose (en termes de volume , complexité) avec FMP et Oracle ...
peut-etre. Ne parlons pas des secteurs dans lesquels oracle et DB2 se disputent le marché, mais des bases utilisées dans des boites petites et moyennes, jusqu'à quelques milliers d'employés et une gestion de données standards.
mais je vois de plus en plus oracle utilisé pour des systèmes dans lesquelles aucune table ne dépasse le million d'enregistrement et le volume total reste inférieur à quelques GO. Et ça, FMP le gère très tranquillement.
En revanche, je n'ai pas l"expérience de FMP serveur et de sa tenue à la charge, mais les gens qui s'en servent sur de gros systèmes NT en semblent contents. Notons que jusqu'ici, le fonctionnement en serveur sur OSX semblait assez aléatoire...
-- Philippe Manet
pmanet
Jacques Foucry wrote:
Parce que FMP, avec 1756823468436 enregistrements, il perd les pédales.
moui, quand chaque rubrique dépasse les 10 TO, ça doit devenir un peu difficile... surtout si tu recommence un tri alphabétique chaque fois que tu rajoute une ligne. Mais bon, y'en a beaucoup, en France, des bases Access (voire meme Oracle...) qui gèrent ce genre de base ?
parce que la question initiale, c'était de remplacer une base Acces... -- Philippe Manet
Jacques Foucry <nospam@foucry.net.invalid> wrote:
Parce que FMP, avec 1756823468436 enregistrements, il perd les pédales.
moui, quand chaque rubrique dépasse les 10 TO, ça doit devenir un peu
difficile... surtout si tu recommence un tri alphabétique chaque fois
que tu rajoute une ligne.
Mais bon, y'en a beaucoup, en France, des bases Access (voire meme
Oracle...) qui gèrent ce genre de base ?
parce que la question initiale, c'était de remplacer une base Acces...
--
Philippe Manet
pmanet@invivo.edu
Parce que FMP, avec 1756823468436 enregistrements, il perd les pédales.
moui, quand chaque rubrique dépasse les 10 TO, ça doit devenir un peu difficile... surtout si tu recommence un tri alphabétique chaque fois que tu rajoute une ligne. Mais bon, y'en a beaucoup, en France, des bases Access (voire meme Oracle...) qui gèrent ce genre de base ?
parce que la question initiale, c'était de remplacer une base Acces... -- Philippe Manet
