Heureusement que tu as mis « la plupart ». :o)
Cet outil introduit souvent des bogues, car la plupart de ces
utilisateurs sont des débutants, qui ne comprennent pas ce qu'ils font.
Du coup, c'est (toujours ?) mal configuré. Et un utilisateur avancé sait
qu'il ira plus vite et aura plus de puissance en passant par un éditeur
de texte et l'invocation d'une commande (depuis l'éditeur, évidement).
J'ai dit que je n'aime pas PHPMyAdmin ? :)
Heureusement que tu as mis « la plupart ». :o)
Cet outil introduit souvent des bogues, car la plupart de ces
utilisateurs sont des débutants, qui ne comprennent pas ce qu'ils font.
Du coup, c'est (toujours ?) mal configuré. Et un utilisateur avancé sait
qu'il ira plus vite et aura plus de puissance en passant par un éditeur
de texte et l'invocation d'une commande (depuis l'éditeur, évidement).
J'ai dit que je n'aime pas PHPMyAdmin ? :)
Heureusement que tu as mis « la plupart ». :o)
Cet outil introduit souvent des bogues, car la plupart de ces
utilisateurs sont des débutants, qui ne comprennent pas ce qu'ils font.
Du coup, c'est (toujours ?) mal configuré. Et un utilisateur avancé sait
qu'il ira plus vite et aura plus de puissance en passant par un éditeur
de texte et l'invocation d'une commande (depuis l'éditeur, évidement).
J'ai dit que je n'aime pas PHPMyAdmin ? :)
On 04/07/2011 01:42 PM, Olivier Masson wrote:MyISAM n'est-il pas bcp plus rapide qu'InnoDB ?
Si, en effet.
Si pour certaines bases je n'ai pas besoin de rollback, de foreign key
et autres spécificités, *pourquoi* devrais-je m'imposer InnoDB ? Parce
que ça fait plus sérieux ?
Oui ! C'est plus "sérieux", dans le sens ou ça respecte ACID.
Vous pouvez utiliser MyISAM si vous êtes conscient que vous pouvez
perdre des données, sans être prévenu, et si ça n'est pas grave pour vous.
Ça ne répond pas au même besoin, c'est tout.
On 04/07/2011 01:42 PM, Olivier Masson wrote:
MyISAM n'est-il pas bcp plus rapide qu'InnoDB ?
Si, en effet.
Si pour certaines bases je n'ai pas besoin de rollback, de foreign key
et autres spécificités, *pourquoi* devrais-je m'imposer InnoDB ? Parce
que ça fait plus sérieux ?
Oui ! C'est plus "sérieux", dans le sens ou ça respecte ACID.
Vous pouvez utiliser MyISAM si vous êtes conscient que vous pouvez
perdre des données, sans être prévenu, et si ça n'est pas grave pour vous.
Ça ne répond pas au même besoin, c'est tout.
On 04/07/2011 01:42 PM, Olivier Masson wrote:MyISAM n'est-il pas bcp plus rapide qu'InnoDB ?
Si, en effet.
Si pour certaines bases je n'ai pas besoin de rollback, de foreign key
et autres spécificités, *pourquoi* devrais-je m'imposer InnoDB ? Parce
que ça fait plus sérieux ?
Oui ! C'est plus "sérieux", dans le sens ou ça respecte ACID.
Vous pouvez utiliser MyISAM si vous êtes conscient que vous pouvez
perdre des données, sans être prévenu, et si ça n'est pas grave pour vous.
Ça ne répond pas au même besoin, c'est tout.
Le 07/04/11 00:01, Pascal Poncet a écrit :Le 06/04/2011 16:23, Bruno Baguette a écrit :En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.
Bon, on est un peu (voire totalement) hors charte mais, comme le
newsgroup est modéré, je suppose qu'on est implicitement autorisé à
développer le sujet.
On est complètement hors charte, je vais donc positionner la suite du
débat sur fr.comp.applications.sgbd, ca ne fera pas de tort (on y sera
en charte), et puis ca y roupille, pour le moment...Euh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais
il faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.
>Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.
Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que
c'était une daubasse.
Bon, puisque j'ai ouvert la fosse à trolls, j'assume ! :-)
Je précise que j'ai été zieuter les récents changements de MySQL par
honnêteté, dès fois que... Et j'ai bien fait puisque changements il y a eu.
A l'époque (un bail) où j'ai fait mes choix, MySQL ne gérait pas les
sous-requêtes, ni les procédures stockées. PostgreSQL répondait à mes
besoins, je n'ai pas changé de SGBDR depuis.
Jusqu'il y a peu (fin 2010), MySQL était une daubasse dans sa
configuration par défaut, c'est à dire avec le moteur MyISAM (pas de
clef étrangères, acceptation de données plus grandes que la colonne
censée la recevoir, ...)
En d'autres termes, vous pouviez virer un enregistrement référencé par
d'autres (et donc perdre la cohérence de vos données), ou vous pouviez
insérer une chaine de 200 caractères dans un varchar(20) sans que MySQL
ne vous refuse l'insertion (et donc vous retrouver avec une chaine
tronquée).
Enfin, si vous utilisez une table (en insert ou en update) en MyISAM
lors d'un plantage du serveur, vous aviez de bonnes chances de vous
retrouver avec une table corrompue.
Bref, utiliser MySQL avec MyISAM relève de l'inconscience (surement une
grosse partie des utilisateurs), ou de la folie furieuse à moins de
savoir *ce que l'on fait*.
Le rachat de MySQL par Oracle aura permit (c'est peut-être la seule
bonne chose), que le moteur par défaut ne soit plus MyISAM, mais bien
InnoDB (qui appartenait déjà à Oracle avant, si je ne me trompe pas).
Un comparatif des fonctionnalités et des performances serait intéressant
à refaire (à moins qu'un comparatif *récent* ne soit déjà fait). Je ne
suis pas bien placé pour le faire puisque je n'utilise que rarement
MySQL (et aussi parce que je n'ai pas le temps de le faire, mais ca je
ne le dis pas !).
Pour l'aspect de la réplication, je ne vais pas m'aventurer sur ce
terrain, je n'ai jamais utilisé cela avec MySQL (uniquement en
PostgreSQL). Donc je n'ai pas d'expérience à donner sur ce point ! :-)Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?
Hélas, il semble bien incertain, du moins dans ses perspectives de
développement, car Oracle est réputé le positionner définitivement en
entrée de gamme, anti-cannibalisation oblige.
Enfin, entre une DB MySQL/PostgreSQL,... ou une DB Oracle, il y a une
grosse marge de coût quand même (serveur, DBA,...).Maintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].
De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]
J'en avais entendu parler, mais j'ignorait qu'ils étaient compatibles
avec le client MySQL (quand on voit l'auteur, on comprend mieux ensuite).
Le tout est de voir s'il sera adopté largement, mais c'est sans doute
trop tôt ? Il y a aussi Drizzle, un fork signalé par Mickael.
Le 07/04/11 00:01, Pascal Poncet a écrit :
Le 06/04/2011 16:23, Bruno Baguette a écrit :
En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.
Bon, on est un peu (voire totalement) hors charte mais, comme le
newsgroup est modéré, je suppose qu'on est implicitement autorisé à
développer le sujet.
On est complètement hors charte, je vais donc positionner la suite du
débat sur fr.comp.applications.sgbd, ca ne fera pas de tort (on y sera
en charte), et puis ca y roupille, pour le moment...
Euh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais
il faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.
>
Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.
Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que
c'était une daubasse.
Bon, puisque j'ai ouvert la fosse à trolls, j'assume ! :-)
Je précise que j'ai été zieuter les récents changements de MySQL par
honnêteté, dès fois que... Et j'ai bien fait puisque changements il y a eu.
A l'époque (un bail) où j'ai fait mes choix, MySQL ne gérait pas les
sous-requêtes, ni les procédures stockées. PostgreSQL répondait à mes
besoins, je n'ai pas changé de SGBDR depuis.
Jusqu'il y a peu (fin 2010), MySQL était une daubasse dans sa
configuration par défaut, c'est à dire avec le moteur MyISAM (pas de
clef étrangères, acceptation de données plus grandes que la colonne
censée la recevoir, ...)
En d'autres termes, vous pouviez virer un enregistrement référencé par
d'autres (et donc perdre la cohérence de vos données), ou vous pouviez
insérer une chaine de 200 caractères dans un varchar(20) sans que MySQL
ne vous refuse l'insertion (et donc vous retrouver avec une chaine
tronquée).
Enfin, si vous utilisez une table (en insert ou en update) en MyISAM
lors d'un plantage du serveur, vous aviez de bonnes chances de vous
retrouver avec une table corrompue.
Bref, utiliser MySQL avec MyISAM relève de l'inconscience (surement une
grosse partie des utilisateurs), ou de la folie furieuse à moins de
savoir *ce que l'on fait*.
Le rachat de MySQL par Oracle aura permit (c'est peut-être la seule
bonne chose), que le moteur par défaut ne soit plus MyISAM, mais bien
InnoDB (qui appartenait déjà à Oracle avant, si je ne me trompe pas).
Un comparatif des fonctionnalités et des performances serait intéressant
à refaire (à moins qu'un comparatif *récent* ne soit déjà fait). Je ne
suis pas bien placé pour le faire puisque je n'utilise que rarement
MySQL (et aussi parce que je n'ai pas le temps de le faire, mais ca je
ne le dis pas !).
Pour l'aspect de la réplication, je ne vais pas m'aventurer sur ce
terrain, je n'ai jamais utilisé cela avec MySQL (uniquement en
PostgreSQL). Donc je n'ai pas d'expérience à donner sur ce point ! :-)
Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?
Hélas, il semble bien incertain, du moins dans ses perspectives de
développement, car Oracle est réputé le positionner définitivement en
entrée de gamme, anti-cannibalisation oblige.
Enfin, entre une DB MySQL/PostgreSQL,... ou une DB Oracle, il y a une
grosse marge de coût quand même (serveur, DBA,...).
Maintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].
De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]
J'en avais entendu parler, mais j'ignorait qu'ils étaient compatibles
avec le client MySQL (quand on voit l'auteur, on comprend mieux ensuite).
Le tout est de voir s'il sera adopté largement, mais c'est sans doute
trop tôt ? Il y a aussi Drizzle, un fork signalé par Mickael.
Le 07/04/11 00:01, Pascal Poncet a écrit :Le 06/04/2011 16:23, Bruno Baguette a écrit :En même temps, les développeurs qui ont besoins de procédures stockées,
triggers et fonctions utilisent plutôt des bases de données sérieuses
comme PostgreSQL.
Bon, on est un peu (voire totalement) hors charte mais, comme le
newsgroup est modéré, je suppose qu'on est implicitement autorisé à
développer le sujet.
On est complètement hors charte, je vais donc positionner la suite du
débat sur fr.comp.applications.sgbd, ca ne fera pas de tort (on y sera
en charte), et puis ca y roupille, pour le moment...Euh... MySQL, c'est pas un SGBDR sérieux ?
Faudra le dire à Google, Amazon, Fnac, etc.
Je veux bien en discuter, car rien n'est définitivement acquis, mais
il faudra quand même amener quelques arguments solides avant toute
conclusion hâtive.
>Même dans le contexte particulier des routines, triggers et events, je
ne vois pas de faiblesse manifeste à leur implémentation de SQL 2003.
Je n'ai pas encore eu l'occasion de tester le parallélisme, la
réplication ou le clustering, mais je n'ai pas entendu dire que
c'était une daubasse.
Bon, puisque j'ai ouvert la fosse à trolls, j'assume ! :-)
Je précise que j'ai été zieuter les récents changements de MySQL par
honnêteté, dès fois que... Et j'ai bien fait puisque changements il y a eu.
A l'époque (un bail) où j'ai fait mes choix, MySQL ne gérait pas les
sous-requêtes, ni les procédures stockées. PostgreSQL répondait à mes
besoins, je n'ai pas changé de SGBDR depuis.
Jusqu'il y a peu (fin 2010), MySQL était une daubasse dans sa
configuration par défaut, c'est à dire avec le moteur MyISAM (pas de
clef étrangères, acceptation de données plus grandes que la colonne
censée la recevoir, ...)
En d'autres termes, vous pouviez virer un enregistrement référencé par
d'autres (et donc perdre la cohérence de vos données), ou vous pouviez
insérer une chaine de 200 caractères dans un varchar(20) sans que MySQL
ne vous refuse l'insertion (et donc vous retrouver avec une chaine
tronquée).
Enfin, si vous utilisez une table (en insert ou en update) en MyISAM
lors d'un plantage du serveur, vous aviez de bonnes chances de vous
retrouver avec une table corrompue.
Bref, utiliser MySQL avec MyISAM relève de l'inconscience (surement une
grosse partie des utilisateurs), ou de la folie furieuse à moins de
savoir *ce que l'on fait*.
Le rachat de MySQL par Oracle aura permit (c'est peut-être la seule
bonne chose), que le moteur par défaut ne soit plus MyISAM, mais bien
InnoDB (qui appartenait déjà à Oracle avant, si je ne me trompe pas).
Un comparatif des fonctionnalités et des performances serait intéressant
à refaire (à moins qu'un comparatif *récent* ne soit déjà fait). Je ne
suis pas bien placé pour le faire puisque je n'utilise que rarement
MySQL (et aussi parce que je n'ai pas le temps de le faire, mais ca je
ne le dis pas !).
Pour l'aspect de la réplication, je ne vais pas m'aventurer sur ce
terrain, je n'ai jamais utilisé cela avec MySQL (uniquement en
PostgreSQL). Donc je n'ai pas d'expérience à donner sur ce point ! :-)Je peux avoir loupé un épisode, mais l'avenir de MySQL n'est-il pas
incertain avec son rachat par Oracle ?
Hélas, il semble bien incertain, du moins dans ses perspectives de
développement, car Oracle est réputé le positionner définitivement en
entrée de gamme, anti-cannibalisation oblige.
Enfin, entre une DB MySQL/PostgreSQL,... ou une DB Oracle, il y a une
grosse marge de coût quand même (serveur, DBA,...).Maintenant, l'alternative semble très sérieuse du côté de MariaDB.
Voir [http://mariadb.org/].
De plus, pour revenir dans la charte, il n'y a apparemment aucun
problème à utiliser PHP en client.
Voir [http://kb.askmonty.org/v/mariadb-versus-mysql]
J'en avais entendu parler, mais j'ignorait qu'ils étaient compatibles
avec le client MySQL (quand on voit l'auteur, on comprend mieux ensuite).
Le tout est de voir s'il sera adopté largement, mais c'est sans doute
trop tôt ? Il y a aussi Drizzle, un fork signalé par Mickael.
Sauf que l'un n'a rien à voir avec l'autre... dans un cas c'est du
fichier cobol averc un surcouche pseudo SQL, dans l'autre c'est presque
du relationnel....
Sauf que l'un n'a rien à voir avec l'autre... dans un cas c'est du
fichier cobol averc un surcouche pseudo SQL, dans l'autre c'est presque
du relationnel....
Sauf que l'un n'a rien à voir avec l'autre... dans un cas c'est du
fichier cobol averc un surcouche pseudo SQL, dans l'autre c'est presque
du relationnel....
Le 11/04/2011 14:19, SQLpro a écrit :Sauf que l'un n'a rien à voir avec l'autre... dans un cas c'est du
fichier cobol averc un surcouche pseudo SQL, dans l'autre c'est presque
du relationnel....
On s'en fout, il faut lire la totalité du fil pour comprendre le
pourquoi de cette comparaison ici.
Si tu as juste besoin d'enregistrer des sessions utilisateurs pour
remplacer des cookies sur un petit site, MyISAM est très bien. J'utilise
également SQLite.
Si, par contre, tu me dis que PostgreSQL à un moteur facilement
accessible (cad facile à trouver, installer et utiliser avec les
langages web courants) qui va aussi vite que MyISAM pour des opérations
ultra-basiques, là c'est déjà plus intéressant.
Le 11/04/2011 14:19, SQLpro a écrit :
Sauf que l'un n'a rien à voir avec l'autre... dans un cas c'est du
fichier cobol averc un surcouche pseudo SQL, dans l'autre c'est presque
du relationnel....
On s'en fout, il faut lire la totalité du fil pour comprendre le
pourquoi de cette comparaison ici.
Si tu as juste besoin d'enregistrer des sessions utilisateurs pour
remplacer des cookies sur un petit site, MyISAM est très bien. J'utilise
également SQLite.
Si, par contre, tu me dis que PostgreSQL à un moteur facilement
accessible (cad facile à trouver, installer et utiliser avec les
langages web courants) qui va aussi vite que MyISAM pour des opérations
ultra-basiques, là c'est déjà plus intéressant.
Le 11/04/2011 14:19, SQLpro a écrit :Sauf que l'un n'a rien à voir avec l'autre... dans un cas c'est du
fichier cobol averc un surcouche pseudo SQL, dans l'autre c'est presque
du relationnel....
On s'en fout, il faut lire la totalité du fil pour comprendre le
pourquoi de cette comparaison ici.
Si tu as juste besoin d'enregistrer des sessions utilisateurs pour
remplacer des cookies sur un petit site, MyISAM est très bien. J'utilise
également SQLite.
Si, par contre, tu me dis que PostgreSQL à un moteur facilement
accessible (cad facile à trouver, installer et utiliser avec les
langages web courants) qui va aussi vite que MyISAM pour des opérations
ultra-basiques, là c'est déjà plus intéressant.
Mais de l'accès fichier Cobol, ça va encore plus vite que MyISAM !!!
Pourquoi faire du SGBD si c'est pour ne pas utiliser les transactions ni
les contraintes ? C'est idiot !
A +
Mais de l'accès fichier Cobol, ça va encore plus vite que MyISAM !!!
Pourquoi faire du SGBD si c'est pour ne pas utiliser les transactions ni
les contraintes ? C'est idiot !
A +
Mais de l'accès fichier Cobol, ça va encore plus vite que MyISAM !!!
Pourquoi faire du SGBD si c'est pour ne pas utiliser les transactions ni
les contraintes ? C'est idiot !
A +
