Discussion :

[Tesing]

Sans parler de la fameuse date 0000-00-00 et autres fantaisies débiles de MySQL...

Sous MySQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET SQL_MODE = TRADITIONNAL

et hop c'est plus possible d'insérer des dates comme 0000-00-00



Certains chercheurs du CNAM Paris n'ont pas la même opinion que vous sur MySQL.

[kedare]

Cela n'a en pratique aucun intérêt car statistiquement les résultats étant différents pour chaque utilisateur dans plus de 99% des cas il faudrait des To de RAM pour une base de quelques Go pour que cela soit efficace !

Dans certains cas (notamment pour les sites), c'est le même utilisateur qui va effectuer les requêtes, donc dans ce cas la, le cache est vraiment utile...

Par contre j'ai commencé a vraiment tester certains trucs avec MySQL.... je suis vraiment déçu sur certains points: Tablespaces inutilisables avec InnoDB, Partitionnement Ultra limité (Impossible de faire un partitionnement HASH sur des strings, peut d'intérêt pour InnoDB vu qu'on peux pas choisir de Tablespaces différents...), le moindre ALTER TABLE reconstruit toute la table et les indexes.... Donc inutilisable sur des grosses tables sans downtime

Pourtant énormément de grosses entreprises et de gros sites utilisent MySQL, donc c'est que ca doit pas etre si mal... Coté Postgresql, a part sf.net, Météo France et Skype, je connais aucun gros site qui l'utilise...
Puis quand on vois que Twitter tourne sous un simple Master/Slave MySQL (Je sais pas si c'est toujours le cas, mais il y a quelques temps ca l'était: http://scaleordie.com/2008/02/23/twitter-architecture/ )

[SQLpro]

La plupart des grosses boîtes qui utilisent MySQL ne l'utilisent que pour le stockage, certainement pas pour la transaction ni l'interrogation des données... Le plus bel exemple fut SABRE que MySQL AB avait bien fait mousser !

A +