You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

原因有很多，其中一种就是缺少主键。

xoyozo 3 天前

EF 更新数据库时减少一次查询

通常，我们在更新一条数据库记录时，EF 先取出这一条记录：

var log = DbContext.MyTable.Find(id);

然后赋值字段并保存：

log.Result = "OK";
DbContext.SaveChanges();

这样就会产生两次数据库查询。

我们尝试用 Attach 方法。

先创建一个仅包含主键的对象：

var log  = new MyTable { Id = id };

将对象附加到上下文：

DbContext.MyTable.Attach(log);

然后更新需要更新的字段：

log.Result = "OK";
DbContext.SaveChanges();

这样，能在保留其它字段值的前提下，减少一次数据库查询。

但是需要注意的是：

当某非 null 字段需要恢复默认值时，EF 会忽略这个更改。（可能会因 EF 版本等原因有不同的结论）

举个例子：

某记录有个 int 型字段 a，在数据库中这个记录的 a 的值为 1，但 C# 中 int 型的默认值为 0，所以当 Attach 附加这个对象后，如果重新设置 log.a 为 0，那么保存后 a 的值仍为 1。

还有一种写法，利用 ExecuteUpdate 方法：

var affectedRows = DbContext.MyTable
  .Where(c => c.Id == id)
  .ExecuteUpdate(setters => setters
    .SetProperty(c => c.Result, "OK")
  );

返回匹配的行数。

这种写法不会遇到“恢复为默认值不生效”的问题，推荐使用。

xoyozo 8 个月前

731

记一次 Discuz! 论坛升级（阿里云）

本文记录于 2021 年 9 月。

	升级前	期望（最新正式版）	最终选择
操作系统	CentOS 6.5	Alibaba Cloud Linux 3	Alibaba Cloud Linux 3
管理面板	lnmp	宝塔面板 Linux 版 7.7.0	宝塔面板 Linux 版 7.7.0
Web 服务	nginx 1.6	nginx 1.21	nginx 1.21
脚本语言	PHP 5.6	PHP 8.0	PHP 7.4
数据库	RDS MySQL 5.6	RDS MySQL 8.0	RDS MySQL 5.6
论坛程序	Discuz! X3.2 GBK	Discuz! X3.5 UTF-8（即将发布）	Discuz! X3.4 GBK

版本选择原因：

Alibaba Cloud Linux 完全兼容 CentOS，相比于 CentOS 较短的生命周期，Alibaba Cloud Linux 3 将于 2029 年 4 月 30 日结束生命周期。
Discuz! X3.4 不支持 PHP 8.0，安装时即报错，打开页面时一片空白。
MySQL 8.0 和阿里云 RDS 的 MySQL 7.5 不支持 MyISAM，而数据表 pre_common_member_grouppm 和 pre_forum_post 使用联合主键且自动递增字段不是第一主键，使用 InnoDB 引擎创建表时会报“1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key”错误，而擅自更改主键次序会影响业务逻辑。因此，在必须选择阿里云 RDS 的情况下，只能选择 MySQL 5.6。（2023年8月注：查看如何更改为 InnoDB）
Discuz! X3.5 正式版尚未发布（截止发稿），即便发布，插件也可能不能得到及时更新。相比之下，X3.4 首个版本发布距今已有 4 年，相关第三方插件已经非常成熟。

完整升级步骤：

备份原网站程序、RDS 数据库；
购买新的 ECS、RDS，挂载磁盘，安装云监控；
迁移（或还原）数据库到新的 RDS；
安装宝塔面板并配置；
安装 nginx 及 PHP；
创建网站、配置 SSL、伪静态、防盗链、可写目录禁执行等（.conf）；
配置 hosts；
上传原网站程序到新的站点目录下；
按 Discuz! X 升级文档升级 X3.2 至 X3.4；详情见下文 ↓；
配置 OSS、Redis、更新缓存等；
测试论坛基本功能是否正常；检查附件是否正常显示；全面检查控制台配置；
逐个开启插件并检查兼容性；
按二开备忘录逐个按需进行二开；
逐个修改调用论坛接口的项目及直接调用论坛数据库的项目；
调试 MAGAPP 接口；
尝试强制 https 访问；
将以上所有修改后的程序保留备份；发布升级公告并关闭论坛；重复以上步骤；修改域名解析；开启论坛；
配置 IP 封禁、定时器、日志、自动备份、配置其它 ECS 的 hosts 等；
查看搜索引擎中收录的地址，是否有无法访问的情况；
尝试将历史遗留的本地附件全部转移到 OSS；
参这篇文章，可能有其它需要配置的地方。

