Pourquoi utiliser MySQL pour un site Web avec dictionnaire est-il une mauvaise idée?

Je prévois de concevoir et de configurer une base de données pour stocker les entrées de dictionnaire (généralement des mots simples) et leur signification dans une autre langue. Ainsi, par exemple, le glossaire de table doit avoir une entrée et une définition et chaque enregistrement de table contient une référence à l' id d'un enregistrement stocké dans Tag(chaque entrée doit avoir une étiquette ou une catégorie).

Puisque mes données ont une structure, je pensais que l’utilisation d’une base de données SQL (comme MySQL) n’était pas une mauvaise idée. mais les gens disent que MongoDB est bien meilleur pour la performance.

Du côté du client, l’application doit pouvoir fournir une zone de recherche avec la saisie semi-automatique qui utilise une API REST fournie par le backend. Est-il prudent d’utiliser MySQL dans un tel scénario? ou devrais-je utiliser MongoDB ou ElasticSearch avec une autre solution? Des centaines de milliers d'enregistrements sont supposés être stockés et accessibles de cette manière.

Je ne peux pas vous dire pourquoi c'est une mauvaise idée. Je peux cependant vous expliquer de nombreuses raisons pour lesquelles une base de données relationnelle est une bonne idée.

1. Rappelez-vous que tout le monde ne consulte pas un dictionnaire pour une définition. Plus souvent qu'autrement, un dictionnaire est utilisé pour trouver l'orthographe correcte. Cela signifie que vous ne trouvez pas simplement une aiguille dans une botte de foin , vous recherchez des aiguilles similaires à celle décrite par l'utilisateur (si je peux utiliser un idiome).

   Vous ne ferez pas simplement des recherches de clés primaires. Vous ferez des recherches par mot clé

2. Les mots peuvent être liés, soit dans le sens, soit dans l'orthographe ( lire, lire , rouge et roseau )

   Chaque fois que vous voyez le mot "lié" pensez "Base de données relationnelle"

3. Si vous avez besoin de rapidité, vous avez besoin d'une mise en cache sur votre base de données relationnelle, et non d'un modèle de données relationnel brisé.

4. Une base de données correctement normalisée accélère les recherches et les recherches de clés primaires car il y a tout simplement moins de bits à parcourir.

5. Les personnes qui affirment que les bases de données normalisées sont plus lentes se réfèrent aux 0,1% de cas où cela est vrai. Dans 99,9% des cas, ils n’ont pas réellement travaillé avec une base de données véritablement normalisée pour voir les performances de première main, alors ignorez-les. J'ai travaillé avec une base de données normalisée. Aimer. Je ne veux pas y retourner. Et je ne suis pas un gars de base de données. Je suis un gars C # / JavaScript / HTML / Ruby.

6. Les mots ont une origine. En fait, plusieurs mots de la même langue peuvent avoir la même origine, ce qui est un autre mot dans une langue différente. Par exemple, résumé (ce que nous téléchargeons sur les sites Web des recruteurs pour pouvoir recevoir des appels téléphoniques et des courriels incessants pour les 7 prochaines années) est un mot français.

7. Un dictionnaire définit également le type de mot (nom, verbe, adjectif, etc.). Ce n'est pas juste un morceau de texte: "nom", il a aussi un sens. De plus, avec une base de données relationnelle, vous pouvez dire des choses telles que "donnez-moi tous les noms pour la langue anglaise" et, comme une base de données normalisée utilisera des clés étrangères, et que les clés étrangères ont (ou devraient avoir) des index, la recherche se fera en un clin d'œil.

8. Pensez à la façon dont les mots sont prononcés. En anglais en particulier, beaucoup de mots ont la même prononciation (voir mon exemple ci-dessus avec read et reed, ou read et red).

   La prononciation d'un mot est, en soi, un autre mot. Une base de données relationnelle vous permettrait d'utiliser des clés étrangères pour toutes les prononciations. Ces informations ne seront pas dupliquées dans une base de données relationnelle. Il est dupliqué comme un fou dans une base de données sans SQL.

9. Et maintenant parlons des versions plurielles et singulières des mots. :) Pensez "bateau" et "bateaux". Ou le fait même qu'un mot est "singulier" ou "pluriel".

10. Oh! Et maintenant parlons du passé, du présent, du futur et du participe présent (pour être honnête, je ne sais pas ce que c’est que le "présent participe". Je pense que cela a quelque chose à voir avec les mots qui se terminent par "ing" dans Anglais ou quelque chose).

    Cherchez "run" et vous devriez voir les autres temps: couru, court, courant

    En fait, le «temps» est une autre relation elle-même.

