2 回答
TA贡献1874条经验 获得超12个赞
一般来说,自动递增(或identity
或serial
)主键是可行的方法。您通常不希望应用程序担心诸如值是否已被使用之类的事情。
如果您的应用程序是多线程的(即同时有多个用户),那么数据库将处理任何冲突。那是相当方便的。
我很喜欢数据库创建的代理键。在按主键对行进行聚类(排序)的数据库中,使用自动递增的值会更有效。数据库可以解决这个问题。
在某些情况下,您需要自然键。当然,这也是允许的。但是,如果您要为表发明主键,请让数据库来完成这项工作。
TA贡献1829条经验 获得超6个赞
在为 CRUD 操作定义数据库支持结构时,您需要问自己:
我的主键高度可预测重要吗?
我的意思是,如果我将用户启动到诸如“whatever.com/something/edit/1”之类的屏幕
除了明显的安全性之外,用户可以操纵 url 并将 2 或 3 或 4 注入路径中是否有助于或损害业务流程?
如果没关系,那么绝对将其设置为数据库端的自动增量 int 并将该区域的责任转移给数据库来处理。您现在不必再高度关注处理密钥生成。
如果确实重要,则将主键设置为唯一标识符。在代码中添加新记录集时,您将生成一个新的 GUID 并将其设置为主键 (Guid.NewGuid())。这将防止用户以不受控制的方式遍历您的数据,因为随机猜测 GUID 会给他们带来问题。EX:新路径:“whatever.com/something/edit/0f8fad5b-d9cb-469f-a165-70867728950e”
并不是说不可能偶然发现一些东西,但使用您的应用程序的普通人不会那么倾向于去探索 url 操作,因为他们会浪费 99.99% 的时间在无效的帖子上尝试猜测已注册的有效 GUID在你的数据库中。
作为补充评论,如果您决定将主键保留为 int 并且不使用自动增量,那么您只是在为自己做大量不必要的工作,而我个人从未见过逻辑的任何真正投资回报您应该检查占位符是否已被使用。那并考虑追踪历史吗?如果您决定从表中删除记录然后重新使用它们,那么您将陷入痛苦的世界。除了你正在做的事情之外,这是你必须处理的另一组问题。
- 2 回答
- 0 关注
- 110 浏览
添加回答
举报