Discuz! X 升级步骤及注意点：

升级前务必先修改 ./config/ 目录下的数据库/缓存连接信息，以防出现新站连接老库的情况；
按官方文档进行升级；
【问题】运行到 ./install/update.php?step=data&op=notification 时白屏。
【排查】尝试切换到 PHP 5.6 后成功（但该版本过于陈旧不能使用）；尝试升级 CPU 和内存 PHP 7.4 上升级仍不成功。
【原因】DB::result_first() 方法不对 SQL 语句追加“limit 1”，而是 SELECT 所有记录后在 PHP 端取第一条数据；
【解决】打开文件 update.php，查找 elseif($_GET['op'] == 'notification')，该节点的功能是在表 home_notification 中查找 category <= 0 的数据并修复它，如果数据库中所有 category 都大于 0，直接注释其内部 if 代码段继续升级即可（或改为 if(false && ...)）。
【问题】发布主题遇到错误：(1062) Duplicate entry '*' for key 'pid'
【原因】forum_post 中的 pid 不是自动增长的，而是由表 forum_post_tableid 中自动增长的 pid 生成的。如果生成的 pid 值已在 forum_post 表中存在，则会出现此错误。
【解决】迁移数据库时应关闭论坛，以防止 forum_post 表有新数据插入。
【问题】打开帖子页面 ./thread-***-1-1.html 显示 404 Not Found，而 ./forum.php?mod=viewthread&tid=*** 可以正常打开
【原因】未配置伪静态（可在宝塔面板中选择）
【问题】打开 UCenter 时报错：UCenter info: MySQL Query Error SQL:SELECT value FROM [Table]vars WHERE name='noteexists'
【解决】打开文件 ./uc_server/data/config.inc.php 配置数据库连接
【问题】打开登录 UCenter 后一片空白
【解决】将目录 ./uc_server/data/ 设为可写
需要将原来安装的插件文件移回 ./source/plugin/ 目录，并设置可写；
界面-表情管理，界面-编辑器设置-Discuz!代码

后续 Discuz! X3.4 R 小版本升级注意事项：

确认插件是否支持新版本（如短信通）
先创建一个新网站测试二开代码
保留 /config/、/data/、/uc_client/data/、/uc_server/data/、/source/plugin/，其它移入 old
上传文件
移回其它需要的文件，如：
-- 勋章/loading/logo/nv 等：/static/image/common/
-- 表情：/static/image/smiley/
-- 水印：/static/image/common/watermark.*
-- 风格：/template/default/style/t2/nv.png 等
-- 默认头像：/uc_server/images/noavatar_***.gif
-- 根目录 favicon.ico 等
-- 及其它非 DZ 文件
再次检查可写目录的写入权限和禁止运行 PHP 效果。

xoyozo 4 年前

6,517

there can be only one auto column and it must be defined as a key

1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

在 MyISAM 转 InnoDB 时出现。

原因：这个表有联合主键，且自增的字段不是第一个主键。

解决方法一，取消自增字段的自动递增，改为在程序中实现；

解决方法二，单独给自增字段单独添加一个索引。

以 Disucz! X3.4 为例，方法一改程序代码显然困难比较大，所以选择方法二。

表 pre_forum_post 中，tid 为第1主键，position 为第2主键且自增。

tid 表示主题，position 表示该帖在该主题中的位置（类似于楼层的概念）。

所以在原来 MyISAM 中可以方便地实现 position 在各自的主题下自增。

给 position 单独添加索引后可以将引擎改为 InnoDB，但是 position 在全表范围内自增了。

也就是说，如果发布一个新主题，那么这个主题帖的 position 就不是1，而是整个数据库中最大的 position 再加 1。

