Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Qu'Oracle la conserve
Qu'Oracle s'en débarasse
De passer par une fondation multi-vendeurs
Autre (précisez svp)
Discussion :
Et où est le problème, au niveau maintenance ?
L'optimisation est indispensable dans certains domaines. Par exemple, si tu ne veux par ruiner la boite en serveurs, ça peut être bien, si tu créé un site grand public, où les accès concurrents se comptent en dizaines de milliers.
Tu dis que cela fait des années que tu bosses dans ce domaine,alors si tu poses la question c'est que la réponse ne t'a jamais intéressé.
Remarque , tu n'es pas le seul, et moi tant je n'ai pas à repasser derrière quelqu'un de votre style, ou que mon appli n'en dépend pas, au final je m'en tape.
Donc inutile d'entamer un dialogue de sourd, vous avez déjà prouver que vous vous débrouillez très bien dans le monologue...
Là, c'est un problème humain et non pas de Mysql. Les autres moteurs sont utilisé que par 1% des utilisateurs de Mysql et dans 90% des cas c'est MyIsam qui est utilisé. Personnellement, je l'utilise parce que je sais à quoi je touche mais il s'agit pas d'avoir une base avec 36 moteurs différent. Il faut savoir que peut de moteur son disponible chez les hébergeurs. MyIsam, InnoDb, Example.Envoyé par Erwy
Je ne vois pas non plus parce que je rejoins lychee sur ce point.
Je n'ai jamais eu a utilisé mysql au boulot et ce n'est pas vos arguments qui m'y pousseront.
Le truc du 1 moteur pour 1 utilisation c'est super marrant, sauf que lorsqu'on se trouve à placer ceci dans un vrai systme d'information et non pas une application dans son coin .Ca fait plutot frémir en terme de maintenance mais aussi de transmission de connaissance si on commence à faire mumuse avec ça.
Ce n'est pas la première fois que je vois ce type de raisonnement qui ne se place qu'à l'instant T mais n'envisage pas réellement le vécu d'une application dans un système ni ne prend en compte la gestion des équipes qui y travaille
Franchement l'optimisation à tout crin j'en suis revenu , comme la plupart de ceux qui doivent vivre avec ce qu'ils ont crée
Pas mal. Tu dis un truc, je te pose une question sur ce que tu affirmes, et tu dis tout de suite que je monologue. Le tout sans jamais, jamais, avancer le moindre argument. Sans commentaire...Tu dis que cela fait des années que tu bosses dans ce domaine,alors si tu poses la question c'est que la réponse ne t'a jamais intéressé.
Remarque , tu n'es pas le seul, et moi tant je n'ai pas à repasser derrière quelqu'un de votre style, ou que mon appli n'en dépend pas, au final je m'en tape.
Donc inutile d'entamer un dialogue de sourd, vous avez déjà prouver que vous vous débrouillez très bien dans le monologue...
Séparer l'humain du technique c'est le coeur du problème.
L'informatique c'est fait par des humains pour des humains (mais si cela passe parfois par des chemins détournés).
La très,très grande majorité des problème sont causé par le mélange humain/technique.Si tu exclus la moitié du problème, tu ne le résoudras jamais complètement , ni pour très longtemps.
Donc oui des technos comme mysql qui permettent vraiment n'importe quoi et de 40 manières différentes (ou même que 3 ou 4), ça pose un souci sur la durée.
Si seulement cela pouvait être vraiSans commentaire...
Non mais je suis d'accord dans l'ensemble mais il faut pas dire que le principe de différent type de table ou moteur est null parce que les mecs ne savent pas communiquer dans une boite. Parce que là il faudrait mettre toute les techno à la poubelle.Séparer l'humain du technique c'est le coeur du problème.
L'informatique c'est fait par des humains pour des humains (mais si cela passe parfois par des chemins détournés).
La très,très grande majorité des problème sont causé par le mélange humain/technique.Si tu exclus la moitié du problème, tu ne le résoudras jamais complètement , ni pour très longtemps.
Donc oui des technos comme mysql qui permettent vraiment n'importe quoi et de 40 manières différentes (ou même que 3 ou 4), ça pose un souci sur la durée.
Si seulement cela pouvait être vrai
Dans ce cas, pourquoi avoir des entiers, booleen ou textes dans des types de champs différents ? Si l'on suit ton raisonnement on devrait tout stocker dans un type unique.
Pour les performance ?
Et bien pour les moteur de MySQL c'est pareil.
Et de tout façon, rien ne nous oblige à les utiliser.
C'est pas parce que Oracle ou SQL Server ne le fait pas qu'il faut voir ça comme un désavantage. Il devraient peut être même s'en inspirer...
Sauf que la communication n'est pas la même dans un groupe de 10 personnes , une structure d'une centaine ou une autre de milliers.
J'appartiens à une structure du milieu, et on recrute régulièrement des personnes ayant le profil de la première et c'est toujours chiant de devoir leur expliquer pendant des heures pourquoi il ne faut pas faire un truc dans son coin, pourquoi sa super bidouille de la mort faut la virer parce ce n'est pas lui qui fera la maintenance mais aussi parce qu'elle peut couter très cher en terme d'évolution ou que son super outils de la mort il est peut être dix fois mieux que le palier technique mais:
- il est pas super compatible avec ce qu'on utilise et on va pas tout retaper pour lui faire plaisir
- c'est vrai que son seul petit défaut c'est qu'il ne fait pas du tout un truc qu'aujourd'hui on n'utilise pas mais rien ne nous dit qu'il ne sera pas dans les cartons demain.
Certes on sort complètement du cadre technique pur mais ceci est aussi important(voir +) pour une application qui est destiné à vivre que sa partie technique pure
Tu en as qui permettent de faire à peu près tout même si elles sont moins performantes ou d'autres qui oblige à une certaine approche , plus strict pour les utiliser.Je les préfère très largement à celles optimisées dans leur doamine
Désolé la bataille du troll c'est pas mon truc, j'espère au moins que c'est ça parce que si trouves ton argument valide c'est à pleurer...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Je prcise un point qui éclaircira peut être mieux ce que j'ai mis avant.
Avant cette discussion et même mainteant je ne suis pas un anti-mysql.
Je ne l'utilise pas mais j'ai toujours suivi son actu et je suis d'accord que la plupart des points faibles de mysql ont été corrigé ou au moins amélioré.
Ce que j'ignorais c'était cette histoire de moteur, et ce qui me gêne encore plus c'est les réactions en leur faveur que je vois ici.
Je ne trouve pas du tout sain cet éclatement, mais je suis encore plus inquiet de le voir aussi justifié par certains.
Dans le même style, mais sur linux, il y avait eu un article humoristique qui pointait que le problème ce n'était pas linux mais le linuxien.
Même si c'était traité sur le thème de l'humour cela posait quand même une réalité, ce qui dessert le plus linux c'est une partie de sa communauté.
Je ne pensais pas que ce problème existait sur mysql, je savais que la plupart des utilisateurs approchait le niveau zéro en connaissance de BDD mais bon
Par contre que la communauté qui développe s'amuse à ce genre de chose et qu'elle soit autant suivie, oui ça m'inquiète et j'éviterais donc volontairement mysql désormais.
Mais tu m'apprends rien puisque je suis dans le même cas, je travail pour un grand groupe international et je comprend bien ce dont tu parles.Sauf que la communication n'est pas la même dans un groupe de 10 personnes , une structure d'une centaine ou une autre de milliers.
J'appartiens à une structure du milieu, et on recrute régulièrement des personnes ayant le profil de la première et c'est toujours chiant de devoir leur expliquer pendant des heures pourquoi il ne faut pas faire un truc dans son coin, pourquoi sa super bidouille de la mort faut la virer parce ce n'est pas lui qui fera la maintenance mais aussi parce qu'elle peut couter très cher en terme d'évolution ou que son super outils de la mort il est peut être dix fois mieux que le palier technique mais:
- il est pas super compatible avec ce qu'on utilise et on va pas tout retaper pour lui faire plaisir
- c'est vrai que son seul petit défaut c'est qu'il ne fait pas du tout un truc qu'aujourd'hui on n'utilise pas mais rien ne nous dit qu'il ne sera pas dans les cartons demain.
Certes on sort complètement du cadre technique pur mais ceci est aussi important(voir +) pour une application qui est destiné à vivre que sa partie technique pure
Tu en as qui permettent de faire à peu près tout même si elles sont moins performantes ou d'autres qui oblige à une certaine approche , plus strict pour les utiliser.Je les préfère très largement à celles optimisées dans leur doamine
Désolé la bataille du troll c'est pas mon truc, j'espère au moins que c'est ça parce que si trouves ton argument valide c'est à pleurer...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Mais ce que tu reproche à Mysql n'a pas de rapport avec l'équipe.
J'ai comme l'impression que vous imaginez qu'il faut choisir sont moteur au moment ou il faut penser au projet ou lorsque vous commencez à construire vos tables. Non, ces moteurs sont réservés aux utilisateurs averties. Je le répète encore une fois. Il y a que 1% des utilisateurs qui utilisent ces moteurs et 90% utilisent le moteur par défaut (MyIsam). J'utilise quelques moteurs parce que je sais ce que je fais. La plupart c'est des entreprises qui les utilisent même certaine ont leur propre moteur qui est propriétaire. Il faut arrêter d'imaginer que c'est un truc mis en avant lorsque vous utilisez Mysql.
Personnellement, je taffe toute la journée sur SQLServer au boulot et j'avoue que celui-ci est puissant mais il aurait été bien s'il y avait ce principe de type de table (moteur) parce que cela améliorait énormément certain processus.
Je vais prendre qu'un simple cas. Est-ce qu'une table doit-il travailler de la même manière lorsqu'il y a beaucoup d'entré sortie et que les données une durée de vie courte, que des données de logs. SQLServer répond que très faiblement à cela. Mysql y répond parfaitement. Memory/Archive. Doit-on dire que ceux qui ont mis cela en place sont idiot ?
Pas besoin d'avoir une doc de 50 pages ou utiliser la méthode Agile XP, etc pour expliquer cela à un collaborateur.
Il faut pas porter des critiques sans savoir de quoi il s'agit, du fonctionnement et de l'utilité.
+1
Il suffit d'imaginer que das SQL Server ou oracle par exemple au moment de la création d'une table il y ai une option qui permette de choisir le comportement de la table afin d'améliorer les performances suivant comment on va utiliser cette table.
Bien sur comme c'est une option ça reste optionnel et si on ne choisi rien ça prendre la valeur par défaut.
De plus ça peut se modifier en quelques seconde à tout moment. On peut passer d'un moteur à l'autre sans soucis... ça n'a rien d'une décision critique
Et je tiens également à préciser que je ne suis ni pro / ni anti quoi que ce soit. C'est juste que j'adhère à cette philosophie de moteur.
Au taf on utilise SQL Server / Oracle et Postgres
Et perso j'utilise MySQL parce que c'est la base supportée par la majorité des applis php open sources. Et lorsque l'on a un serveur qui n'a pas besoin de monter énormément en charge, ça convient largement.
Par contre je suis tout à fait d'accords que sur des bases avec plusieurs million d'enregistrements, MySQL ne fera pas le poids face à SQL Server ou Oracle
Pour moi, la possibilité d'utiliser différents moteurs de stockage est à la fois un avantage et un inconvénient :
- un avantage, car, comme dit plus haut, ca permet de mieux s'adapter à l'utilisation et donc d'optimiser les performances. J'utilise souvent MEMORY par exemple, car il est très rapide (pas de latence du disque) pour stocker des données temporaires (la liste des utilisateurs connectés, l'historique d'un chat, ... il y'a énormément d'utilisations possibles) ;
- un inconvénient, car on se retrouve avec des fonctionnalités réparties sur plusieurs moteurs, et on retrouve plusieurs moteurs aux capacités identiques (InnoDB, BerkeleyDB, Maria et bientôt Falcon sont des moteurs transactionnels) et une bonne partie des moteurs (et pas les moindre) ne sont pas développés par MySQL AB ... ce qui est pas très homogène. Le problème également, c'est MyISAM (le moteur non transactionnel) qui est le choix par défaut qui est vraiment pauvre en fonctionnalités : il ne supporte pas les clés étrangères, les transactions, ... et certains tests montrent que, en pleine charge, il n'est pas plus rapide qu'innoDB. Pour moi, le moteur par défaut devrait être transactionnel et on devrait mettre les moteurs MyISAM et ISAM à la poubelle.
Tu as raison sur les inconvénients. le problème c'est que InnoDB apparatient à Oracle et avant cela n'était pas à MysqlAB. Je pense qu'avec l'arrivé de Falcon il sera par défaut. Maria va, il me semble remplacer MyISAM.
Mouai, faut encore que MySQL 6 sorte un jour ...
Comme je l'ai dit, c'était dans en cour avant le rachat par Sun et pendant Sun mais avec le rachat de Sun je sais pas ou cela en est.
Tu m'accuse de monologuer, mais tu ne réponds pas aux arguments. A partir de là, c'est sûr que le débat perd de son intérêt. Désolé de mettre le doigt là où ça fait mal...
Si seulement cela pouvait être vrai
Bref, il faut qualifier les outils qu'on va utiliser. En quoi est-ce que ça rend le mécanisme dont on parle mauvais ? En matière de SGBD, il y a même des gens dont c'est la spécialité : les DBA.
Comme le dit berceker united, le choix du moteur ne relève pas (ou ne devrait pas relever) du développeur applicatif. Ça n'a pas d'incidence sur la syntaxe des requêtes, par exemple. C'est le genre de choix qui, dans une structure d'une certaine taille, devrait être réservé au DBA. C'est un mécanisme d'optimisation, un peu comme la création d'index.Je prcise un point qui éclaircira peut être mieux ce que j'ai mis avant.
Avant cette discussion et même mainteant je ne suis pas un anti-mysql.
Je ne l'utilise pas mais j'ai toujours suivi son actu et je suis d'accord que la plupart des points faibles de mysql ont été corrigé ou au moins amélioré.
Ce que j'ignorais c'était cette histoire de moteur, et ce qui me gêne encore plus c'est les réactions en leur faveur que je vois ici.
Je ne trouve pas du tout sain cet éclatement, mais je suis encore plus inquiet de le voir aussi justifié par certains.
Dans le même style, mais sur linux, il y avait eu un article humoristique qui pointait que le problème ce n'était pas linux mais le linuxien.
Même si c'était traité sur le thème de l'humour cela posait quand même une réalité, ce qui dessert le plus linux c'est une partie de sa communauté.
Je ne pensais pas que ce problème existait sur mysql, je savais que la plupart des utilisateurs approchait le niveau zéro en connaissance de BDD mais bon
Par contre que la communauté qui développe s'amuse à ce genre de chose et qu'elle soit autant suivie, oui ça m'inquiète et j'éviterais donc volontairement mysql désormais.
Pour préciser un peu techniquement : le choix d'un moteur se fait au niveau d'une table. Et en dehors des moteurs livrés en standard avec MySQL, la mise en place de moteurs supplémentaires se fait par l'installation de plugins. Jusqu'à preuve du contraire, ce n'est pas le genre de chose que peut faire un développeur.
Cela dit, rien n'empêche de n'utiliser qu'un moteur "généraliste", genre InnoDB ou SolidDB, et de ne pas chercher à tirer partie des possibilités des autres.
Mise à jour :
MySQL restera Open-Source et sera soutenu par Oracle
La Commission Européenne semble enfin satisfaite des engagements pris par le géant du logiciel
Lors de son audition de Vendredi dernier face à la Commission chargée de la concurrence, Oracle a réussi à gagner des points.
La société s'est engagée à soutenir le développement de la base de données de Sun, à la garder sous libre et à continuer à publier des informations pour les développeurs.
Dans un communiqué à la presse, Bruxelles indique qu'il s'agit à ses yeux "d'éléments nouveaux importants qui devront être pris en compte dans la procédure en cours".
Les opposants à l'accord (dont Microsoft et SAP) n'ont certainement pas dit leur dernier mots.
Beaucoup parlent de "poudres au yeux".
Le plus motivé d'entre eux, Michael "Monty" Widenius, le créateur de MySQL (lire ci-dessous), en appelle même à la vox populi et à la réaction démocratique. Il faudrait que les citoyens en viennent à écrire à Bruxelles pour exprimer leurs désaccords.
Mais les jeux semblent bien être faits, sauf revirement inattendu de dernière minute.
Ce qui ne serait par pas la première fois dans cette affaire.
Et vous ?
Seriez-vous prêt à écrire à la Commission pour empêcher la fusion Sun-Oracle ou au contraire trouvez-vous que Michael "Monty" Widenius commence à en faire trop ?
Pourquoi pas.
Je pense qu'il faudrait dire quelque chose qui n'a pas encore été dit.
MySQL est la base de données OpenSource qui a du succès et elle prends donc la vedette à d'autres moteurs comme PostgreSQL qui sont pourtant bien plus "puissants". Si Oracle souhaite garder MySQL, selon moi en tous cas, c'est pour s'en servir comme "bouclier" contre l'OpenSource. MySQL ne dispose pas, et ne disposera sans doute jamais des ressources pour entrer en concurrence avec Oracle, ce n'est pas le cas de PostgreSQL : ils est en train de rattraper son retard à grands pas et ce qu'il lui manque, c'est de la popularité. Si MySQL coule, PostgreSQL prendra sa place, et ça, c'est la mort pour Oracle ... Surtout que Postgre est maintenant supporté par RedHat.
Imaginez que toutes les installations actuellement sous MySQL migrent sur PostgreSQL : tous le monde aurait déjà travaillé avec cet SGBD et risquerait de ne pas voir l'intérêt d'acquérir une licence Oracle à un prix exorbitant alors que PgSQL, qui est gratuit et libre, fournit déjà une grande partie des fonctionnalités (et comme je l'ai dit plus haut, l'écart a tendance à se réduire). PostgreSQL ne serait plus le choix "lowcost" qu'il est aujourd'hui.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager