Pourquoi l'utilisation de MySQL pour un site Web de dictionnaire est-elle une mauvaise idée?
Je prévois de concevoir et de mettre en place une base de données pour stocker les entrées du dictionnaire (généralement des mots simples) et leur signification dans une autre langue. Ainsi, par exemple, la table Glossaire doit avoir entrée et définition et chaque enregistrement de table a une référence à l'ID d'un enregistrement stocké dans Tag (chaque entrée doit avoir une étiquette ou une catégorie).
Étant donné que mes données ont une structure, j'ai pensé que l'utilisation d'une base de données SQL (comme MySQL) n'est pas une mauvaise idée; mais les gens disent que MongoDB est bien meilleur pour les performances.
Côté client, l'application doit être en mesure de fournir une zone de recherche avec saisie semi-automatique qui consomme une API REST fournie par le backend. Est-il sûr d'aller avec MySQL dans un tel scénario? J'utilise MongoDB ou ElasticSearch de toute autre solution pour cela? Des centaines de milliers d'enregistrements sont censé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 vous dire un tas de raisons pour lesquelles une base de données relationnelle est une bonne bonne idée .
N'oubliez pas 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 n'êtes pas seulement trouver une aiguille dans une botte de foin , vous recherchez dans la botte de foin des aiguilles similaires à celle décrite par l'utilisateur (si je peux utiliser un idiome).
Vous ne ferez pas seulement des recherches de clé primaire. Vous ferez des recherches par mots clés
Les mots peuvent être liés, que ce soit en sens ou en orthographe ( lire, lire , rouge et rosea )
Chaque fois que vous voyez le mot "lié", pensez à "base de données relationnelle"
Si vous avez besoin de vitesse, vous avez besoin d'une mise en cache au-dessus de votre base de données relationnelle, pas d'un modèle de données relationnelles cassé
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.
Les gens qui disent que les bases de données normalisées sont plus lentes font référence au 0,1% des cas où cela est vrai. Dans les 99,9% des autres cas, ils n'ont pas réellement travaillé avec une base de données vraiment 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 revenir en arrière. Et je ne suis pas un type de base de données. Je suis un gars C #/JavaScript/HTML/Ruby.
Les mots ont une origine. En fait, de nombreux mots dans la même langue peuvent avoir la même origine, qui est un autre mot dans une langue différente. Par exemple, CV (ce que nous téléchargeons sur les sites Web des recruteurs afin que nous puissions recevoir des appels téléphoniques et des e-mails incessants pendant les 7 prochaines années) est un mot français.
Un dictionnaire définit également de quel type de mot il s'agit (nom, verbe, adjectif ect). Ce n'est pas seulement un morceau de texte: "nom", il a aussi un sens. De plus, avec une base de données relationnelle, vous pouvez dire des choses comme "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 sera un jeu d'enfant.
Pensez à la façon dont les mots sont prononcés. En anglais surtout, beaucoup de mots ont la même prononciation (voir mon exemple ci-dessus avec lu et roseau, ou lu et rouge).
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.
Et maintenant, parlons des versions plurielles et singulières des mots. :) Pensez "bateau" et "bateaux". Ou le fait même qu'un mot soit "singulier" ou "pluriel".
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 la merde "participe présent") "est. Je pense que cela a quelque chose à voir avec les mots se terminant par" ing "en anglais ou quelque chose).
Recherchez "run" et vous devriez voir les autres temps: run, runs, running
En fait, "tendu" est une autre relation elle-même.
L'anglais ne fait pas tellement cela, mais le genre est une autre chose qui définit un mot. Des langues comme l'espagnol ont des suffixes pour définir si le sujet du nom est masculin ou féminin. Si vous devez remplir les blancs d'une phrase, le sexe est extrêmement important dans de nombreuses langues.
Comme vous ne pouvez pas toujours vous fier aux conventions linguistiques pour déterminer le sexe (en espagnol, les mots se terminant par "o" sont masculin/masculin, mais ce n'est pas vrai pour tous les mots), vous avez besoin d'une valeur d'identification: masculin ou féminin. Il s'agit d'une autre relation qu'une base de données normalisée gère avec élégance, même sur 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 une solution sans SQL. Les relations entre les mots et leurs composants sont si nombreuses et si variées qu'une base de données relationnelle est la seule solution sensée.
Si vous optez pour le magasin de valeurs-clés (qui vous offre un modèle de programmation plus pauvre) et qu'il s'avère que vous avez besoin de plus de structure (dans votre cas, par exemple, l'ajout d'une troisième langue), 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 sur le ferrage de chaussures dans le formulaire de valeur-clé.
Une fois l'application installée, vous pouvez travailler sur les performances, en mesurant différentes options. Il y a quelques astuces de performance à faire en SQL avant de devoir changer de technologie. Vous aurez beaucoup appris sur votre application et serez bien mieux placé pour décider si le relationnel vous fait mal et si la valeur-clé fonctionnera pour votre modèle de données.
S'il s'avère que la valeur-clé est exactement ce dont votre application a besoin, vous pouvez basculer sans avoir gaspillé un investissement important dans le modèle relationnel, tandis que l'inverse pourrait éventuellement vous faire perdre du temps à faire en sorte que le modèle valeur-clé fasse des choses qui sont trivial dans le modèle relationnel.
Considérez la base de données relationnelle comme un accélérateur pour que votre application soit conçue, écrite et opérationnelle, face à des exigences en constante évolution à mesure que vous en apprendrez plus sur votre domaine et vos utilisateurs.
Lorsque vous avez des millions d'utilisateurs, vous devrez certainement refactoriser la conception de toute façon, 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 pour les performances. Un SGBDR standard n'est pas une idée terrible ici car, vraisemblablement, il devrait y avoir beaucoup plus de lectures que d'écritures d'une entrée donnée. Les performances ne semblent pas être un moteur principal pour cela. La mise en cache dans la couche application atténue également ces problèmes.
L'autre considération est la réplication et la résilience. Les bases de données relationnelles sont généralement conçues autour d'une seule instance. Vous devriez lire sur le théorème CAP et considérer 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 la garantie de rencontrer des problèmes lorsque vous commencerez à traiter des cas Edge (par exemple, lorsque les mots clés doivent être recherchés par leur valeur (ou une partie de) par exemple).
Ce serait une option plus sûre d’utiliser une base de données relationnelle au départ, puis de la dénormaliser plus tard. MySQL est génial pour ce genre d'objectif (bases de données relationnelles simples avec recherche textuelle), il n'y a pas trop de cas d'utilisation où vous aurez du mal avec ce type de données. Assurez-vous simplement que vos index sont correctement configurés et vous constaterez qu'il fonctionnera à un niveau comparable (ou mieux lors d'une recherche de texte) à une base de données NoSQL, et il vous donnera la flexibilité de modifier la logique de votre application sans être 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 jamais vous trouvez qu'elles ne répondent pas à vos besoins de performances), vous pouvez ensuite procéder à la dénormalisation des données en les sortant dans un format défini qui peut être chargé (et récupéré à partir de) un schéma NoSQL.