Structure de la base de données - mySQL est-il le bon choix?

Question

Nous planifions actuellement la structure de la base de données d'une application web e-commerce assez complexe dont la flexibilité est la pierre angulaire.

Notre application comporte une grande quantité de données (produits) et nous avons rencontré un léger casse-tête en essayant de maintenir des performances élevées sans compromettre les règles de normalisation de la base de données, ou en abandonnant notre concept de flexibilité bien-aimé lors de l'intégration des options de produits (également largement connues sous le nom d'attributs ou de paramètres de produits).

Sur la base de diverses références et sources disponibles, nous avons dressé des listes des avantages et des inconvénients de tous les principaux modèles de base de données bien connus pour résoudre ce problème. Après les avoir comparés, nous avons retenu deux alternatives finales :

• Modèle EAV (Entity-attribute-value) :

  Avantages : La base de données est utilisée pour tous les tris.

  Inconvénients : Toutes les requêtes associées incluront un certain nombre de jointures entre plusieurs tables pour compléter la collection de données.

• Modèle SLOB (LOV sérialisé, aussi connu sous le nom de Facade ?) :

  Avantages : Très flexible. Garde le nombre de jointures nécessaires bas par rapport à un modèle de conception EAV. Facile à mettre à jour/ajouter/supprimer des données de chaque produit mais difficile de maintenir l'intégrité des données sans tables supplémentaires.

  Inconvénients : Tous les tris seront effectués par l'application au lieu de la base de données. Utilisera beaucoup de performances (mémoire ?) lorsque de grands ensembles de données sont traités par un grand nombre d'utilisateurs.

Nos principales questions :

• Quel modèle/structure utiliseriez-vous, ou peut-être même une solution différente ?
• Y a-t-il de meilleures bases de données que mySQL disponibles actuellement pour accomplir ce que nous voulons ?

Merci beaucoup !

Référence : Comment concevoir une table de produits pour de nombreux types de produits, chaque produit ayant de nombreux paramètres

Answer 1

MySQL fonctionne très bien même pour de très grands ensembles de données. Je l'utilise dans une société de services financiers SaaS et cela a toujours bien fonctionné. J'ai aussi utilisé SQL Server et Oracle pour de très grandes applications et MySQL ne performe ni mieux ni moins bien dans l'ensemble. Mon domaine de prédilection est davantage la couche métier, cependant, vous pourriez obtenir des opinions plus détaillées de personnes plus proches de la base de données.

Lors du choix d'un schéma, gardez à l'esprit qu'il est beaucoup plus simple de faire évoluer la couche application que la couche données (il est facile et peu coûteux d'ajouter des serveurs d'application). Effectuer de nombreuses jointures pour des opérations courantes peut entraîner un véritable goulot d'étranglement en termes de performances.

Je vous suggère de prototyper les deux approches afin de vous familiariser davantage avec chacune d'elles, et de mesurer leurs performances dans votre environnement spécifique.

De plus, vous pouvez également envisager des alternatives au SQL qui tentent d'atteindre un schéma similaire à ceux que vous décrivez. Un ami travaillant pour une très grande entreprise Internet bien connue commence à utiliser Project Voldemort. Il le préfère à d'autres efforts similaires principalement en raison de la communauté très active.

Answer 2

De votre solution, il semble que vous ne voulez pas utiliser de modèle relationnel, donc il est peut-être préférable de ne pas utiliser de base de données relationnelle. Jetez un œil à ces alternatives : http://nosql-database.org/. Au fait, SQLServer a de belles fonctionnalités SLOB sous forme de champs XML (qui peuvent être indexés et interrogés via XQuery).

Answer 3

Pourquoi vous limiter à un seul modèle ? Il est tout à fait possible que vous ayez de meilleurs résultats avec deux modèles différents, chacun répondant parfaitement à un objectif spécifique.

En supposant, comme c'est souvent le cas, que les deux ne doivent pas être absolument et instantanément synchronisés, vous pourriez facilement obtenir des performances globales bien meilleures. Quels seraient les exigences strictes en matière de synchronisation ? Des millisecondes jusqu'à une minute ?

Udi Dahan a de bonnes informations sur la séparation des responsabilités de commandes et de requêtes (CQRS) qui sont pertinentes. Consultez également quelques autres articles. InfoQ propose également une vidéo pertinente de Greg Young de QCon08.

ÉDIT : Voici une autre vidéo (par Udi Dahan) qui aborde, entre autres, les avantages de plusieurs modèles.