我打算整理一个可用于查询单词同义词的数据库。数据库最终会变得庞大,因此我们的想法就是让事情快速运行。
我一直在考虑如何做到这一点,但是这些天我的数据库设计技巧还不尽如人意。
我最初的想法是将每个单词存储在一个表中,然后将另一个表存储在1到多个关系中,其中每个单词可以链接到另一个单词,并且可以查询该表。
我正在开发的应用程序允许用户突出显示一个单词,然后键入,或从数据库中为该单词选择一些同义词。应用程序从用户输入中学习,因此如果某人突出显示“car”并输入“motor”,则数据库将被更新以链接该关系(如果该关系已经不存在)。
我不想发生的是用户输入单词“shop”并将其链接到单词car。所以我想我需要为每个关系增加一些分量。
最终将使用用户输入的同义词,以便他们可以自动选择与某个单词一起使用的常用同义词。重量较轻的单词不会显示,所以除非车的重量非常高,否则车间永远不会成为汽车的同义词,而且很可能没有人会这样做。
上述声音是否合适?你能提出任何建议或改进吗?
答案 0 :(得分:1)
从关系数据库的角度来看,你真正想要的是单词之间的多对多关系,可能还有一些关于这种关系的额外数据。
关系表看起来像:
WORD_TABLE
----------
id
word
RELATION_TABLE
--------------
word_1_id
word_2_1d
weight
我建立它的方式是以用户可以投票(向上或向下)各种单词对的方式进行。这将以相当简单的方式为您提供所需的重量。您可能还希望使用词库或其他类似来源的数据预先填充它以涵盖已知的同义词,并为您的用户减少工作量。
此外,这种数据结构的另一个术语是加权图。
通常,关系数据库在建模图时并不是特别擅长(他们可以做到,但有更好的选择)。您可能希望查看图形数据库(Neo4J可以想到)作为关系数据库的替代方案。
答案 1 :(得分:0)
它似乎是同一实体集的实体内的多对多关系。我会为所有单词创建一个表,为关系创建另一个表。关系表将有两个用于word表的外键。表格将类似于
Word (w_pk, ....)
Synonym (fk1_to_w_pk, fk2_to_w_pk, weight)
在Synonym
中添加条目时,您必须检查
- fk1_to_w_pk ≠ fk2_to_w_pk
- both (fk1_to_w_pk, fk2_to_w_pk) and (fk2_to_w_pk, fk1_to_w_pk) do not already exist in Synonym
答案 2 :(得分:0)
这应该很好用:
create table suggestions (
word varchar(255),
suggestion varchar(255) not null,
weight float not null default 1.0,
primary key(word, suggestion, weight)
);
select suggestion from suggestions where word = ? and weight > 3 order by weight desc.