32 个解决方案
#1
他说的很对，又不用一定要id来标识，他说的就是主键嘛
#2
为什么心情不好的时候，没有人来安慰我呢？
#3
干吗要用三个字段来识别呢?一个字段识能多好,真是多此一举!
#4
那个人说的是复合主键！！！可以使用这种方式来唯一确定数据库中记录。如果你的表与别的表关联比较多，那么使用符合主键可能会降低效率，可以考虑使用ID莱维已确定一条记录。但是ID不是简单的1，2，3...，一个好的ID首先要保证没有重复、其次要保证有一定的可读性，例如我使用的ID是这样定义的YYYYMMDDHHMMSS###$$$，前面的一看就知道什么意思，###表示的是ID的来源（我的ID的来源非常多），$$$表示的是顺序号（我的程序是多线程的）。
你可以考虑ID和符合主键同时定义的方案，这样一方面符合你的习惯，另外一方面你可以通过视图实现符合主键查询的功能！！！
你可以考虑ID和符合主键同时定义的方案，这样一方面符合你的习惯，另外一方面你可以通过视图实现符合主键查询的功能！！！
#5
但是在很多数据表中，多余的3个字段都冗余啊！
#6
是从表吧！用多个字段确定唯一记录要看情况。将表结构粘出来看看。
#7
这是要根据不同情况决定的，id是方便，但是对 需要查重的数据 或者 多地的数据 就不合适；如一个客户在多个分公司购买产品，你不可以用id记录一个客户成多个客户；如库存，需要 分公司编号＋产品编号 唯一决定，用id可能会一个地区的某产品有多记录
#8
你说的是主键吗？
主键：field1+field2+field3
请问，我知道主键的值要你找到这条记录，你的唯一ID可以做到吗？
当然你会说：只要你记住ID就行了。
事实上并不是这样的，一条记录是某一特定对象的相关信息描述，
你给这个对象分配一个ID（如0001），更加增加了记忆的负担，
你记住了0001（0001有什么用，谁知道他是什么），是不是还要将上面主键内容记住才能确认001是谁？
主键：field1+field2+field3
请问，我知道主键的值要你找到这条记录，你的唯一ID可以做到吗？
当然你会说：只要你记住ID就行了。
事实上并不是这样的，一条记录是某一特定对象的相关信息描述，
你给这个对象分配一个ID（如0001），更加增加了记忆的负担，
你记住了0001（0001有什么用，谁知道他是什么），是不是还要将上面主键内容记住才能确认001是谁？
#9
同意楼上，ID在一个表内是不会有问题的，如果有多个表，还是要考虑。
#10
多个字段唯一确定一条记录，也很常见，建立一个多字段主键。至于效率，再看吧
#11
现在是关联很多表啊。
就像有厂家，厂家下有系列，系列下有型材，现在我认为在型材表中厂家和系列的信息，我认为在厂家、系列表中应该有ID，当然是唯一表示一条记录的值。但是现在是在系列表中有厂家名称，在型材表中厂家名称、系列名称。需要关联5-6个表。
就像有厂家，厂家下有系列，系列下有型材，现在我认为在型材表中厂家和系列的信息，我认为在厂家、系列表中应该有ID，当然是唯一表示一条记录的值。但是现在是在系列表中有厂家名称，在型材表中厂家名称、系列名称。需要关联5-6个表。
#12
我们用的表中几乎都这样确定唯一，联合主键应用的地方太多了
#13
多个字段唯一确定一条记录，也很常见，建立一个多字段主键.我是看情况用的
#14
我支持用ID
#15
其实用不用id都无所谓的，如果你的表关联少，完全可以用自增id来给每条记录判断唯一性，不过最好用录入数据本身带有的唯一性特征做主键,id只是辅助作用。
#16
或许联合主键有它的好处！
#17
UP
#18
联合主键什么时候用？我举个简单例子楼主就明白：
有一表TABLE1，里面存放新闻记录，字段有TITLE，CONTENT，PHRASE等，该数据库要求在网上发布。很明显，新闻不要求重复，因此我们选定title+content为主键，这样我可以保证我的数据库里的新闻没有重复的，反之此时用id就无法达到要求
有一表TABLE1，里面存放新闻记录，字段有TITLE，CONTENT，PHRASE等，该数据库要求在网上发布。很明显，新闻不要求重复，因此我们选定title+content为主键，这样我可以保证我的数据库里的新闻没有重复的，反之此时用id就无法达到要求
#19
符合主键不是地狱，该使用的时候就该使用:)
#20
一般的表需要ID
但是有些表：比如几个表间的联系表，则不需要，用外键盘就可以了。
但是有些表：比如几个表间的联系表，则不需要，用外键盘就可以了。
#21
to lonaerd(罗纳尔多) :
但是我也可以用ID来唯一的表示一条记录啊，然后在存放新闻信息时判断有无重复内容啊。不过这样是麻烦了一点。
但是我也可以用ID来唯一的表示一条记录啊，然后在存放新闻信息时判断有无重复内容啊。不过这样是麻烦了一点。
#22
标记
#23
我现在的项目里也是这样的，甚至比他还多，用了5个属性共同做主键，这也是因具体需求的需要；按照传统的理论，可以用一个做主键同时也是其他表的外键，但是由于使用的频繁，会很大程度上影响系统的响应速度；我们也考虑到有在主键内实行多级编码的方式，这样也科学，但还是归结到速度上，由于使用的频率过高（每次操作甚至使用过N次），每次使用还必须对主键进行拆分，速度上还是达不到要求（可能我们的水平有限暂时没有好的、速度能够大幅度提的算法），所以放弃了。所以具体问题具体分析！
#24
这个玩艺被搞出来，肯定有它存在的道理
你现在觉得没用，只是你还不知道他的用处罢了
可能你以后会离不开它了呢
你现在觉得没用，只是你还不知道他的用处罢了
可能你以后会离不开它了呢
#25
呵呵，大家说的都对！
但是存在一个问题，毕竟有写表的记录即使不完全一样，但是它表示的是同样的东西。譬如说我画一个窗型，数据库中存着二进制，虽然数据会差一点，但是却表示的是同样的窗型。还有涉及到数据的导入导出。
能不能采用时间来唯一表示一条记录啊？
但是存在一个问题，毕竟有写表的记录即使不完全一样，但是它表示的是同样的东西。譬如说我画一个窗型，数据库中存着二进制，虽然数据会差一点，但是却表示的是同样的窗型。还有涉及到数据的导入导出。
能不能采用时间来唯一表示一条记录啊？
#26
r_james(james) ：
在主键内实行多级编码的方式，是不是就是你的主健的内容是多个意思组合起来？
就象YYYYMMDDHHMMSS###$$$呢？
我以前做的一个考勤系统，其中主健就是采用
时间+员工号+am/pm+/sb/xb
其中/sb/xb表示上下班登记
在主键内实行多级编码的方式，是不是就是你的主健的内容是多个意思组合起来？
就象YYYYMMDDHHMMSS###$$$呢？
我以前做的一个考勤系统，其中主健就是采用
时间+员工号+am/pm+/sb/xb
其中/sb/xb表示上下班登记
#27
都这么复杂啊。大家有没有听过ms的GUID啊，声称几个世纪都不会重复！
#28
呵，我也喜欢用YYYYMMDDHHMMSS+RANDOM的3-8位。若还不爽可把员工帐号007加在随机数前
我现在又更觉得用天数，这样更短了。
即从2000年开始算今天是第700天，前补一个0，即0700，才4位，就比YYYYMMDD省了4位了，别说你的系统能用到2030年。那就用5位吧，补两个0，可用300年的系统。
秒数也用小时＊3600+分种＊60+秒，也只有5位数，不过省这一位数就有点小题大作了
我现在又更觉得用天数，这样更短了。
即从2000年开始算今天是第700天，前补一个0，即0700，才4位，就比YYYYMMDD省了4位了，别说你的系统能用到2030年。那就用5位吧，补两个0，可用300年的系统。
秒数也用小时＊3600+分种＊60+秒，也只有5位数，不过省这一位数就有点小题大作了
#29
用时间的话，如果服务器的时间改了，有没有可能出现重复呢？
#30
字段需要按需要来设的，你觉得不需要，那就不设免得浪费资源
#31
今天下班时结贴！
#32
To xiaoyuer0851(小鱼儿0851):对！多级编码的是比较先进的处理方式（我认为）！不过我现在看到的有多级编码的项目中的多级编码使用的不多，即使使用了也不规范，这样就很难体现出它的优点！更重要的是开发环境中对多级编码并没有更大的支持，所以要想在一个项目中使用多级编码，设计人员和编码人员要做的工作太多，这可能也是多级编码没能大量实现的一个原因吧！
#1
他说的很对，又不用一定要id来标识，他说的就是主键嘛
#2
为什么心情不好的时候，没有人来安慰我呢？
#3
干吗要用三个字段来识别呢?一个字段识能多好,真是多此一举!
#4
那个人说的是复合主键！！！可以使用这种方式来唯一确定数据库中记录。如果你的表与别的表关联比较多，那么使用符合主键可能会降低效率，可以考虑使用ID莱维已确定一条记录。但是ID不是简单的1，2，3...，一个好的ID首先要保证没有重复、其次要保证有一定的可读性，例如我使用的ID是这样定义的YYYYMMDDHHMMSS###$$$，前面的一看就知道什么意思，###表示的是ID的来源（我的ID的来源非常多），$$$表示的是顺序号（我的程序是多线程的）。
你可以考虑ID和符合主键同时定义的方案，这样一方面符合你的习惯，另外一方面你可以通过视图实现符合主键查询的功能！！！
你可以考虑ID和符合主键同时定义的方案，这样一方面符合你的习惯，另外一方面你可以通过视图实现符合主键查询的功能！！！
#5
但是在很多数据表中，多余的3个字段都冗余啊！
#6
是从表吧！用多个字段确定唯一记录要看情况。将表结构粘出来看看。
#7
这是要根据不同情况决定的，id是方便，但是对 需要查重的数据 或者 多地的数据 就不合适；如一个客户在多个分公司购买产品，你不可以用id记录一个客户成多个客户；如库存，需要 分公司编号＋产品编号 唯一决定，用id可能会一个地区的某产品有多记录
#8
你说的是主键吗？
主键：field1+field2+field3
请问，我知道主键的值要你找到这条记录，你的唯一ID可以做到吗？
当然你会说：只要你记住ID就行了。
事实上并不是这样的，一条记录是某一特定对象的相关信息描述，
你给这个对象分配一个ID（如0001），更加增加了记忆的负担，
你记住了0001（0001有什么用，谁知道他是什么），是不是还要将上面主键内容记住才能确认001是谁？
主键：field1+field2+field3
请问，我知道主键的值要你找到这条记录，你的唯一ID可以做到吗？
当然你会说：只要你记住ID就行了。
事实上并不是这样的，一条记录是某一特定对象的相关信息描述，
你给这个对象分配一个ID（如0001），更加增加了记忆的负担，
你记住了0001（0001有什么用，谁知道他是什么），是不是还要将上面主键内容记住才能确认001是谁？
#9
同意楼上，ID在一个表内是不会有问题的，如果有多个表，还是要考虑。
#10
多个字段唯一确定一条记录，也很常见，建立一个多字段主键。至于效率，再看吧
#11
现在是关联很多表啊。
就像有厂家，厂家下有系列，系列下有型材，现在我认为在型材表中厂家和系列的信息，我认为在厂家、系列表中应该有ID，当然是唯一表示一条记录的值。但是现在是在系列表中有厂家名称，在型材表中厂家名称、系列名称。需要关联5-6个表。
就像有厂家，厂家下有系列，系列下有型材，现在我认为在型材表中厂家和系列的信息，我认为在厂家、系列表中应该有ID，当然是唯一表示一条记录的值。但是现在是在系列表中有厂家名称，在型材表中厂家名称、系列名称。需要关联5-6个表。
#12
我们用的表中几乎都这样确定唯一，联合主键应用的地方太多了
#13
多个字段唯一确定一条记录，也很常见，建立一个多字段主键.我是看情况用的
#14
我支持用ID
#15
其实用不用id都无所谓的，如果你的表关联少，完全可以用自增id来给每条记录判断唯一性，不过最好用录入数据本身带有的唯一性特征做主键,id只是辅助作用。
#16
或许联合主键有它的好处！
#17
UP
#18
联合主键什么时候用？我举个简单例子楼主就明白：
有一表TABLE1，里面存放新闻记录，字段有TITLE，CONTENT，PHRASE等，该数据库要求在网上发布。很明显，新闻不要求重复，因此我们选定title+content为主键，这样我可以保证我的数据库里的新闻没有重复的，反之此时用id就无法达到要求
有一表TABLE1，里面存放新闻记录，字段有TITLE，CONTENT，PHRASE等，该数据库要求在网上发布。很明显，新闻不要求重复，因此我们选定title+content为主键，这样我可以保证我的数据库里的新闻没有重复的，反之此时用id就无法达到要求
#19
符合主键不是地狱，该使用的时候就该使用:)
#20
一般的表需要ID
但是有些表：比如几个表间的联系表，则不需要，用外键盘就可以了。
但是有些表：比如几个表间的联系表，则不需要，用外键盘就可以了。
#21
to lonaerd(罗纳尔多) :
但是我也可以用ID来唯一的表示一条记录啊，然后在存放新闻信息时判断有无重复内容啊。不过这样是麻烦了一点。
但是我也可以用ID来唯一的表示一条记录啊，然后在存放新闻信息时判断有无重复内容啊。不过这样是麻烦了一点。
#22
标记
#23
我现在的项目里也是这样的，甚至比他还多，用了5个属性共同做主键，这也是因具体需求的需要；按照传统的理论，可以用一个做主键同时也是其他表的外键，但是由于使用的频繁，会很大程度上影响系统的响应速度；我们也考虑到有在主键内实行多级编码的方式，这样也科学，但还是归结到速度上，由于使用的频率过高（每次操作甚至使用过N次），每次使用还必须对主键进行拆分，速度上还是达不到要求（可能我们的水平有限暂时没有好的、速度能够大幅度提的算法），所以放弃了。所以具体问题具体分析！
#24
这个玩艺被搞出来，肯定有它存在的道理
你现在觉得没用，只是你还不知道他的用处罢了
可能你以后会离不开它了呢
你现在觉得没用，只是你还不知道他的用处罢了
可能你以后会离不开它了呢
#25
呵呵，大家说的都对！
但是存在一个问题，毕竟有写表的记录即使不完全一样，但是它表示的是同样的东西。譬如说我画一个窗型，数据库中存着二进制，虽然数据会差一点，但是却表示的是同样的窗型。还有涉及到数据的导入导出。
能不能采用时间来唯一表示一条记录啊？
但是存在一个问题，毕竟有写表的记录即使不完全一样，但是它表示的是同样的东西。譬如说我画一个窗型，数据库中存着二进制，虽然数据会差一点，但是却表示的是同样的窗型。还有涉及到数据的导入导出。
能不能采用时间来唯一表示一条记录啊？
#26
r_james(james) ：
在主键内实行多级编码的方式，是不是就是你的主健的内容是多个意思组合起来？
就象YYYYMMDDHHMMSS###$$$呢？
我以前做的一个考勤系统，其中主健就是采用
时间+员工号+am/pm+/sb/xb
其中/sb/xb表示上下班登记
在主键内实行多级编码的方式，是不是就是你的主健的内容是多个意思组合起来？
就象YYYYMMDDHHMMSS###$$$呢？
我以前做的一个考勤系统，其中主健就是采用
时间+员工号+am/pm+/sb/xb
其中/sb/xb表示上下班登记
#27
都这么复杂啊。大家有没有听过ms的GUID啊，声称几个世纪都不会重复！
#28
呵，我也喜欢用YYYYMMDDHHMMSS+RANDOM的3-8位。若还不爽可把员工帐号007加在随机数前
我现在又更觉得用天数，这样更短了。
即从2000年开始算今天是第700天，前补一个0，即0700，才4位，就比YYYYMMDD省了4位了，别说你的系统能用到2030年。那就用5位吧，补两个0，可用300年的系统。
秒数也用小时＊3600+分种＊60+秒，也只有5位数，不过省这一位数就有点小题大作了
我现在又更觉得用天数，这样更短了。
即从2000年开始算今天是第700天，前补一个0，即0700，才4位，就比YYYYMMDD省了4位了，别说你的系统能用到2030年。那就用5位吧，补两个0，可用300年的系统。
秒数也用小时＊3600+分种＊60+秒，也只有5位数，不过省这一位数就有点小题大作了
#29
用时间的话，如果服务器的时间改了，有没有可能出现重复呢？
#30
字段需要按需要来设的，你觉得不需要，那就不设免得浪费资源
#31
今天下班时结贴！
#32
To xiaoyuer0851(小鱼儿0851):对！多级编码的是比较先进的处理方式（我认为）！不过我现在看到的有多级编码的项目中的多级编码使用的不多，即使使用了也不规范，这样就很难体现出它的优点！更重要的是开发环境中对多级编码并没有更大的支持，所以要想在一个项目中使用多级编码，设计人员和编码人员要做的工作太多，这可能也是多级编码没能大量实现的一个原因吧！