0

我不确定如何为我有 14 个字段的表单构建数据库，每个字段中有 5 个可能的固定答案。运行时记录数通常在 30 - 200 条记录之间变化。然而，任何超过 100 条记录都是不常见的。可以得到偶尔的400条记录表。

通常会重复给定的条目组合，或者一系列记录将具有 -most- 共同的值，但是无法预测其中哪些可能会在记录插入之间发生变化。


我想避免大量重复，但尽可能保持良好的搜索效率。以下是我提出的模式。

架构 1： 1 个大型 14 字段表。对于小型数据集（<30）可能没问题，但是 200？在安卓上？


模式 2：一些规范化尝试：分解成 14 - 2 个带有外键的表。除了反复试验，不知道如何确定最佳数量。


模式 3：更详细但不难理解。

2张桌子。表 1 有 14 个字段，其中一个主键对应 14 个条目的给定组合。然后，表 2 使用外键根据与表 1 中的组合对应的 FK 记录记录。新组合在运行时出现时填充到表 1 中。

然后使用地图检查输入的记录是否对应于现有组合（也即时生成）。映射键只是字段中离散值的总和* - 有没有更好的方法来生成映射键？我想不出任何方法可以廉价地生成唯一密钥。然后我必须使用条件来区分具有相似总和的组合（if匹配组合是 13 秒吗？）

*每个字段中的每个状态都对应一个数值。

这个模式（3）是否可能在我规定的范围内很好地扩展，还是一个坏主意/矫枉过正/完全不合适？


有没有更好的方法来解决这个问题？

这是我第一次使用 RDBMS，非常感谢您提供的任何帮助。

编辑：还忘了提到这是一个更大的数据库的一部分，总共有 32 个字段，一些离散的和一些字符串，它们更容易预测或以其他方式处理的变化......

4

1 回答 1

1

我的直觉是，在您达到数千/数万条记录之前，您无需担心记录的数量会很大。实际上，您可以将具有 400 条记录的数据库视为 400 行文本文件。Android 可以轻松地将巨大的 xml/json 文件解析成 10 到 10 万行长。30 到 400 条记录对于 Android 来说应该是完全可以接受的。

如果我正确理解架构 3，您计划保留 5^14 个预配置状态，然后让主表中的条目引用选择可能性表中的给定状态配置？这听起来像是矫枉过正，因为 5^14 = 6103515625（当然这是最坏的情况）。如果存在大量重复状态，您将 [可能] 通过选择模式 3 显着减少内存使用量，但听起来这是不必要的早期优化。

一般来说，首先规划一个运行良好的系统，然后在必要时进行重构。不要试图从一开始就编写最详尽、最详尽的方案（数据库或编码，无所谓）。

使用最简单的模式可能是最有效的：模式 1。如果您到了记录计数成为问题的地步，请稍后重构为schema 3之类的内容。

或者，找到一种方法将这些位打包。5 个选项，14 个状态，2^3 包含 8 个状态，3 * 14 = 42 位。您可以在所有选择进入时生成一棵树，并以 3 位阶段遍历它。该树当然不适合内存，因此您需要将其分解并找到某种方法对其进行序列化..

于 2013-04-03T13:28:58.953 回答