虽然不影响页面中帖子的排序和楼层号显示，但不知道会不会有其它问题，所以最好把它改过来。

给表 pre_forum_post 添加一个触发器，在插入前（BEFORE INSERT）

BEGIN
    DECLARE max_position INT;
    
    SELECT MAX(position) INTO max_position FROM pre_forum_post WHERE tid = NEW.tid;
    
    IF max_position IS NULL THEN
        SET max_position = 0;
    END IF;
    
    SET NEW.position = max_position + 1;
END

在上面触发器的定义中，NEW 指即将要插件的一条记录，在新插入的帖子所在主题中寻找最大的 position 赋值给一个 INT 变量，如果找不到就赋值 0，然后 +1 赋值给新的 position。

这样就实现了与原来相同的效果。

用同样的方法给表 pre_common_member_grouppm 添加触发器。

如果帖子有分表，给每个分表添加触发器，下次有新的分表也要记得添加。

xoyozo 4 年前

3,154

利用中文分词打造数据库全文检索

传统的 LIKE 模糊查询（前置百分号）无法利用索引，特别是多个关键词 OR，或在多个字段中 LIKE，更是效率低下。本文研究对文章进行分词以提高检索的准确度和查询效率。

根据自己的编程语言选择一款合适的中文分词组件，我在 ASP.NET 平台下选择了 jieba.NET。

设想的步骤：

分别对文章标题、标签、正文进行分词，保存到一张分词表上。该表把“文章 ID”和“词语”设为联合主键，用 3 个字段记录该词语分别在标题、标签、正文中出现的次数，另外还可以按需要添加文章分类 ID、文章创建时间等字段。
当用户输入关键词进行检索时，先将关键词分词，在分词表中用 in 语法查询到所有相关的记录；
使用 group by 语法对查询结果按文章 ID 分组；
关键在排序上，理想的排序是：
a. 先按搜索关键词中不同词语的出现量排序，即：若搜索关键词分词后是 3 个词语，那么全部包含这 3 个词的文章优先，只匹配其中 2 个词语的其次；
b. 再按搜索关键词在文中累计出现的次数排序（考虑权重），即：我们先假定标题和标签的分词权重为 5（意思是一个分词在标题中出现 1 次相当于在正文中出现 5 次），那么累加每个分词在标题、标签、正文的权重次数，得分高的优先；
c. 再进一步考虑文章的发布时间，即将文章的发布时间距离最早一篇文章的发布时间（或一个较早的固定日期）相隔的天数，乘以一个系数加入到权重中，这个系数按不同文章分类（场景）不同，比如新闻类的大一点，情感类的小一点）。乘以系数时一篇文章只加权一次，不要加权到每个分词。
d. 根据需求还可以加入文章热度（阅读数）的权重。

根据上述逻辑对一个有 18 万篇文章的内容管理系统进行改造，循环所有文章进行分词统计，得到一张包含 5 千万条记录的分词表（系统中部分文章只有标题、标签和外链，没有正文，否则更多）。

由于查询中包含 in、group by、count、sum、运算等，再若分类是无级限的，即文章分类 ID 也是 in 查询，然后分页，即使创建索引，效率也只能呵呵了。

简化：

不对正文进行分词；

不按权重进行排序；

那么分词表的记录数降到 250 万条，同样用 in 查询分词，先按搜索关键词中不同词语的出现量排序，再按发布时间排序，分页后获得一页的文章 ID 集合，再去文章表中 in 获取详细信息（注意保持一页中的排序）。

添加相关索引后，查询一个包含 3 个分词的关键词仅需十几毫秒。因为 in 的内容比较离散，所以索引的利用率比较高。

xoyozo 6 年前

5,637

关于 MySQL 数据库索引

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。

以一张包含 2000 万条记录的表做实验：

CREATE TABLE `dt_read`  (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `time` datetime(0) NOT NULL,
  `a_id` int(11) NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
);

这张表是用于记录文章点击量的，

`id` 为主键，int(11) 自增；

`time` 为非空 datetime，表示文章打开时间，测试数据是从 2017-03-11 至 2018-04-28；

