Question

我目前有一个“强”用户表格

示例:

Languages known: checkbox PHP, Java, Ruby

OS knowledge: Windows, Linux, Mac

目前我的数据库表是这样的:

USER
----------------------------------------
|  ID  |  Name      |  
-----------------------
|   1  |    John    |    
-----------------------
|   2  |    Alice    |    
-----------------------

LANGUAGES
----------------------------------------
|  ID  | User_ID(FK)     | lang-name  | 
----------------------------------------
|   1  |    1            |   PHP      |
----------------------------------------
|   1  |    2            |   Java     |
----------------------------------------

OS
----------------------------------------
|  ID  | User_ID(FK)     | os-name  | 
----------------------------------------
|   1  |    1            | Windows  |
----------------------------------------
|   1  |    2            |  Windows |
----------------------------------------

这看起来像是一个好的方案吗? 与用户有关的领域还有很多,每个领域都需要有自己的表格,而且表格中似乎有许多冗余,因为成千上万的用户会知道PHP,因此,会有成千上万行的PHP作为每个不同用户的语言。

" 强者 " 是否有更好的组织方法? " /强者 "

Answer 1

也许你可以在数据库中用自己的表格建立 Language 和 OS 头等实体,然后用一个组合表格处理与 user 的多种关系。

User
---------
ID
Name
etc...

Language
---------
ID
Name

OS
---------
ID
Name

UserLanguage
---------
UserID
LanguageID

UserOS
---------
UserID
OSID

这样,实际实体( User , Language , OS )就具有自成一体的性质,只有对其有意义的数据,而不是由于彼此关系方面的关切而被污染或重复的数据。这些关系包含在它们自己的简单的数字化表格中,它们本身不是实体,而只是实体之间的许多对多种联系。

没有重复数据(在你的抽样数据中, Language 和 OS 将各只有三份记录,至少目前是这样),如果需要使用,这些数据对ORMS和其他框架非常友好。

Edit: 基于您的评论, 您可以尝试这样的方式 :

User
---------
ID
Name
etc...

Lookup
---------
ID
LookupTypeID
Value

LookupType
---------
ID
Value

UserLookup
---------
UserID
LookupID

这给了您很多灵活性。在您的样本数据中, Language 和 >OS 将被记录在 LookupType 中。所有语言和OSs都将是 Lookup 中的数值,这些数值与它们各自的 LookupType 相链接。所以仍然不能重复数据。而只有 userLookup 表格是众多链接表格。

谨慎使用这个设计。它非常灵活, 绝对灵活。但是当您使用这个表格结构作为实际域模型时, 您会遇到“ 查看” 等术语成为商业术语的情况, 而情况可能并非如此。 “ 访问” 和“ OS” 是实际模型。我建议使用“ 视图或存储程序” 从代码中抽取这个结构。因此, 代码会将语言从语言视图或程序中提取出来, 而不是直接从 < code> Lookup 表格中提取出来。

友情链接