数据库设计:多个相同类型的项目

时间:2011-02-24 08:19:37

标签: database-design

我不确定如何在这个问题上说出来,所以我会解释我在想什么。我之前有过设计数据库的经验,但实际上还没有决定我是如何实现这个或者之前运行的。我会解释我在想什么作为表达方式我已经考虑过了......

我正在创建一个数据库,用于存储用户的信息,例如简历(这是一群大学生的副项目)。我遇到的问题是如何处理存储大量技术技能的事情,可能是每个用户20+的顺序以及他们的熟练程度

创意一:一张巨大的桌子,上面有TechSkill1的列 - > 20.随着他们的熟练程度。使用用户ID作为FK与所有这些相关。 优点:最简单的实施,最简单的前端。 缺点:限制为20种技能,很多可能存在空值,尺寸过大

理念二:大型文本输入表,其中所有技能都在一个文本对象中,由逗号或|等字符分隔。另一个熟练的专栏以同样的方式划界。同样,USERID作为FK。 优点:易于实现,桌面尺寸小,易于在前端获取信息 缺点:浪费大量空白空间的可能性,需要在商店之前在前端进行更多编码,然后再进行检索。

创意三:小技巧和精通专栏。然后创建多个行以与每个USERID相关联 优点:最小的桌子和最干净的。节省最多空间 缺点:前端实现将是有趣的,如何处理多个字段的无限数量的条目(不是我的东西,但我不想为前端人员创建太多问题)

这是我的三个想法,我不完全确定最好的是什么......我问你们。非常感谢所有建议。

谢谢!

-Jabsy

4 个答案:

答案 0 :(得分:1)

在数据库级别实现此功能的最佳方法是创建4个表:

  
  • USERS(你可能有这个)
  •    
  • 技能
  •    
  • PROFICIENCIES
  •    
  • SKILLS_PROFICIENCIES(fk_userid,fk_proficiencyid,fk_skill_id)
  •  

这样您就不会浪费空间,您的架构将更具可扩展性和可维护性。

您解决了前端实施的问题。解决这个问题的最佳方法是使用更多“前端友好”数据视图创建数据库视图(您使用哪个数据库引擎?)。将模式非规范化以简化前端开发并不是一个好主意,主要是因为数据操作是信息系统中最脆弱的操作。保持您的架构清洁,以后在扩展和添加新功能时将为您节省很多麻烦。

答案 1 :(得分:0)

我是这样做的。

表1:包含列出所有可能技能的单个列。

表2:包含三列,一列的userID和第二列的关联技能。使用复合键,第二列仅限于第一个表中的条目。加上第三列的能力水平(这可能需要引用另一个表,它取决于它只是一个值还是一个单词)。用户可能在表中有20个不同的条目。

答案 2 :(得分:0)

以标准化方式存储数据。带有USER主键的USER_ID表,带有SKILL主键的SKILL_ID表和带有USER_SKILL的{​​{1}}表,USER_IDSKILL_ID列。

我不确定我是否理解这是否是您所建议的第三种选择。如果是的话,我不太确定你对前端有什么问题。据推测,将有一个界面,用户可以添加新技能并输入他们的熟练程度。这似乎非常自然地映射到正确规范化的模式。

答案 3 :(得分:0)

我将创建3个表:

  • USER表格中包含PK USER_ID
  • SKILL表格中包含PK SKILL_ID,以及一列SKILL_DESCRITPION
  • USER_SKILL表,结构如下:
    • USER_ID,FK引用USER.USER_ID
    • SKILL_ID,FK引用SKILL.SKILL_ID
    • PROFICIENCY

通过这种方式,只需在SKILL表中插入新的技能记录,它就可以让您灵活地在将来包含更多不同的技能类型。

有关如何查询每个用户的技能和熟练程度的结果,如果您使用的是oracle,可以参考此http://bytes.com/topic/oracle/answers/64603-help-decode-function-crosstab-query。您的问题描述应与此链接描述相同。

相关问题