与主键混淆
我是设计数据库的新手。也许这是一个愚蠢的问题,所以请原谅我。所以问题是我正在为用户设计数据库。用户填写注册信息后,他将获得唯一的收据号码。所以我的问题是因为收据号。是唯一的,我可以将其用作用户表中的主键,还是应该坚持使用将 userID 分配给表中的每一行并使用 userID 作为主键的标准方法?
I am new to designing database. Maybe its a stupid question so please pardon me for that. So the thing is I am designing the database for users. After user fills registration information he gets the unique receipt number. So my question is since receipt no. is unique can I use it as a primary key in Users table or should I stick with standard method of assigning userID to each row in table and use userID as primary key?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
一张表可以有多个键。如果收据编号旨在是唯一的,并且您希望 DBMS 强制执行对该属性的键依赖性作为数据完整性约束,那么您应该将其设为键(通过 PRIMARY KEY 或 UNIQUE 约束或 DBMS 的任何机制实现唯一性)提供)。
将任何一个键指定为“主”键并不是特别重要,或者至少它的重要性取决于您的意愿。真正重要的是您选择的全套密钥。任何密钥的要求是唯一性和不可约性。选择密钥的合理标准还包括:熟悉性、简单性和稳定性
A table can have more than one key. If the receipt number is intended to be unique and you want the DBMS to enforce key dependencies on that attribute as a data integrity constraint then yes you should make it a key (with uniqueness implemented by a PRIMARY KEY or UNIQUE constraint or whatever mechanisms your DBMS provides).
Designating any one key to be a "primary" one isn't especially important - or at least it is only as important as you want it to be. What really matters is the full set of key(s) you choose. The requirements for any key are Uniqueness and Irreducibility. Sensible criteria for choosing a key are also: Familiarity, Simplicity and Stability
如果您的收据编号仅包含整数,那么您可以将收据编号字段设置为自动递增编号,
if your receipt number contains only integer number then, may be you can make your receipt-no field as auto-increment number,
如果您的收据没有。足够复杂 - 使用数字和字符构建,或长度为 20 位 - 更好使用代理 UserId
如果收据 No 可以是简单整数并且可以从数据库生成 - 更好使用 UserId 并将其值分配给 ReceiptNo
如果 ReceiptNo 是简单整数并且它标识用户并且唯一的用户 - 将其用作 PKey。
If your receipt no. is complicated enough - built using numbers and characters, or 20 digits in length - better use the surrogate UserId
If receipt No can be simple integer and may be generated from DB - better use UserId and assign its value to ReceiptNo
If ReceiptNo is simple integer and its identifies the user AND the only user - use it as PKey.