0

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

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

一般来说，让表格足够宽以处理所有案例并为每个条目保留一些（但不同的）部分未使用会更好，还是应该为每个案例制作一个特殊的表格？

还是有其他更好的技术？

4

3 回答 3

1

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

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)
    )
于 2013-04-03T20:17:42.433 回答
0

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

为了简短起见：

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

  2. 如果您需要灵活性，例如存储您还不知道的结果结构的未来游戏的结果，而不考虑性能，则存储二进制值或包含解决方案的文件的链接。

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

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

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

于 2015-01-05T23:20:30.710 回答
0

你的问题很笼统，所以简短的回答是：这取决于！较长的一个是：如果您只有几款差异不大的游戏，“宽”牌桌是一个简单的解决方案。在某些情况下，我会寻求该解决方案，但通常不会。

我的建议是：问问自己，所有选择/选择的共同点。该数据应该进入一个通用表。特定游戏的特殊数据应放在每个游戏的单独相关表中。

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

于 2013-04-03T20:34:43.860 回答