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 ?
Je vois pas le rapport entre l'enseignement dans les cursus Informatique et le fait qu'il soit dur de trouver des "développeur" sur un truc propriétaire.
le rapport, c'est que plein de petits jeunes sortant des cursus en question ne savent meme pas qu'il existe autre chose que le SQL pour faire des bases de données. Et que ces trucs permettent de résoudre avec facilité et élégance la plupart des problèmes. Quand on leur montre, ça leur troue le cul.
et l'enseignement, c'est censé te donner un aperçu le plus large possible de ce qui existe pour résoudre un problème, et pas t'enfermer dans des solutions des années 70.
-- Philippe Manet
Hubert Figuiere <hub@free.fr> wrote:
Je vois pas le rapport entre l'enseignement dans les cursus
Informatique et le fait qu'il soit dur de trouver des "développeur"
sur un truc propriétaire.
le rapport, c'est que plein de petits jeunes sortant des cursus en
question ne savent meme pas qu'il existe autre chose que le SQL pour
faire des bases de données. Et que ces trucs permettent de résoudre avec
facilité et élégance la plupart des problèmes. Quand on leur montre, ça
leur troue le cul.
et l'enseignement, c'est censé te donner un aperçu le plus large
possible de ce qui existe pour résoudre un problème, et pas t'enfermer
dans des solutions des années 70.
Je vois pas le rapport entre l'enseignement dans les cursus Informatique et le fait qu'il soit dur de trouver des "développeur" sur un truc propriétaire.
le rapport, c'est que plein de petits jeunes sortant des cursus en question ne savent meme pas qu'il existe autre chose que le SQL pour faire des bases de données. Et que ces trucs permettent de résoudre avec facilité et élégance la plupart des problèmes. Quand on leur montre, ça leur troue le cul.
et l'enseignement, c'est censé te donner un aperçu le plus large possible de ce qui existe pour résoudre un problème, et pas t'enfermer dans des solutions des années 70.
-- Philippe Manet
pmanet
Christophe Franco wrote:
Cela dit, PHP/MySQL n'est pas le meilleur exemple, loin de là.
oui, mais c'est celui qu'on trouve le plus, je suppose que c'est parce qu'il est le plus facile à utiliser et à télécharger... -- Philippe Manet
Christophe Franco <cfranco@pobox.com> wrote:
Cela
dit, PHP/MySQL n'est pas le meilleur exemple, loin de là.
oui, mais c'est celui qu'on trouve le plus, je suppose que c'est parce
qu'il est le plus facile à utiliser et à télécharger...
--
Philippe Manet
pmanet@invivo.edu
Cela dit, PHP/MySQL n'est pas le meilleur exemple, loin de là.
oui, mais c'est celui qu'on trouve le plus, je suppose que c'est parce qu'il est le plus facile à utiliser et à télécharger... -- Philippe Manet
pmanet
Christophe Franco 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.
Et c'est la raison pour laquelle les bases faites avec des intégrés sont presque toujours meilleures à l'usage.
D'ailleurs, quand on programme avec 4D ou FMP, on passe beaucoup plus de temps sur ces interfaces que sur la base elle-meme. Et j'ai souvent l'impression que pour les systèmes dissociés, c'est l'inverse. Le front end de saisie est complétement baclé voire confié à des stagiaires (on m'a livré des écrans de saisie dans lesquels, quand on cliquait dans un champs, le curseur se positionnait dans un autre à l'opposé de l'écran ; merci Cap Gemini !), et le requeteur indigent.
-- Philippe Manet
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.
Et c'est la raison pour laquelle les bases faites avec des intégrés sont
presque toujours meilleures à l'usage.
D'ailleurs, quand on programme avec 4D ou FMP, on passe beaucoup plus de
temps sur ces interfaces que sur la base elle-meme. Et j'ai souvent
l'impression que pour les systèmes dissociés, c'est l'inverse.
Le front end de saisie est complétement baclé voire confié à des
stagiaires (on m'a livré des écrans de saisie dans lesquels, quand on
cliquait dans un champs, le curseur se positionnait dans un autre à
l'opposé de l'écran ; merci Cap Gemini !), et le requeteur indigent.
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.
Et c'est la raison pour laquelle les bases faites avec des intégrés sont presque toujours meilleures à l'usage.
D'ailleurs, quand on programme avec 4D ou FMP, on passe beaucoup plus de temps sur ces interfaces que sur la base elle-meme. Et j'ai souvent l'impression que pour les systèmes dissociés, c'est l'inverse. Le front end de saisie est complétement baclé voire confié à des stagiaires (on m'a livré des écrans de saisie dans lesquels, quand on cliquait dans un champs, le curseur se positionnait dans un autre à l'opposé de l'écran ; merci Cap Gemini !), et le requeteur indigent.
-- Philippe Manet
pmanet
Christophe Franco wrote:
Maintenant, tout le monde (tous les éditeurs de logiciels je parle) n'a pas la volonté de laisser les utilisateurs faire leurs propres requêtes sur la base... Parce que ça veut dire qu'ils ne sont plus prisonniers de cette base précisément, qu'ils peuvent donc se passer des services de ceux qui l'ont vendue... Et tous les clients ne mesurent pas forcément l'importance de cela.
c'est tout à fait vrai ; et maintenant, meme 4D et FMP permettent de verrouiller l'accès aux dialogues de recherche, d'export, etc... mais c'est une démarche volontaire du programmeur ; alors que pour permettre sur Oracle (ou Access...) l'export du résultat de n'importe quelle recherche qu'on vient de pratiquer, oualou.
meme chose, d'ailleurs, pour l'import. Encore une grosse tare, que j'avais oubliée, de tous ces systèmes. -- Philippe Manet
Christophe Franco <cfranco@pobox.com> wrote:
Maintenant, tout le monde (tous les éditeurs de logiciels je parle) n'a
pas la volonté de laisser les utilisateurs faire leurs propres requêtes
sur la base... Parce que ça veut dire qu'ils ne sont plus prisonniers de
cette base précisément, qu'ils peuvent donc se passer des services de
ceux qui l'ont vendue... Et tous les clients ne mesurent pas forcément
l'importance de cela.
c'est tout à fait vrai ; et maintenant, meme 4D et FMP permettent de
verrouiller l'accès aux dialogues de recherche, d'export, etc...
mais c'est une démarche volontaire du programmeur ; alors que pour
permettre sur Oracle (ou Access...) l'export du résultat de n'importe
quelle recherche qu'on vient de pratiquer, oualou.
meme chose, d'ailleurs, pour l'import. Encore une grosse tare, que
j'avais oubliée, de tous ces systèmes.
--
Philippe Manet
pmanet@invivo.edu
Maintenant, tout le monde (tous les éditeurs de logiciels je parle) n'a pas la volonté de laisser les utilisateurs faire leurs propres requêtes sur la base... Parce que ça veut dire qu'ils ne sont plus prisonniers de cette base précisément, qu'ils peuvent donc se passer des services de ceux qui l'ont vendue... Et tous les clients ne mesurent pas forcément l'importance de cela.
c'est tout à fait vrai ; et maintenant, meme 4D et FMP permettent de verrouiller l'accès aux dialogues de recherche, d'export, etc... mais c'est une démarche volontaire du programmeur ; alors que pour permettre sur Oracle (ou Access...) l'export du résultat de n'importe quelle recherche qu'on vient de pratiquer, oualou.
meme chose, d'ailleurs, pour l'import. Encore une grosse tare, que j'avais oubliée, de tous ces systèmes. -- Philippe Manet
pmanet
Christophe Franco wrote:
C'est d'ailleurs là qu'est LE grand intérêt de ne pas utiliser des front-ends de base de données, mais de faire un vrai développement avec des vrais langages et une vraie structure. A court terme, c'est sûr que ça prend un peu plus de temps, mais ça vieillit nettement mieux...
pas sur... l'évolutivité de ce genre de bricolage n'est pas garantie, ou alors elle coute extremement cher.
Chaque fois qu'on veut rajouter une rubrique, voire meme qu'on change de sous-version du SGDB, du frontal, de je ne sais quel composant, on risque fort d'avoir à remettre les mains dans le cambouis, de devoir repartir à la chasse au bug... le tout avec les difficultés de maintenance déjà décrite, qui rendent compliquée la moindre intervention. Et compliqué, ça veut dire quoi :
1) des couts directs en compétence ou en intervenants 2) et beaucoup plus de couts indirects en dysfonctionnements et perturbation de la qualité des données.
C'est éventuellement une solution pour de très gros déploiements (le cout de devellopement est amorti plus facilement) de bases très stables, qu'on ne va pas changer tous les ans.
En tous cas, ce n'est pas ton cas actuel, un truc tout nouveau, qui va beaucoup bouger pendant au moins 5 ans, avec lequel on te propose des SGDB qui sont eux-meme très instables, voire quasiment en version beta... dans ce cas là, dans mon expérience, l'usage de petits bouts de code peut servir à compenser des insuffisances ou des bugs, mais fonder tout le developpement dessus est aberrant, c'est etre sur de devoir tout reprendre 10 fois et de repatcher chaque modif 3fois (sauf à consacrer un temps considérable au debuggage, mais ça, je ne l'ai jamais vu, c'est pour le client et la hotline). -- Philippe Manet
Christophe Franco <cfranco@pobox.com> wrote:
C'est d'ailleurs là qu'est LE grand
intérêt de ne pas utiliser des front-ends de base de données, mais de
faire un vrai développement avec des vrais langages et une vraie
structure. A court terme, c'est sûr que ça prend un peu plus de temps,
mais ça vieillit nettement mieux...
pas sur... l'évolutivité de ce genre de bricolage n'est pas garantie, ou
alors elle coute extremement cher.
Chaque fois qu'on veut rajouter une rubrique, voire meme qu'on change de
sous-version du SGDB, du frontal, de je ne sais quel composant, on
risque fort d'avoir à remettre les mains dans le cambouis, de devoir
repartir à la chasse au bug... le tout avec les difficultés de
maintenance déjà décrite, qui rendent compliquée la moindre
intervention.
Et compliqué, ça veut dire quoi :
1) des couts directs en compétence ou en intervenants
2) et beaucoup plus de couts indirects en dysfonctionnements et
perturbation de la qualité des données.
C'est éventuellement une solution pour de très gros déploiements (le
cout de devellopement est amorti plus facilement) de bases très stables,
qu'on ne va pas changer tous les ans.
En tous cas, ce n'est pas ton cas actuel, un truc tout nouveau, qui va
beaucoup bouger pendant au moins 5 ans, avec lequel on te propose des
SGDB qui sont eux-meme très instables, voire quasiment en version
beta... dans ce cas là, dans mon expérience, l'usage de petits bouts de
code peut servir à compenser des insuffisances ou des bugs, mais fonder
tout le developpement dessus est aberrant, c'est etre sur de devoir tout
reprendre 10 fois et de repatcher chaque modif 3fois (sauf à consacrer
un temps considérable au debuggage, mais ça, je ne l'ai jamais vu, c'est
pour le client et la hotline).
--
Philippe Manet
pmanet@invivo.edu
C'est d'ailleurs là qu'est LE grand intérêt de ne pas utiliser des front-ends de base de données, mais de faire un vrai développement avec des vrais langages et une vraie structure. A court terme, c'est sûr que ça prend un peu plus de temps, mais ça vieillit nettement mieux...
pas sur... l'évolutivité de ce genre de bricolage n'est pas garantie, ou alors elle coute extremement cher.
Chaque fois qu'on veut rajouter une rubrique, voire meme qu'on change de sous-version du SGDB, du frontal, de je ne sais quel composant, on risque fort d'avoir à remettre les mains dans le cambouis, de devoir repartir à la chasse au bug... le tout avec les difficultés de maintenance déjà décrite, qui rendent compliquée la moindre intervention. Et compliqué, ça veut dire quoi :
1) des couts directs en compétence ou en intervenants 2) et beaucoup plus de couts indirects en dysfonctionnements et perturbation de la qualité des données.
C'est éventuellement une solution pour de très gros déploiements (le cout de devellopement est amorti plus facilement) de bases très stables, qu'on ne va pas changer tous les ans.
En tous cas, ce n'est pas ton cas actuel, un truc tout nouveau, qui va beaucoup bouger pendant au moins 5 ans, avec lequel on te propose des SGDB qui sont eux-meme très instables, voire quasiment en version beta... dans ce cas là, dans mon expérience, l'usage de petits bouts de code peut servir à compenser des insuffisances ou des bugs, mais fonder tout le developpement dessus est aberrant, c'est etre sur de devoir tout reprendre 10 fois et de repatcher chaque modif 3fois (sauf à consacrer un temps considérable au debuggage, mais ça, je ne l'ai jamais vu, c'est pour le client et la hotline). -- Philippe Manet
pmanet
Christophe Franco wrote:
Et puis même pour le développement, c'est bien plus difficile à programmer qu'avec un langage comme Java par exemple, du fait d'un manque de rigueur considérable dans le langage, techniquement c'est en fait beaucoup plus dur si on veut faire quelque chose de propre. L'ennui, c'est que bien peu de gens se soucient de faire quelque chose de propre, et à court terme on n'en mesure pas forcément les conséquences...
tu pars sans arret d'une situation effectivement commune : celle d'une base bricolée dans son coin par un amateur génial, mais sans base théorique de programmation, et qu'on veut reprendre ensuite. Comme le modèle de donnée est mauvais, que les routines ne sont pas documentées, et que les rubriques sont empilées sans qu'une autre personne que le concepteur sache pourquoi, c'est évident qu'on y arrivera pas sans un énorme boulot, et qu'il faut tout reprendre en s'efforçant de comprendre comment ça fonctioonne. Mais cet exemple est buggé : ce serait pareil s'il avait utilisé MySQL !!! ou directement du C !
Moi je te parle d'un gars comme toi, un vrai pro qui va faire une analyse sérieuse du modèle de donnée, et qui derrière, dans les cas où c'est indispensable, (mais avouons que c'est plus rarement le cas avec les bases intégrées), va faire un vrai boulot de programmation bien orthogonal.
Sur que, notamment dans FMP tel qu'il est actuellement, programmer réellement n'est pas bien facile (il semble que la V7 a amélioré pas mal de points, mais ce n'est pas encore terrible) ; ceci dit, ils ont enfin mis des outils de reporting, alors qu'avant il fallait les faire soi-meme en Applescript. Et on peut séparer modèle et données, ce qui peut servir... Et peut-etre faut-il aussi abandonner quelques canons rouillés, comme l'unicité des objets ou des trucs comme ça (non, aie, pas sur la tete...).
Mais je pense que le résultat global, pris à la fois sur l'exploitation totale et l'évolutivité, restera meilleur dans la plupart des cas.
-- Philippe Manet
Christophe Franco <cfranco@pobox.com> wrote:
Et puis même pour le développement, c'est bien plus difficile à
programmer qu'avec un langage comme Java par exemple, du fait d'un
manque de rigueur considérable dans le langage, techniquement c'est en
fait beaucoup plus dur si on veut faire quelque chose de propre.
L'ennui, c'est que bien peu de gens se soucient de faire quelque chose
de propre, et à court terme on n'en mesure pas forcément les
conséquences...
tu pars sans arret d'une situation effectivement commune :
celle d'une base bricolée dans son coin par un amateur génial, mais sans
base théorique de programmation, et qu'on veut reprendre ensuite. Comme
le modèle de donnée est mauvais, que les routines ne sont pas
documentées, et que les rubriques sont empilées sans qu'une autre
personne que le concepteur sache pourquoi, c'est évident qu'on y
arrivera pas sans un énorme boulot, et qu'il faut tout reprendre en
s'efforçant de comprendre comment ça fonctioonne. Mais cet exemple est
buggé : ce serait pareil s'il avait utilisé MySQL !!! ou directement du
C !
Moi je te parle d'un gars comme toi, un vrai pro qui va faire une
analyse sérieuse du modèle de donnée, et qui derrière, dans les cas où
c'est indispensable, (mais avouons que c'est plus rarement le cas avec
les bases intégrées), va faire un vrai boulot de programmation bien
orthogonal.
Sur que, notamment dans FMP tel qu'il est actuellement, programmer
réellement n'est pas bien facile (il semble que la V7 a amélioré pas mal
de points, mais ce n'est pas encore terrible) ; ceci dit, ils ont enfin
mis des outils de reporting, alors qu'avant il fallait les faire
soi-meme en Applescript. Et on peut séparer modèle et données, ce qui
peut servir... Et peut-etre faut-il aussi abandonner quelques canons
rouillés, comme l'unicité des objets ou des trucs comme ça (non, aie,
pas sur la tete...).
Mais je pense que le résultat global, pris à la fois sur l'exploitation
totale et l'évolutivité, restera meilleur dans la plupart des cas.
Et puis même pour le développement, c'est bien plus difficile à programmer qu'avec un langage comme Java par exemple, du fait d'un manque de rigueur considérable dans le langage, techniquement c'est en fait beaucoup plus dur si on veut faire quelque chose de propre. L'ennui, c'est que bien peu de gens se soucient de faire quelque chose de propre, et à court terme on n'en mesure pas forcément les conséquences...
tu pars sans arret d'une situation effectivement commune : celle d'une base bricolée dans son coin par un amateur génial, mais sans base théorique de programmation, et qu'on veut reprendre ensuite. Comme le modèle de donnée est mauvais, que les routines ne sont pas documentées, et que les rubriques sont empilées sans qu'une autre personne que le concepteur sache pourquoi, c'est évident qu'on y arrivera pas sans un énorme boulot, et qu'il faut tout reprendre en s'efforçant de comprendre comment ça fonctioonne. Mais cet exemple est buggé : ce serait pareil s'il avait utilisé MySQL !!! ou directement du C !
Moi je te parle d'un gars comme toi, un vrai pro qui va faire une analyse sérieuse du modèle de donnée, et qui derrière, dans les cas où c'est indispensable, (mais avouons que c'est plus rarement le cas avec les bases intégrées), va faire un vrai boulot de programmation bien orthogonal.
Sur que, notamment dans FMP tel qu'il est actuellement, programmer réellement n'est pas bien facile (il semble que la V7 a amélioré pas mal de points, mais ce n'est pas encore terrible) ; ceci dit, ils ont enfin mis des outils de reporting, alors qu'avant il fallait les faire soi-meme en Applescript. Et on peut séparer modèle et données, ce qui peut servir... Et peut-etre faut-il aussi abandonner quelques canons rouillés, comme l'unicité des objets ou des trucs comme ça (non, aie, pas sur la tete...).
Mais je pense que le résultat global, pris à la fois sur l'exploitation totale et l'évolutivité, restera meilleur dans la plupart des cas.
-- Philippe Manet
yvon.thoravalNO-SPAM
manet wrote:
le rapport, c'est que plein de petits jeunes sortant des cursus en question ne savent meme pas qu'il existe autre chose que le SQL pour faire des bases de données.
Qu'existe t'il d'autre ? Perso je fais du java.sql en ce moment et je trouve qu'effectivement les orientations des languages sont si opposées que... -- yt
manet <pmanet@invivo.edu> wrote:
le rapport, c'est que plein de petits jeunes sortant des cursus en
question ne savent meme pas qu'il existe autre chose que le SQL pour
faire des bases de données.
Qu'existe t'il d'autre ? Perso je fais du java.sql en ce moment et je
trouve qu'effectivement les orientations des languages sont si opposées
que...
--
yt
le rapport, c'est que plein de petits jeunes sortant des cursus en question ne savent meme pas qu'il existe autre chose que le SQL pour faire des bases de données.
Qu'existe t'il d'autre ? Perso je fais du java.sql en ce moment et je trouve qu'effectivement les orientations des languages sont si opposées que... -- yt
Hubert Figuiere
le rapport, c'est que plein de petits jeunes sortant des cursus en question ne savent meme pas qu'il existe autre chose que le SQL pour faire des bases de données. Et que ces trucs permettent de résoudre avec facilité et élégance la plupart des problèmes. Quand on leur montre, ça leur troue le cul.
A priori t'a pas suivi récemment un cours de base de données. Parceque bon, on t'apprendre autre chose que SQL. Et puis finalement quand t'a compris SQL tu peut faire n'importe quoi, et surtout tu n'est pas cantonné à un seul SGBD, propriétaire de surcroit.
et l'enseignement, c'est censé te donner un aperçu le plus large possible de ce qui existe pour résoudre un problème, et pas t'enfermer dans des solutions des années 70.
Ni dans les solutions de années 1980 comme tu le suggère. Et oui, 4D ca date de 1985 et ca a presque pas évolué. Car SQL c'est qu'un langage d'interrogation *standard*, il n'a aucun dépendance sur la l'architecture sous-jaceante du SGBD.
le rapport, c'est que plein de petits jeunes sortant des cursus en
question ne savent meme pas qu'il existe autre chose que le SQL pour
faire des bases de données. Et que ces trucs permettent de résoudre avec
facilité et élégance la plupart des problèmes. Quand on leur montre, ça
leur troue le cul.
A priori t'a pas suivi récemment un cours de base de données. Parceque
bon, on t'apprendre autre chose que SQL. Et puis finalement quand t'a
compris SQL tu peut faire n'importe quoi, et surtout tu n'est pas
cantonné à un seul SGBD, propriétaire de surcroit.
et l'enseignement, c'est censé te donner un aperçu le plus large
possible de ce qui existe pour résoudre un problème, et pas t'enfermer
dans des solutions des années 70.
Ni dans les solutions de années 1980 comme tu le suggère. Et oui, 4D
ca date de 1985 et ca a presque pas évolué.
Car SQL c'est qu'un langage d'interrogation *standard*, il n'a aucun
dépendance sur la l'architecture sous-jaceante du SGBD.
le rapport, c'est que plein de petits jeunes sortant des cursus en question ne savent meme pas qu'il existe autre chose que le SQL pour faire des bases de données. Et que ces trucs permettent de résoudre avec facilité et élégance la plupart des problèmes. Quand on leur montre, ça leur troue le cul.
A priori t'a pas suivi récemment un cours de base de données. Parceque bon, on t'apprendre autre chose que SQL. Et puis finalement quand t'a compris SQL tu peut faire n'importe quoi, et surtout tu n'est pas cantonné à un seul SGBD, propriétaire de surcroit.
et l'enseignement, c'est censé te donner un aperçu le plus large possible de ce qui existe pour résoudre un problème, et pas t'enfermer dans des solutions des années 70.
Ni dans les solutions de années 1980 comme tu le suggère. Et oui, 4D ca date de 1985 et ca a presque pas évolué. Car SQL c'est qu'un langage d'interrogation *standard*, il n'a aucun dépendance sur la l'architecture sous-jaceante du SGBD.
Car SQL c'est qu'un langage d'interrogation *standard*, il n'a aucun dépendance sur la l'architecture sous-jaceante du SGBD.
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.
Ol. -- Olivier Gutknecht
Hubert Figuiere <hub@free.fr> wrote:
Car SQL c'est qu'un langage d'interrogation *standard*, il n'a aucun
dépendance sur la l'architecture sous-jaceante du SGBD.
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.
Car SQL c'est qu'un langage d'interrogation *standard*, il n'a aucun dépendance sur la l'architecture sous-jaceante du SGBD.
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.
Ol. -- Olivier Gutknecht
yvon.thoravalNO-SPAM
Olivier Gutknecht <ol.g+ wrote:
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... -- yt
Olivier Gutknecht <ol.g+news@free.fr> wrote:
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...
--
yt
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... -- yt