11. L'anglais ne le fait pas tellement, mais le genre est une autre chose qui définit un mot. Les langues comme l’espagnol ont des suffixes qui définissent si le sujet du nom est masculin ou féminin. Si vous devez remplir les blancs d'une phrase, le genre est extrêmement important dans de nombreuses langues.

    Etant donné que vous ne pouvez pas toujours compter sur les conventions linguistiques pour déterminer le sexe (en espagnol, les mots finissant par "o" sont masculins / masculins, mais ce n'est pas le cas pour tous les mots), vous avez besoin d'une valeur d'identification: masculin ou féminin. C'est une autre relation qu'une base de données normalisée gère normalement même avec des millions d'enregistrements.

Avec toutes les règles tordues et les relations entre les mots, et même différentes langues, il m'est difficile d'imaginer ce magasin de données comme un "magasin de documents" comme le fournit une solution sans SQL. Il existe une telle variété de relations entre les mots et leurs composants qu'une base de données relationnelle est la seule solution sensée.

Si vous optez pour le magasin clé-valeur (qui vous offre un modèle de programmation plus appauvri) et qu'il s'avère que vous avez besoin de plus de structure (dans votre cas, par exemple, l'ajout d'un troisième langage), ou que vous devez effectuer des requêtes plus complexes impliquant des jointures. , vous passerez beaucoup de temps à réorganiser vos clés, à dénormaliser vos données et / ou à parcourir toutes les données pour trouver ce dont vous avez besoin.

Si vous commencez avec une base de données relationnelle, vous pouvez travailler sur la conception, le code et l’essayer de votre application en vous concentrant davantage sur le modèle de données naturel de votre application, plutôt que de le placer dans le formulaire valeur-clé.

Une fois l'application installée, vous pouvez travailler sur les performances en mesurant diverses options. Avant de devoir changer de technologie, il y a pas mal d’astuces de performance en SQL. Vous aurez beaucoup appris sur votre application et serez beaucoup mieux placé pour décider si les relations relationnelles vous font mal et si la valeur-clé fonctionnera pour votre modèle de données.

S'il s'avère que la valeur-clé correspond exactement aux besoins de votre application, vous pouvez passer sans avoir à perdre un investissement considérable dans le modèle relationnel, alors que l'inverse pourrait vous faire perdre du temps à faire en sorte que le modèle clé-valeur trivial dans le modèle relationnel.

Considérez la base de données relationnelle comme un accélérateur pour la conception, l’écriture et le bon fonctionnement de votre application, malgré les exigences en constante évolution, à mesure que vous en apprenez plus sur votre domaine et vos utilisateurs.

Lorsque vous avez des millions d'utilisateurs, vous aurez certainement besoin de refactoriser le design, même si vous aviez choisi la valeur-clé pour commencer.

Pour une base de données aussi petite, cela ne fera probablement pas beaucoup de différence en termes de performances. Un SGBDR standard n’est pas une très mauvaise idée ici, car on peut supposer qu’il devrait y avoir beaucoup plus de lectures que d’écritures pour une entrée donnée. Les performances ne semblent pas être le principal facteur pour cela. La mise en cache dans la couche d'application atténue également ces préoccupations.

L'autre considération est la réplication et la résilience. Les bases de données relationnelles ont tendance à être conçues autour d'une seule instance. Vous devriez lire le théorème de la PAC et réfléchir à ce qui compte le plus pour vous.

Ces bases de données NoSQL sonnent toujours comme une bonne idée au départ, mais vous aurez sûrement des problèmes lorsque vous commencerez à traiter des cas extrêmes (par exemple, lorsque les mots clés doivent être recherchés par leur valeur (ou une partie de ceux-ci), par exemple.

Il serait plus sûr d’opter pour une base de données relationnelle au début, puis de la dénormaliser plus tard. MySQL est génial pour ce type d’objet (bases de données relationnelles simples avec recherche textuelle), il n’ya pas beaucoup de cas d’utilisation dans lesquels vous constaterez des difficultés avec ce type de données. Assurez-vous simplement que vos index sont configurés correctement et que vous constaterez qu’ils fonctionneront à un niveau comparable (ou supérieur lorsqu’une recherche de texte) à une base de données NoSQL. Vous aurez ainsi la possibilité de modifier la logique de votre application sans être gêné. lié à une structure de données concrète.

Au fur et à mesure que vous trouvez l'utilisation la plus courante de vos données (et si vous trouvez que cela ne correspond pas à vos besoins en performances), vous pouvez alors procéder à la dé-normalisation des données en générant dans un format prédéfini qui peut être chargé (et récupéré). un schéma NoSQL.