针对情境相关数据的数据库表设计

时间:2013-04-03 19:57:28

标签: database postgresql database-design

假设您有一个表格,其中包含非常依赖于情境的数据。

一个例子是玩家选择获胜的游戏集合。应该存储此选择,但游戏是不同的,因此在一个游戏中的选择不适合另一个游戏中的选择。

一般来说,最好是使表格足够广泛以处理所有情况,并为每个条目留下一些(但不同的)部分,或者我应该为每个案例制作一个特殊的表格吗?

或者还有其他一些技术会更好吗?

3 个答案:

答案 0 :(得分:1)

我不确定,如果我理解你的话,你似乎想要一个需要3个表的m:n-relation:

CREATE TABLE game
    (
    id int PRIMARY KEY,
    game nchar(x)
    )

CREATE TABLE solution
    (
    id int PRIMARY KEY,
    solution nchar(x)
    )

CREATE TABLE game_solution
    (
    id int PRIMARY KEY,
    id_game int NULL REFERENCES game( id),
    id_solution int NULL REFERENCES solution( id)
    )

答案 1 :(得分:0)

你的问题是一般性的,所以简短的答案是:这取决于!时间越长:如果只有少数游戏没有太大差异,那么“宽泛”的表格就是一个简单的解决方案。在某些情况下,我会寻求解决方案,但一般情况下不会。

我的建议是:问问自己,所有选择/选择的共同点是什么。该数据应该转到一般表。特定游戏的数据应该是每场比赛的一个单独的相关表格。

不知道你作为程序员的背景如何。但是如果您熟悉OO编程,只需谷歌搜索如何将类层次结构映射到SQL数据库的策略。

答案 2 :(得分:0)

@Lars:我刚读过你的问题。

保持简短:

  1. 如果您需要最高性能,请将其保持完整结构,即使您必须创建许多新表格。

  2. 如果您需要灵活性,e。 G。在不考虑性能的情况下,存储未知游戏的结果,而不考虑性能,存储二进制值或指向包含解决方案的文件的链接。

  3. 如果您需要灵活性更好的性能并且已经知道最常见的解决方案类型的结构,请将它们存储在结构化表格和所有其他不可预测(未来)的解决方案,作为文件的二进制或链接。

  4. 如果您想保持简单,请使用第1点或第2点,因为3会给您的程序增加很多复杂性。

  5. 我希望这是正确的答案。我很好奇,如果有人有更好的建议!