Jua*_*bío 2 mysql database-design
我正在开发一个关于反义词、同义词和“类似说话”词的简单语言游戏。
如果您在“同义词屏幕”中玩游戏，游戏将向您显示两个同义词和两个不相关的单词，您必须猜测哪个是同义词。
如果您在“反义词屏幕”中玩游戏，游戏将向您显示两个反义词和两个不相关的单词，您必须猜测哪个是反义词。
如果您在“说话屏幕”中玩游戏，游戏会向您显示两个“相似的说话”词，每个词都会说一个，您必须猜测哪个是。
我的问题是您可以有多个同义词，例如：
愤怒：被激怒、愤怒、愤怒、被冒犯等。
爱：亲情、激情、奉献等。
我的第一个想法是这样的：
表同义词：
+-----------+-------------------+
| word | related |
+-----------+-------------------+
| angry | enraged |
| angry | furious |
| angry | irated |
| angry | offended |
| enraged | furious |
| enraged | irated |
| enraged | offended |
| furious | irated |
| furious | offended |
| irated | offended |
| love | affection |
| love | passion |
| love | devotion |
| affection | pasion |
| .... | .... |
+-----------+-------------------+
并以相同的方式构建反义词和说话表。
但这似乎需要大量工作，而且很难添加/删除一个同义词。
另外，我不知道在哪里可以放置有关如何说出每个单词的信息。也许另一个表像：
+-----------+-------------------+
| word | pronuciation |
+-----------+-------------------+
| angry | ?aNGgr? |
| enraged | en?r?jd |
| .... | .... |
+-----------+-------------------+
该关联实体的想法是处理一个很好的方式，但它有一个缺点，那你可能要考虑。
在其他一些答案中尚未解决的问题是您将如何维护所有这些数据。这将是一项艰巨的工作，特别是如果您想在不知道从哪个单词开始的情况下，就能够从一个单词转换为它的任何同义词（或反义词）。想想你的{愤怒、愤怒、愤怒、恼怒、被冒犯}的例子。这是一组五个同义词。如果您使用关联实体，您将拥有这些对：angered=enraged、angered=furious...等等。您还必须反过来使用它们：enraged=angry、furious=angry，等等。
五个同义词并不多。但是，如果您为 5 个同义词制作一个关联表，您将有 10 个条目。对于 6 个同义词，您将有 15 个，对于 7 个同义词，您将有 21 个。您可以看到这可能会如何失控。
替代方案：通过根关联 好消息是还有另一种方法可以做到这一点。如果您选择一个同义词并将其作为基本词或词根（例如在您的情况下为“angry”），那么您可以在一张表中为这些词中的每一个创建一条记录（五个同义词 = 五个记录，在表中包括“angry”）您的单词列表），然后是仅包含词根的第二个表格（例如“生气”）
关键（双关语）是让单词列表指向它们的基本词或词根。这将通过外键进行。
所以在你的单词表中，你可能有这样的东西：
生气 = 生气
生气 = 生气
愤怒 = 生气
生气=生气
生气=生气
现在，您可能希望在上述每一项的第二列中使用无意义的数字键而不是“生气”。由于各种实际原因，这可能会使事情变得更容易。在这种情况下，您将有第二个表格，其中仅包含基本单词及其无意义的数字键，例如：
所以你的单词表看起来更像这样：
生气, 123
愤怒，123
愤怒, 123
生气, 123
被冒犯了, 123
那么如何找到一个词的同义词呢？
这是一个简单的过程，但它是一个两步* 过程：
查找给定单词的根键。假设您要查找“furious”的同义词。你查了一下，发现根号是 123。
查找与您的单词具有相同根键的所有单词，这些是您的同义词。
这样做的好处是它可以为您节省大量的数据维护。您只需为每个单词维护一个记录，并为每组同义词维护一个记录。这比所有同义词的组合要少得多，如果您使用关联实体执行此操作，您就会看到这种情况。
*注意：您实际上不必分两步执行此操作。您可以编写一个 SQL，使用self join将所有这些组合到一个语句中。