`a_id` 为非空 int(11)，表示文章 ID，在此表中不唯一，测试数据是从 1 至 260218。

体验“全表扫描”

首先来体验一下什么是全表扫描，执行下面语句：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10

> 时间: 0.012s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 7.317s

表中数据是按主键从小到大排列的，当查询条件为 `time` < '2020-1-1' 时，能很快地从表的前端找到 10 条满足条件的数据，所以不再继续判断后面的记录，立刻返回结果，耗时 0.012 秒；但当条件改为 `time` < '2000-1-1' 时，同样逐条判断，直到最后一条也没有找到，这种情况就是所谓的“全表扫描”，耗时 7 秒。

索引对 ORDER BY 的 ASC 和 DESC 的影响

我们给 `time` 建一个索引，同样执行刚才需要全表扫描的语句：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10

> 时间: 0.012s

创建 `time` 的索引后，相当于生成了一张按 `time` 字段排列的新表，这时 MySQL 就能够很快地定位并找到符合条件的记录，避免了全表扫描。

试试按 `time` 倒序排：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10

> 时间: 0.013s

结论：索引对 ORDER BY 的顺序（ASC）和倒序（DESC）都是有效的。

索引字段的次序对 WHERE 和 ORDER BY 的影响

删除所有索引，创建一个新的索引，字段依次为 `time`, `a_id`。

分别执行以下查询：

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10

> 时间: 0.013s

结论：MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。

但在 ORDER BY 中却不是这么回事了：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10

> 时间: 14.066s

原因也很好理解，对两个字段进行排序，先后次序肯定会影响结果集，因此只能以 SQL 语句指定的字段次序来 ORDER BY，这样，按索引的字段次序进行 ORDER BY 查询无疑是更快的。

索引中的字段必须依次使用

保持上例创建的索引不变，即 `time`, `a_id`。

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10

> 时间: 6.438s

上句合理利用了索引的字段，而下句跳过了 `time`，直接 WHERE 了 `a_id`，这是不受该索引支持的。

我们可以想象一下这张由索引生成的虚拟表，其实就是一张普通的平面二维表格，按索引指定的字段次序进行了排序，所以全表中仅仅是索引指定的第一个字段是按大小排列的，第二个字段是在第一个字段值相同的区域内按大小排列，后同。所以，跳过索引指定的第一个字段直接对第二个字段进行检索，是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中：

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 29.566s

WHERE 和 ORDER BY 混合

保持上例创建的索引不变，即 `time`, `a_id`。

先来执行这两句：

SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10

> 时间: 12.29s

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

仅仅 WHERE 了一个 `time`，对 ORDER BY `a_id` 的效率却有质的提升，是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗？答案是否定的。

我们把时间改大，让它能马上找到符合条件的数据：

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 22.34s

为什么这个语句就不走索引了呢？

其实，一个简单的 SELECT 查询语句，首先执行 WHERE，然后 ORDER BY，最后是 LIMIT。每一步都独自去找了索引，而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的，最终才是快的。

当 `time` < '2000-1-1' 时，WHERE 用到了索引，所以很快，ORDER BY 却没有用到索引，但为什么也很快呢？因为 WHERE 的结果集非常小（示例中为 0 条）。

当 `time` < '2020-1-1' 时，WHERE 也用到了索引，但其结果集非常大（示例中为所有记录），再 ORDER BY `a_id` 就非常慢了，因为我们没有创建以 `a_id` 开头的索引。

现在把索引改成只有 `time` 一个字段。

SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 6.033s

