为什么将MySQL用于字典网站是个坏主意？

我打算设计和建立一个数据库，以存储词典条目（通常是单个单词）及其在另一种语言中的含义。因此，例如，表Glossary必须具有条目和定义，并且每个表记录都具有对存储在其中的记录的ID的引用Tag（每个条目必须具有标签或类别）。

由于我的数据具有结构，因此我认为使用SQL数据库（如MySQL）并不是一个坏主意；但是人们说MongoDB的性能要好得多。

在客户端，应用程序必须能够提供一个具有自动完成功能的搜索框，该框使用后端提供的REST API。在这种情况下使用MySQL是否安全？还是应该为此使用MongoDB或任何其他解决方案的ElasticSearch？应该以这种方式存储和访问数十万条记录。

我不能告诉你为什么这是一个坏主意。我可以告诉您一系列关系数据库为何是个好主意的原因。

1. 请记住，并不是每个人都参考字典来定义。使用字典来查找正确的拼写的次数多过很多。这意味着您不仅在大海捞针中找到一根针，而且还在大海捞针中搜索与用户所描述的针相似的针（如果我可能使用成语的话）。

   您将不仅会进行主键查询。您将进行关键字搜索

2. 单词可以含义或拼写相关（阅读，阅读，红色和芦苇）

   每当您看到“相关”一词时，请思考“关系数据库”

3. 如果需要速度，则需要在关系数据库之上进行缓存，而不是损坏的关系数据模型

4. 正确归一化的数据库可以加快主键查找和搜索的速度，因为筛选的位数很少。

5. 那些说标准化数据库的速度较慢的人指的是0.1％的情况是正确的。在其他99.9％的情况下，他们实际上并没有使用真正的规范化数据库来直接查看性能，因此请忽略它们。我已经使用标准化数据库。爱它。不想回去。而且我不是数据库专家。我是C＃/ JavaScript / HTML / Ruby的人。

6. 单词有起源。实际上，同一语言中的许多单词可以具有相同的来源，这是另一种语言中的另一个单词。例如，résumé（我们上传到招聘网站上的东西，以便在接下来的7年中不断收到电话和电子邮件）是一个法语单词。

7. 字典还定义了它是什么样的单词（名词，动词，形容词等）。这不只是一段文字：“名词”也具有含义。再加上关系数据库，您可以说“给我英语的所有名词”之类的事情，并且由于规范化数据库将利用外键，并且外键具有（或应该具有）索引，因此查找将非常容易。

8. 想想单词的发音。特别是在英语中，许多单词的发音相同（请参阅上面的示例，其中包含read和reed或read和red）。

   一个单词的发音本身就是另一个单词。关系数据库将允许您对任何发音使用外键。该信息不会在关系数据库中重复。它在无SQL数据库中疯狂地复制。

9. 现在让我们讨论单词的复数形式和单数形式。:)想想“船”和“船”。或一个单词是“单数”或“复数”的事实。

10. 哦! 而现在让我们来谈谈过去时，现在时，将来时和现在分词（说实话，我不知道是什么的废话“现在分词”是什么。我认为这是与在“ing”的结尾的单词英语等）。

    查找“运行”，您应该看到其他时态：运行，运行，运行

    实际上，“紧张”本身就是另一种关系。

11. 英语并没有那么做，但是性别是定义单词的另一回事。西班牙语之类的语言带有后缀，用于定义名词的主题是男性还是女性。如果您需要为句子填写空白，性别在许多语言中都非常重要。

    由于您不能总是依靠语言约定来确定性别（在西班牙语中，以“ o”结尾的单词是男性/男性，但并非所有单词都如此），因此您需要一个可识别的值：“男性”或“女性”。这是规范化数据库即使在数百万条记录中也能正常处理的另一种关系。

有了所有甚至在语言之间甚至语言之间都存在着扭曲的规则和关系，我很难想象这个数据存储就像一个无SQL解决方案所提供的“文档存储”。单词及其组成部分之间的关​​系是如此之多，以至于关系数据库是唯一明智的解决方案。

如果您使用键值存储（它为您提供了更加贫困的编程模型），结果您需要更多的结构（例如，添加第三种语言），或者需要执行涉及联接的更复杂的查询，您将花费大量时间来重新组织密钥，对数据进行非规范化和/或遍历所有数据以查找所需内容。

如果从关系数据库开始，则可以研究应用程序的设计，代码，并尝试将其更多地集中在应用程序的自然数据模型上，而不是将其塞入键值形式。

一旦应用程序稳定下来，您就可以通过测量各种选项来提高性能。在需要切换技术之前，在SQL中有很多性能技巧。您将学到很多有关您的应用程序的知识，并且可以更好地确定关系是否对您造成伤害，以及键值是否适用于您的数据模型。

如果事实证明键值正是您的应用程序所需要的，那么您就可以进行切换而不必在关系模型上浪费大量的投资，而反之，则可能最终会浪费时间使键值模型执行那些在关系模型中微不足道。

面对不断变化的需求，当您了解有关域和用户的更多信息时，可以将关系数据库视为促进设计，编写和运行应用程序的加速器。

当您拥有数百万的用户时，即使您从一开始就选择了键值，几乎肯定还是需要重构设计。

对于这么小的数据库，可能不会对性能产生太大影响。在这里，标准RDBMS并不是一个糟糕的主意，因为大概，给定条目的读取次数应该比写入次数多得多。性能似乎并不是此的主要驱动力。在应用程序层中进行缓存也可以缓解这种担忧。

另一个考虑因素是复制和弹性。关系数据库倾向于围绕单个实例进行设计。您应该阅读CAP定理，并考虑最重要的事情。

这些NoSQL数据库从一开始就听起来总是个好主意，但是当您开始处理边缘情况（例如关键字必须通过其值（或一部分）来查找）时，一定会遇到问题。

首先使用关系数据库，然后再进行非规范化是比较安全的选择。MySQL对于这种目的非常出色（具有基于文本搜索功能的简单关系数据库），没有太多用例，您会发现它在这种数据上苦苦挣扎。只要确保您已正确设置索引，您就会发现它的性能可以与NoSQL数据库媲美（或者在进行文本搜索时更好），并且可以灵活地修改应用逻辑绑定到一个具体的数据结构。

当您发现数据的最常用用法（并且如果发现它不能满足您的性能需求）时，您可以通过输出为可以加载到（以及从中检索）的设置格式来对数据进行非规范化处理。 NoSQL模式。