Core data 用户自定义表中已知行的最佳方法？

我以编写最终用户可以自定义的数据库应用程序为生

通常，这意味着——暂时把数据库放在一边——我的一些概念实体类型有一个无限的宇宙或域

以名称类型为例。你可以有名字，姓氏，已婚的名字，法定的名字，称呼的名字，等等。我不会给这个宇宙设定一个上限

但我确实需要找到并使用某些知名的名称类型。让我们说一下显示名和排序名，只是为了简单起见

我还希望能够查询所有名称类型（即整个宇宙），并返回我的已知名称类型

在数据库中实现这一点有几种策略：

有一个带有id列和代码列的名称\类型表。小于一定数量的ID值“保留”供系统使用；高于此值的ID值被视为用户类型

在id/代码对中添加一列，该列表示布尔或int类型，指示这是哪种类型的行（例如，用户定义或系统）。同样的事情，真的；只需使用另一列显式地分解信息，而不是在id中重载信息

有两个可能有命名约定的表：name\u type和name\u type\u system。据了解或强制执行，名称\类型\系统禁止用户使用；name\u type是他们的域。查询在这些表之间进行联合，而应用程序只是“知道”永远不会更新系统表

人们使用什么策略？有战争故事吗？有什么特别的理由选择一个而不是另一个吗？我没有看到的巨大陷阱

最佳，

---

莱尔德（Laird）在你的三个想法中，第一个经常被称为幻数，这是一件坏事，因为任何不“知道”它的代码都可能出错。此外，随着时间的推移，您最终会意识到，“哎呀，我需要将最小值推高，需要对10000个现有行重新排序。”令人头痛，令人头痛

在那之后，其他两个中的任何一个都可以工作。但是第三个允许您使用DB服务器拒绝对最终用户使用的帐户的插入/更新/删除访问，从而简化了代码

---

在选项2和选项3之间做出决定的方法是问，它们真的是两个独立的东西吗？如果是，它们将倾向于具有不同的安全性，对它们执行不同的操作，一个通过升级进行修改，另一个不进行修改，等等。如果它们真的是两个不同的东西，它们将放在两个表中。如果它们是同一事物的两种口味，并且几乎总是得到相同的对待，那么它们将放在一个带有“type”标志的表中，选项2。

谢谢；回答得很好。在我的例子中，选择2是一条路要走，遵循这个逻辑。