因为索引里有 `

SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10

> 时间: 0.013s

SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10

> 时间: 6.033s

第二句先 WHERE `a_id`，后 ORDER BY `time` 是不能匹配所建的索引的。

索引中的字段越多越好

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

本例使用 ORDER BY 而不是 WHERE 来测试是因为，在 WHERE 的多个条件下，如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足，无法判断索引是否起作用。

SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 0.013s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.013s

SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10

仅创建索引（`time`）的情况下：

> 时间: 15.015s

仅创建索引（`time`, `a_id`）的情况下：

> 时间: 0.014s

可以看到，在索引字段依次使用的前提下，索引字段数不少于查询字段数才能避免全表扫描。

虽然索引中的字段越多越好，但必须依次使用，否则也是无效索引。

索引对 INSERT / UPDATE / DELETE 的效率影响

分别在创建索引（`time`）和索引（`time`, `a_id`）的情况下执行下面语句：

INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000（注：存在该 id 值的记录）

不建索引的情况下：

> 时间: 0.01s

仅创建索引（`time`）的情况下：

> 时间: 0.01s

同时创建索引（`time`）和索引（`time`, `a_id`）的情况下：

> 时间: 0.01s

虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引，但从实测数据来看，索引对其效率的影响可忽略不计。

一些误区

“in 语法效率很低”?

in 语法也是应用索引的，网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。

另外：

对于字符串类型，LIKE '%abc%' 是不能应用索引的，但 LIKE 'abc%' 可以。更多关于字符串类型的索引，请查阅全文索引（FULLTEXT）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！

xoyozo 8 年前

4,948

从 SQL Server 迁移到 MySQL 要注意什么？

本文基于使用 Navicat 进行数据传输：

配置源数据库和目标数据库：

切换到“高级”。如果是同类型数据库，会有“包含自动递增”选项，但是，从 SQL Server 迁移到 MySQL 则没有：

传输完成后，我们需要对目标数据库作以下调整：

迁移前（SQL Server）	迁移后（MySQL）	如何调整
表名可能有大小写	全部变成小写（默认）	建议单词间以下划线(_)分隔，并修改程序代码
主键标识（是）	自动递增（否）	迁移会保留主键、外键、索引等，但会丢失自动递增。检查每个表，按需设置（遇到外键可以先删除外键再添加，若外键较多，推荐用 SQL 查询的方式，见下文）
bit	tinyint(4)	改为 tinyint(1) 表示布尔型
tinyint	tinyint(4)	原为无符号[0,255]，现为有符号[-127,128]，在设计表定位到该字段，底下勾选“无符号”
nvarchar(n)	varchar(n) 或 text	会根据原长度转为不同类型，需根据实际情况调整
nvarchar(MAX)	longtext	视实际情况调整
smalldatetime	datetime	MySQL 没有精度为“分钟”的时间类型，需根据实际情况调整程序代码
float	double	精度变高了，视情况调整
money	decimal(19,4)	无需调整

其它我没有使用到的字段类型暂未列出。

MySQL 中将用于外键约束的主键设置为自动递增

当主键用于其它表的外键约束时，我们无法更改该主键：

1833 - Cannot change column 'id': used in a foreign key constraint 'FK_xxx' of table 'xxx'

可以先禁用外键检查再设置自增：

set foreign_key_checks = 0;
ALTER TABLE `<table>` MODIFY COLUMN `id` int(11) NOT NULL AUTO_INCREMENT FIRST;

执行完后，foreign_key_checks 会自动恢复为 1。

xoyozo 8 年前

6,759

SQL Server 2014 （高版本）如何迁移到 RDS（低版本）

使用 DTS 在迁移 SQL Server 数据库时，若源数据库的版本是 2012，则迁移到 RDS （版本 2008 R2）警告版本不兼容，但是可以正常迁移；若源数据库的版本是 2014，则出现错误，无法迁移。

如果数据量较小，则可以这样操作：

在源数据库上右键 - 任务 - 生成脚本 - 编写整个数据库及所有数据库对象的脚本

接下来应该不用介绍了。

如果数据量较大，用上面的方法就力不从心了，可以：

在源数据库上右键 - 任务 - 导出数据 - 选择数据源（SQL Server Native Client），填写 RDS 的连接信息，下一步

这种方法的缺点是只导数据，会丢失主键、外键、索引等信息，需要重新设置。

当然也可以用 Navicat 的数据传输工具，可以完整地迁移整个数据库，但如果中途出现 Err （毕竟是第三方）则传输会中断，只能重来一遍并取消勾选出问题的那个表，全部完成后再用 SSMS 来单独导那个表，手动添加主键、外键、索引等。

xoyozo 10 年前

4,538

大型 .NET ERP 系统的 20 条数据库设计规范

数据库设计规范是个技术含量相对低的话题，只需要对标准和规范的坚持即可做到。当系统越来越庞大，严格控制数据库的设计人员，并且有一份规范书供执行参考。在程序框架中，也有一份强制性的约定，当不遵守规范时报错误。

以下20个条款是我从一个超过1000个数据库表的大型ERP系统中提炼出来的设计约定，供参考。

1 所有的表的第一个字段是记录编号Recnum，用于数据维护

[Recnum] [decimal] (8, 0) NOT NULL IDENTITY(1, 1)

在进行数据维护的时候，我们可以直接这样写：

UPDATE Company SET Code='FLEX'  WHERE Recnum=23

2 每个表增加4个必备字段，用于记录该笔数据的创建时间，创建人，最后修改人，最后修改时间

[CreatedDate] [datetime] NULL,
[CreatedBy] [nvarchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[RevisedDate] [datetime] NULL,
[RevisedBy] [nvarchar] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL

框架程序中会强制读取这几个字段，默认写入值。

3 主从表的主外键设计

主表用参考编号RefNo作为主键，从表用RefNo,EntryNo作为主键。RefNo是字符串类型，可用于单据编码功能中自动填写单据流水号，从表的EntryNo是行号，LineNo是SQL Server 的关键字，所以用EntryNo作为行号。

如果是三层表，则第三层表的主键依次是RefNo,EntryNo,DetailEntryNo，第三个主键用于自动增长行号。

4 设计单据状态字段

字段	含义
Posted	过帐，已确认
Closed	已完成
Cancelled	已取消
Approved	已批核
Issued	已发料
Finished	已完成
Suspended	已取消

5 字段含义相近，把相同的单词调成前缀。

比如工作单中的成本核算，人工成本，机器成本，能源成本，用英文表示为LaborCost,MachineCost,EnergyCost

但是为了方便规组，我们把Cost调到字段的前面，于是上面三个字段命名为CostLabor,CostMachine,CostEnergy。

可读性后者要比前者好一点，Visual Studio或SQL Prompt智能感知也可帮助提高字段输入的准确率。

6 单据引用键命名 SourceRefNo SourceEntryNo

销售送货Shipment会引用到是送哪张销售单据的，可以添加如下引用键SourceRefNo,SourceEntryNo，表示送货单引用的销售单的参考编号和行号。Source开头的字段一般用于单据引用关联。

7 数据字典键设计

比如员工主档界面的员工性别Gender，我的方法是在源代码中用枚举定义。性别枚举定义如下：

public enum Gender
{
        [StringValue("M")]
        [DisplayText("Male")]
        Male,

        [StringValue("F")]
        [DisplayText("Female")]
        Female
}

在代码中调用枚举的通用方法，读取枚举的StringValue写入到数据库中，读取枚举的DisplayText显示在界面中。

经过这一层设计，数据库中有关字典方面的设计就规范起来了，避免了数据字典的项的增减给系统带来的问题。

8 数值类型字段长度设计

Price/Qty 数量/单价 6个小数位   nnnnnnnnnn.nnnnnn 格式（10.6）
Amount 金额   2个小数位          nnnnnnnnnnnn.nn 格式（12.2）
Total Amt 总金额 2个小数位       nnnnnnnnnnnnnn.nn 格式（14.2）

参考编号默认16个字符长度，不够用的情况下增加到30个字符，再不够用增加到60个字符。这样可以保证每张单据的第一个参考编号输入控件看起来都是一样长度。

除非特别需求，一般而言，界面中控件的长度取自映射的数据库中字段的定义长度。

9 每个单据表头和明细各增加10个自定义字段，基础资料表增加20个自定义字段

参考供应商主档的自定义字段，自定义字段的名称统一用UserDefinedField。

ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_1] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_2] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_3] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_4] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_5] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_6] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_7] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_8] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_9] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_10] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_11] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_12] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_13] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_14] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_15] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_16] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_17] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_18] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_19] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
ALTER TABLE Vendor ADD  COLUMN [USER_DEFINED_FIELD_20] nvarchar(100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL

10 多货币(本位币)转换字段的设计

金额或单价默认是以日记帐中的货币为记录，当默认货币与本位币不同时需要同时记录下本位币的值。

销售单销售金额 SalesAmount或SalesAmt,本位币字段定义为SalesAmountLocal或SalesAmtLocal

通常是在原来的字段后面加Local表示本位币的值。

11 各种日期字段的设计

字段名称	含义
TranDate	日期帐日期 Tran是Transaction的简写
PostedDate	过帐日期
ClosedDate	完成日期
InvoiceDate	开发票日期
DueDate	截止日期
ScheduleDate	计划日期，这个字段用在不同的单据含义不同。比如销售单是指送货日期，采购单是指收货日期。
OrderDate	订单日期
PayDate	付款日期
CreatedDate	创建日期
RevisedDate	修改日期
SettleDate	付款日期
IssueDate	发出日期
ReceiptDate	收货日期
ExpireDate	过期时间

12 财务有关的单据包含三个标准字段

FiscalYear 财年，PeriodNo 会计期间，Period 前面二个的组合。以国外的财年为例子，FiscalYear是2015，PeriodNo是4，Period是2015/04。

欧美会计期间是从每年的4月份开始，需要注意的是会计期间与时间没有必然的联系，看到会计期间是2015/04，不一定是表示2015的4月份，它只是说这是2015财年的第四期，具体在哪个时间段需要看会计期间定义。

13 单据自动生成 DirectEntry

有些单据是由其它单据生成过来的，逻辑上应该不支持编辑。比如销售送货Shipment单会产生出仓单，出仓单应该不支持编辑，只能做过帐扣减库存操作。这时需要DirectEntry标准字段来表示。当手工创建一张出仓单时，将DirectEntry设为true,表示可编辑单据中的字段值，当由其它单据传递产生过来产生的出仓单，将DirectEntry设为false，表示不能编辑此单据。这种情况还发生在业务单据产生记帐凭证(Voucher)的功能中，如果可以修改由原始单据传递过来的数量金额等字段，则会导致与源单不匹配，给系统对帐产生困扰。

14 百分比值字段的设计

Percentage百分比值，用于折扣率，损耗率等相关比率设定的地方。推荐用数值类型表示，用脚本表示是

[ScrapRate] [decimal] (5, 2) NULL

预留两位小数，整数部分支持1-999三位数。常常是整数部分2位就可以，用3位也是为了支持一些特殊行业(物料损耗率超过100）的要求。

15 日志表记录编号LogNo字段设计

LogNo字段的设计有些巧妙，以出仓单为例子，一张出仓单有5行物料明细，每一行物料出仓都会扣减库存，再写物料进出日记帐，因为这五行物料出仓来自同一个出仓单，于是将这五行物料的日记帐中的LogNo都设为同一个值。于在查询数据时，以这个字段分组即可看到哪些物料是在同一个时间点上出仓的，对快速查询有很重要的作用。

16 基础资料表增加名称，名称长写，代用名称三个字段

比如供应商Vendor表，给它加以下三个字段：

Description 供应商名称，比如微软公司。

ExtDescription 供应商名称长写，比如电气行业的南网的全名是南方国家电网有限公司。

AltDescription 供应商名称替代名称，用在报表或是其它单据引用中。比如采购单中的供应商是用微软，还是用代用名称Microsoft，由参数(是否用代用名称)控制。

17 文件类表增加MD5 Hash字段

比如产品数据管理系统要读取图纸，单据功能中增加的附件文件，这类涉及文件读写引用的地方，考虑存放文件的MD5哈希值。文件的MD5相当于文件的唯一识别身份，在网上下载文件时，网站常常会放出文件的MD5值，以方便对比核对。当下载到本机的文件的MD5值与网站上给出的值不一致时，有可能这个文件被第三方程序修改过，不可信任。

18 数据表的主键用字符串而不是数字

比如销售单中的货币字段，是存放货币表的货币字符串值RMB/HKD/USD，还是存放货币表的数字键，1/2/3。

存放前者对于报表制作相对容易，但是修改起来相对麻烦。存放后者对修改数据容易，但对报表类或查询类操作都需要增加一个左右连接来看数字代表的货币。金蝶使用的是后者，它的BOS系统也不允许数据表之间有直接的关联，而是间接通过Id值来关联表。

在我看到的系统中，只有一个会计期间功能(财年Fiscal Year)用到数字值作主键，其余的单据全部是字符串做主键。

19 使用约定俗成的简写

模块Module 简写

简写	全名
SL	Sales 销售
PU	Purchasing 采购
IC	Inventory 仓库
AR	Account Receivable 应收
AP	Account Payable 应付
GL	General Ledger 总帐
PR	Production 生产

名称Name 简写

简写	全名
Uom	Unit of Measure 单位
Ccy	Currency 货币
Amt	Amount 金额
Qty	Quantity 数量
Qty Per	Quantity Per 用量
Std Output	Standard Output 标准产量
ETA	Estimated Time of Arrival 预定到达时间
ETD	Estimated Time of Departure 预定出发时间
COD	Cash On Delivery 货到付款
SO	Sales Order 销售单
PO	Purchase Order 采购单

20 库存单据数量状态

Qty On Hand 在手量

Qty Available 可用量

Qty On Inspect 在验数量

Qty On Commited 提交数量

Qty Reserved 预留数量

以上每个字段都有标准和行业约定的含义，不可随意修改取数方法。

转自 James Li 10 年前

3,702

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

体验“全表扫描”

索引对 ORDER BY 的 ASC 和 DESC 的影响

索引字段的次序对 WHERE 和 ORDER BY 的影响

索引中的字段必须依次使用

WHERE 和 ORDER BY 混合

索引中的字段越多越好

索引对 INSERT / UPDATE / DELETE 的效率影响

一些误区

MySQL 中将用于外键约束的主键设置为自动递增

1 所有的表的第一个字段是记录编号Recnum，用于数据维护

2 每个表增加4个必备字段，用于记录该笔数据的创建时间，创建人，最后修改人，最后修改时间

3 主从表的主外键设计

4 设计单据状态字段

5 字段含义相近，把相同的单词调成前缀。

6 单据引用键命名 SourceRefNo SourceEntryNo

7 数据字典键设计

8 数值类型字段长度设计

9 每个单据表头和明细各增加10个自定义字段，基础资料表增加20个自定义字段

10 多货币(本位币)转换字段的设计

11 各种日期字段的设计

12 财务有关的单据包含三个标准字段

13 单据自动生成 DirectEntry

14 百分比值字段的设计

15 日志表记录编号LogNo字段设计

16 基础资料表增加名称，名称长写，代用名称三个字段

17 文件类表增加MD5 Hash字段

18 数据表的主键用字符串而不是数字

19 使用约定俗成的简写

20 库存单据数量状态

大家在看

最新发布

查询 / 检测

编程

前端

行业

本站 API

博客 (9)

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

体验“全表扫描”

索引对 ORDER BY 的 ASC 和 DESC 的影响

索引字段的次序对 WHERE 和 ORDER BY 的影响

索引中的字段必须依次使用

WHERE 和 ORDER BY 混合

索引中的字段越多越好

索引对 INSERT / UPDATE / DELETE 的效率影响

一些误区

MySQL 中将用于外键约束的主键设置为自动递增

1 所有的表的第一个字段是记录编号Recnum，用于数据维护

2 每个表增加4个必备字段，用于记录该笔数据的创建时间，创建人，最后修改人，最后修改时间

3 主从表的主外键设计

4 设计单据状态字段

5 字段含义相近，把相同的单词调成前缀。

6 单据引用键命名 SourceRefNo SourceEntryNo

7 数据字典键设计

8 数值类型字段长度设计

9 每个单据表头和明细各增加10个自定义字段，基础资料表增加20个自定义字段

10 多货币(本位币)转换字段的设计

11 各种日期字段的设计

12 财务有关的单据包含三个标准字段

13 单据自动生成 DirectEntry

14 百分比值字段的设计

15 日志表记录编号LogNo字段设计

16 基础资料表增加名称，名称长写，代用名称三个字段

17 文件类表增加MD5 Hash字段

18 数据表的主键用字符串而不是数字

19 使用约定俗成的简写

20 库存单据数量状态

大家在看

最新发布