1、表名称以单数命名。与单数对应的是复数，如product/proeucts。复数存在的唯一理由是表里存放的数据有很多条所以用复数，然而没有几个表只存放一条数据的，当全体表都齐齐加个“s”时，显然多余。2、不要加前缀、后缀。有人习惯用加t_表示“表”，加v_表示视图，加proc_表示存储过程，意图是看到名称就知道是什么类型的数据库对象。但是各种工具（比如企业管理器）都是分类显示数据库对象的，当在列表中齐齐看到t_开头的表名时，一样是多余。这样的命名出现在代码中倒多少有点用处，能直接识别出它是表还是视图，但好处仅限于此，并且和后面的规则冲突，所以不赞成。3、所有表都设主键“id”，并且是int型、自增的。
a) 主键和外键用来维系数据的完整性，不应当有业务上的含义，所以纯数字的自增型很合适。不赞成自己生成一个id值然后写进去，因为当考虑到并发的问题时，实现起来很麻烦。更不赞成用比如单据编号做主键，尽管业务上它是唯一的，但前端代码写起来复杂，比如订单号可能也需要修改（比如曾经做个系统，WT001表示普通单据，WTA001表示优先度高的单据并且是可以切换的），这时就首先修改SQL SERVER的SET，然后改从表们里的外键，然后再改主表的订单号，然后再恢复SET，很麻烦。
然而当数据库分布存储时，使用自增型就有点小麻烦，对于这个我有一些解决方案，只是还没完全顺畅，暂时不提。
b) 主键名称统一使用“id”。不赞成使用productId、userId等名称，因为表名product、user已经表明id的来历了，表内的字段无需再写一遍product、user，尤其一串productId、productName、productType一溜看下来，太累赘了。但是当多表关联或者代码上其他方面的需要，应当灵活使用别名，比如
SELECT product.name AS productName。
这样rs("productName")、rs("catalogName")时增强代码的可阅读性 c) 不赞成使用复合主键，因为前端代码写起来不舒服。比如在页面上传递链接，user.aspx?tel=12345678&cityName=test显然没有user.aspx?user_id=999来的舒服；还比如当填充下拉菜单等控件时，写itemValue时需要tel+cityName，取值时还需要把itemValue分解成tel和cityName；还比如win32的很多控件比如下拉菜单、ListBox等，value干脆就只能写数值型。4、所有外键都命名为“tablename_id”。以id、tablename_id命名住外键，最大的好处是表之间的关系非常清晰，比如销售表、销售明细表、产品表、产品分类表在一起关联查询，
闭着眼都能写出来
SELECT *
FROM sale, saleItem, product, catalog
WHERE sale.id=saleItem.sale_id
AND product.id=saleItem.product_id
AND catalog.id=product.catalog_id
顺便提到，不要以别名来命名表，那样可读性很差，比如
SELECT *
FROM sale AS s, saleItem i, product AS p, catalog AS c
WHERE se.id=i.sale_id
AND p.id=i.product_id
AND c.id=p.catalog_id
读代码的人肯定要反复对照表名与别名的关系才能理清楚5 字段抽象
5.1)数据库设计中，我总结出大部分数据都有一个“名字”，比如书的书名、权限的名称、BBS的标题，这样的字段统一命名为“name”。对于单据，比如采购单、订单，都会有一个编号，可统一命名为“OrderNo”，（这个随个人习惯，只建议用一样的名字），当然命名为name也说的过去
5.2) 数据生成时间也是很多表共同的需要，统一命名为time，意寓时间标记，并且默认值为getdate()。对用户表来说，它是用户注册时间，对于订单表，它是订单生成时间，对于日志表，它是日志生成时间，等等
5.3)对于不能物理删除记录的表（通常是有主从关系的主表），应当有个字段标记该记录是否已被逻辑删除，我的习惯是加个enabled tinyint default 1的字段。
5.4)有些数据是需要指定显示顺序的，我的经验是设置一个sequence int default 100的字段。所有记录默认都是100（这个值就完全随意了），当需要往前排，就在操作界面写个较小的数字如50进去，检索时写SELECT * FROM table ORDER BY sequence, id DESC。另外建议UI用文本框允许用户直接编辑这个数字就可（当然如果可拖曳的话就更好了），反对其他的方式如勾选两条记录然后点“交换”、或者列表里每行数据都搞个上下箭头点一下就移动一个位置，因为操作起来很繁。
总结起来，常用的表结构就是：
CREATE TABLE tablename
(
id int IDENTITY (1, 1) NOT NULL ,
enabled tinyint DEFAULT 1 NOT NULL ,
time smalldatetime DEFAULT getdate() NOT NULL ,
sequence smallint DEFAULT 100 NOT NULL ,
name nvarchar (99) NOT NULL
)
用固定的名字来概括含义相似的数据，也算是“抽象”吧
==============================================
一直都想写写，一没空二懒，今天加班无事就随便写点，先胡乱写这么多，试探下市场反应，要大家觉得有点用我再接着献丑
a) 主键和外键用来维系数据的完整性，不应当有业务上的含义，所以纯数字的自增型很合适。不赞成自己生成一个id值然后写进去，因为当考虑到并发的问题时，实现起来很麻烦。更不赞成用比如单据编号做主键，尽管业务上它是唯一的，但前端代码写起来复杂，比如订单号可能也需要修改（比如曾经做个系统，WT001表示普通单据，WTA001表示优先度高的单据并且是可以切换的），这时就首先修改SQL SERVER的SET，然后改从表们里的外键，然后再改主表的订单号，然后再恢复SET，很麻烦。
然而当数据库分布存储时，使用自增型就有点小麻烦，对于这个我有一些解决方案，只是还没完全顺畅，暂时不提。
b) 主键名称统一使用“id”。不赞成使用productId、userId等名称，因为表名product、user已经表明id的来历了，表内的字段无需再写一遍product、user，尤其一串productId、productName、productType一溜看下来，太累赘了。但是当多表关联或者代码上其他方面的需要，应当灵活使用别名，比如
SELECT product.name AS productName。
这样rs("productName")、rs("catalogName")时增强代码的可阅读性 c) 不赞成使用复合主键，因为前端代码写起来不舒服。比如在页面上传递链接，user.aspx?tel=12345678&cityName=test显然没有user.aspx?user_id=999来的舒服；还比如当填充下拉菜单等控件时，写itemValue时需要tel+cityName，取值时还需要把itemValue分解成tel和cityName；还比如win32的很多控件比如下拉菜单、ListBox等，value干脆就只能写数值型。4、所有外键都命名为“tablename_id”。以id、tablename_id命名住外键，最大的好处是表之间的关系非常清晰，比如销售表、销售明细表、产品表、产品分类表在一起关联查询，
闭着眼都能写出来
SELECT *
FROM sale, saleItem, product, catalog
WHERE sale.id=saleItem.sale_id
AND product.id=saleItem.product_id
AND catalog.id=product.catalog_id
顺便提到，不要以别名来命名表，那样可读性很差，比如
SELECT *
FROM sale AS s, saleItem i, product AS p, catalog AS c
WHERE se.id=i.sale_id
AND p.id=i.product_id
AND c.id=p.catalog_id
读代码的人肯定要反复对照表名与别名的关系才能理清楚5 字段抽象
5.1)数据库设计中，我总结出大部分数据都有一个“名字”，比如书的书名、权限的名称、BBS的标题，这样的字段统一命名为“name”。对于单据，比如采购单、订单，都会有一个编号，可统一命名为“OrderNo”，（这个随个人习惯，只建议用一样的名字），当然命名为name也说的过去
5.2) 数据生成时间也是很多表共同的需要，统一命名为time，意寓时间标记，并且默认值为getdate()。对用户表来说，它是用户注册时间，对于订单表，它是订单生成时间，对于日志表，它是日志生成时间，等等
5.3)对于不能物理删除记录的表（通常是有主从关系的主表），应当有个字段标记该记录是否已被逻辑删除，我的习惯是加个enabled tinyint default 1的字段。
5.4)有些数据是需要指定显示顺序的，我的经验是设置一个sequence int default 100的字段。所有记录默认都是100（这个值就完全随意了），当需要往前排，就在操作界面写个较小的数字如50进去，检索时写SELECT * FROM table ORDER BY sequence, id DESC。另外建议UI用文本框允许用户直接编辑这个数字就可（当然如果可拖曳的话就更好了），反对其他的方式如勾选两条记录然后点“交换”、或者列表里每行数据都搞个上下箭头点一下就移动一个位置，因为操作起来很繁。
总结起来，常用的表结构就是：
CREATE TABLE tablename
(
id int IDENTITY (1, 1) NOT NULL ,
enabled tinyint DEFAULT 1 NOT NULL ,
time smalldatetime DEFAULT getdate() NOT NULL ,
sequence smallint DEFAULT 100 NOT NULL ,
name nvarchar (99) NOT NULL
)
用固定的名字来概括含义相似的数据，也算是“抽象”吧
==============================================
一直都想写写，一没空二懒，今天加班无事就随便写点，先胡乱写这么多，试探下市场反应，要大家觉得有点用我再接着献丑
---------------------------------------------
关于这一点，有兴趣的朋友可以讨论一下，楼主的理由不足以说服我。
息表messages的意義了。
3>替代键与自然键的争论由来已久，且尚未结束。
a>你说的实际是1NF的问题。人工编码确实存在并发问题，但效率也没想象中那么低，代码也不麻烦。
b>这一点你完全错了，列名的在整个数据库内都应该是统一的，即在主表里叫ProductId，在关联表也应该叫ProductId。因为从应用上来看，应该将数据库看作一系互相关联并组织有序的类型（列）的集合，而不单单是一系列表的集合。另外，很少有人会将表名直接作为别名的
c>莫名其妙
4>同3.b。另外一般要用join替代where条件中的一系列表
5>
1>莫名奇妙
2>有时会需要这么个字段
3>确实有物理删除、逻辑删除的说法
4>莫名奇妙
楼主不要见外～1、表名称以单数命名。
--比较赞同 :) 2、不要加前缀、后缀。有人习惯用加t_表示“表”，加v_表示视图，加proc_表示存储过程，意图是看到名称就知道是什么类型的数据库对象。但是各种工具（比如企业管理器）都是分类显示数据库对象的，当在列表中齐齐看到t_开头的表名时，一样是多余。这样的命名出现在代码中倒多少有点用处，能直接识别出它是表还是视图，但好处仅限于此，并且和后面的规则冲突，所以不赞成。
-- 这个,个人习惯,
-- 在你的脚本或者应用程序中无法区分是表还是视图的情况下,加入前缀或者后缀将提高阅读性,
-- 而实际上,做为大部分的DBA和Programer来说,数据的管理多数是和脚本打交道,所以,个人觉得还是有必要的.3、所有表都设主键“id”，并且是int型、自增的。
-- ID自增列设置有待商榷,
-- 有可能会产生冗余列,不一定非要每个表都要建立ID列,只要有主键列的就可以了,4、所有外键都命名为“tablename_id”。以id、tablename_id命名住外键，最大的好处是表之间的关系非常清晰，比如销售表、销售明细表、产品表、产品分类表在一起关联查询，
--这个和3差不多～ :)
5 字段抽象
用固定的名字来概括含义相似的数据，也算是“抽象”吧
--这个和2差不多,
--相似命名可能导致代码阅读性降低,