态势相关数据的数据库表设计

Question

假设您有一个表，其中将包含非常依赖于情况的数据。

一个例子是玩家选择获胜的游戏集合。这个选择应该被存储，但是游戏是不同的，所以一个游戏中的选择并不真正适合另一个游戏中的选择。

总而言之，是让表足够宽，以处理所有情况，并为每个条目保留一些(但不同的)部分，还是应该为每个情况创建一个特殊的表？

或者有没有其他更好的技术？

Answer 1

我不确定，如果我理解正确的话，似乎你想要一个m:n关系，这将需要3个表：

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)
    )

Answer 2

你的问题太笼统了，所以简单的回答是:看情况！较长的一个是:如果你只有几个游戏，没有太大的区别，那么“宽泛”的桌子是一个简单的解决方案。在某些情况下，我会选择这种解决方案，但通常不会。

我的建议是:问问自己，所有选择/选择的共同点是什么。这些数据应该放到一个通用表中。特定游戏的数据应该放到每个游戏单独的相关表中。

我不知道你的程序员背景如何。但如果你熟悉面向对象编程，只需谷歌搜索如何将类层次结构映射到SQL数据库的策略。

Answer 3

@Lars:我刚刚重读了你的问题。

长话短说：

1. 如果你需要最大的性能，即使你必须创建许多新的表，也要保持它的完全结构化。
2. 如果你需要灵活性，例如存储你还不知道的结果结构的未来游戏的结果，而不考虑性能，存储二进制值或指向包含解决方案的文件的链接。
3. 如果你需要灵活性和更好的性能，并且已经知道最常见的解决方案类型的结构，请将这些存储在结构化的表和所有其他不可预测的(未来)解决方案中，作为二进制或文件链接。
4. 如果你想保持简单，使用第1点或第2点，因为第3点会增加程序的复杂性。

我希望这是正确的答案。我很好奇，如果有人有更好的建议！