???Envoyé par kleber95
N'importe laquelle !
Pourquoi ?
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 :
???
N'importe laquelle !
Pourquoi ?
Je vais répondre même si tu m'as pas posé la question directement
Personnellement, j'utilise InnoDb pour son coté relationnel, Example pour faire mes testes sans que j'ai besoin qu'il y ait des data, moteur CSV pour gérer mes données en CSV sans passer par un langage tiers, Memory pour gérer mes data volatil dans le sens ou j'ai besoin d'un accessibilité rapide mais pas permanente, genre les sessions.Merge pour gérer le gros volume de données et le découper. Archive pour des data de type log.
Voila
Le problème c'est que tu sembles volontairement ignorer ce pour quoi MySQL existe. Il est évident qu'il n'est pas conçu pour faire une application gérant des gigas de données. MySQL est fait pour stocker des infos web, majoritairement du texte. Évidemment, il ne faut pas stocker de données sensibles dessus. Et c'est bien pour ça que les banques ne l'utilisent pas :p
Comparer Oracle/SQLServer/DB2 à MySQL c'est comme comparer un tournevis et un marteau. On peut utiliser les deux pour mettre une vis...
Bref, MySQL pour stocker ton PHP sur un serveur mutualisé qui te propose une solution LAMP, c'est extra. Je n'ai pas besoin d'un gros SGBD pour faire ça.
Et, de toutes façons, tant que les hébergeurs proposeront MySQL de façon quasi systématique dans leurs hébergements mutualisés, je doute que ce SGBD meure :p
MerciJe vais répondre même si tu m'as pas posé la question directement
Personnellement, j'utilise InnoDb pour son coté relationnel, Example pour faire mes testes sans que j'ai besoin qu'il y ait des data, moteur CSV pour gérer mes données en CSV sans passer par un langage tiers, Memory pour gérer mes data volatil dans le sens ou j'ai besoin d'un accessibilité rapide mais pas permanente, genre les sessions.Merge pour gérer le gros volume de données et le découper. Archive pour des data de type log.
Voila
Mais innodb devait être remplacé par falcon ?
Sachant que innodb n'évolue plus, qu'il a été racheté par ORACLE depuis des années, qu'il comporte des solutions de sauvegarde à chaud ... payante.
Complètement d'accord avec ça
La crainte de Bruxelles doit justement être que les hébergeurs ne puissent plus proposer MySQL.
Mais je ne comprend pas pourquoi le rachat de MySQL par SUN n'avait pas fait autant de bruit à l'époque, ainsi que quand les créateurs de MySQL se sont cassé de chez SUN, car c'est à partir de ce moment que tout devenait possible.
SI on utilise le moteur MyISAM, c'est entièrement vrai !... Il n'est même pas relationnel ce système
Comme Sun n'était pas déjà premier sur le marché des bases de données, je pense que la CE n'avait rien à redire en matière de concurrence.
En effet, mais Innodb sera toujours présent. Il y a d'autre moteur qui arrive telle que Maria et Falcon comme tu le site mais avec le rachat par Oracle de Mysql je pense que c'est un peut mis en suspend. D'après des tests, InnoDb reste quand même plus performant que Falcon. Mais ce bench à été réalisé avant le rachat par Sun de Mysql. Depuis, ils ont sortie une version qui est sévèrement boosté.Merci
Mais innodb devait être remplacé par falcon ?
Sachant que innodb n'évolue plus, qu'il a été racheté par ORACLE depuis des années, qu'il comporte des solutions de sauvegarde à chaud ... payante.
C'est bien plus qu'un potentiel. En plus des moteurs fournis en standard avec MySQL (MyISAM, InnoDB, Memory, Archive, CSV, Federated et MRG_MyISAM), il y en a beaucoup d'autres : SoldDB, Nitro, BerkeleyDB (le moteur du SGBD du même nom), et même le moteur de DB2, d'IBM, justement. Il y a aussi un moteur OLAP dont le nom m'échappe. Et j'en oublie. Je n'ai pas encore trouvé de moteur basé sur XML, mais ça serait sûrement un projet intéressant à faire...
Personnellement, je me sers d'InnoDB (moteur transactionnel) et de Memory (moteur entièrement en mémoire, très performant. Je m'en sers pour les données statiques), avec un peu de MyISAM (très rapide pour les recherches texte, mais non-transactionnel). Je suis en train d'examiner SolidDB qui semble plus performant, mais ça n'est pas encore suffisamment urgent...
Falcon est le moteur de MySQL 6, qui n'est pas encore sorti.Merci
Mais innodb devait être remplacé par falcon ?
Sachant que innodb n'évolue plus, qu'il a été racheté par ORACLE depuis des années, qu'il comporte des solutions de sauvegarde à chaud ... payante.
Sinon, InnoDB continue tout à fait à évoluer. La version 1.0.4 est sorti en août.
Le communiqué de presse :
http://www.innodb.com/wp/2009/08/11/...-104-released/
et 40moteurs différents pour 1 seul sgbd ça vous choque pas vous? C'est pour ça que je n'aime pas l'open source, tout le monde apporte son grain de sel dans la sauce sans concerter qui que ce soit et on se retrouve avec 40versions différentes d'un même produit.
Et pourquoi ça serait choquant ? C'est une richesse.
Le foisonnement d'idées et de réalisations du libre te choque ? Je trouve ça étrange, comme attitude. Tu préfères les milieux plus aséptisés, peut-être ?
Tiens, un livre qui pourrait t'intéresser : "La cathédrale et le bazar", d'Eric S. aymond
Encore une fois, tu n'as pas compris l'utilité et le fonctionnement de ses moteurs. Les différents moteurs qui existe n'ont pas pour but de faire la même chose mais bien de répondre à une demande spécifique. Donc, il y a pas lieu qu'ils se concerte entre eux. Il y a un article que j'ai fais sur ce sujet.
Etant donné que chaque moteur (je ne les connais pas tous en détail ceci-dit, mais après cf. l'article posté précédemment) ont des spécificatés, des fonctionnalités et des utilités propres, non ce n'est pas gênant bien au contraire. Je ne suis pas non plus particulièrement fan de l'open-source, mais MySQL reste un bel exemple de ce qui peut être fait de bien dans ce domaine.
Ce ne sont pas 40 versions d'un même produit...
ça permet d'optimiser les tables de sa base de données pour convenir au mieux au besoin que l'on a.
On peut tres bien avoir des tables InnoDB, MyISAM ou MEMORY sur la même base de données MySQL et faire de jointures entre elles sans rien à faire de particulier.
ça peut s'assimiler au type d'un champ dans uns table.
Si tu souhaite créer un champ qui dois contenir des nombres entiers, tu ne va pas créer un champ de type texte.
Et bien pour les tables c'est pareil.
J'ai tout à fait compris à quoi sert MySQL, me prend pas pour un con non plus. Je n'aime pas le même produit que vous pour diverses raisons et forcément j'ai pas compris son utilité. Il n'empêche que proposer 40moteurs pour 1 même produit c'est reconnaitre que la version basique est incomplète.
Nouvel angle d'attaque.
Après avoir vainement essayer de faire croire que MySQL n'était pas performant, Lyche est maintenant a obliger de faire machine arrière et prétendre que le fait qu'il y est plusieurs moteur est un problème
Tu comprend vraiment ce que tu veux toi hein. Je te laisse débattre avec tes copains vous me faites trop chier j'ai plus envie de perdre du temps avec vous.Nouvel angle d'attaque.
Après avoir vainement essayer de faire croire que MySQL n'était pas performant, Lyche est maintenant a obliger de faire machine arrière et prétendre que le fait qu'il y est plusieurs moteur est un problème
Pas du tout. Les différents moteurs ont des avantages et des inconvénients. Si tu ne comprends pas, par exemple, qu'un moteur stockant toutes les données en RAM n'est pas utilisable dans tous les cas, mais que dans les cas où on peut s'en servir, c'est très performant, je ne vois pas comment t'expliquer...
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
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