摘要：
当一个实体包含多个计算列时，如何处理？1 示例需求：在海外采购时，将产生多种费用，如：班轮费、报关费、卸货费，仓储费、利息费，银行手续费等等。这些费用的公式如下：班轮费No. of FCL x rate报关费No. of FCL x rate卸货费No. of FCL x rate仓储费Qty (MT) x Conversion (MT/m3) x rate利息费N/A银行手续费Bank Charges = Purchase Amount x 0.003上面仅是一个简单的需求，根据公司所处的国家不同，这些公式也将做相应的调整；并且，隔一段时间，根据政策的变化，公式也需要做相应的调整。2 解决方 阅读全文
随笔分类 - [05]数据库设计
常用数据库设计（5）————业务匹配表设计
2013-03-12 22:10 by Mike.Jiang, 3104 阅读, 收藏, 编辑
摘要：
1 概述在应用系统中经常会有这样的一个业务需求：对于一个动态的基础信息表，需要标识其中一个或多个记录。比如：账务系统中的成本科目，成本科目是动态添加，但我们在计算某些成本时要去掉固定资产成本类型。对于单位基本信息的维护，单位也是可以动态添加的，但我们的货物要有一个基础单位（公吨），并有默认有一个转换为立方米的设置。即我们需要知道固定资产在成本表中是哪一条记录，公吨在单位表中是哪一条记录，立方米在单位表中是一条记录。诚然对于这些需求，我们可以在原表上加一些标识字段就可以解决。但这样为了一些特殊的需求打乱了原有的设计，要修改原有的代码。2 解决方案为了解决这种基础信息特殊设置的情况，我们创建了一张 阅读全文
数据库设计系列[05]多公司加入权限系统
2013-01-22 22:15 by Mike.Jiang, 7443 阅读, 收藏, 编辑
摘要：
1 引言先解释下上一篇部门+权限文章“数据库设计系列[04]组织结构加入权限系统”最终的结果：1> Employee:独立管理用户信息；2> Dept:独立管理部门信息；3> Post(Role)独立管理岗位信息；4> Resource：独立管理资源（页面和按钮）信息；5> Organization:管理部门+岗位实例的树形实体；6> PostPermission:管理岗位的权限，即某个岗位类型对应的页面即按钮信息；7> EmployeePermission：管理员工的权限，将Organization中的岗位实例分配给员工；总得来说，还是基于角色操作的 阅读全文
数据库设计系列[04]组织结构加入权限系统
2013-01-16 23:01 by Mike.Jiang, 12158 阅读, 收藏, 编辑
摘要：
1引言接着上一篇随笔“数据库设计系列[03]权限系统”；在上篇随笔中，只是简单地介绍基于角色和操作访问控制模型，能把权限控制到页面和按钮。CDM图:2 新的需求：组织结构比如在一个大型的手机销售公司有这样的一种部门岗位结构：现在有下面的需求1>要求给用户分配权限时用苹果部门经理、诺基亚部门经理…而不是部门经理这样的岗位；2>要求统计苹果部门经理、诺基亚部门经理的销售业绩；当有上面这些需求时，上篇随笔中的权限模型就无法满足需求。3 加入组织结构后的权限模型我们先不考虑部门信息，这样上面的结构图中就只剩下岗位信息。对这样的需求建模，第一个反应是将岗位(POST)建成树形结构。但是这样一 阅读全文
数据库设计系列[03]权限系统
2013-01-15 21:26 by Mike.Jiang, 4331 阅读, 收藏, 编辑
摘要：
1 权限模型中的业务对象及联系在权限模型中主要有三个对象员工、岗位（角色）和资源。它们之间的关系为：员工与岗位之间的多对多，岗位与资源也是多对多的关系。即，可以为一位员工分配多个岗位，可以将一个岗位分配给多位员工；可以为一个岗位分配多个资源，也可以将一个岗位分配给多个角色。实体关系图如下：2 业务对象联系的细化标识上三个对象的关键属性，以及它们之间的联系，如下图：Employee:只管理员工信息，不与角色关联；Post:仅管理岗位信息，（如果需要父岗位可以访问子岗位的资源，可以将岗位表设计成一个树形结构的数据）；Resource:只单独管理资源信息，资源包括页面和按钮，用TYPE来区别，并且通 阅读全文
数据库设计系列[01]一些重要的概念
2013-01-15 21:25 by Mike.Jiang, 1373 阅读, 收藏, 编辑
摘要：
1, 数据库不是万能的 正如我们做任何事情一样，我们不可能把每一个方面都做的完美。在做数据库初步设计时，我们同样也做不到将任何现实中繁杂的概念反应到数据库中，毕竟描述数据库语言也很有限，不要总想着把任务业务都加进去，要知道适可而止。所以在设计数据时，要标识出关键的业务实体即可，一些极为繁杂的行为可以其它地方实现。2，关系模型 经常谈关系模型，那么什么是“关系”呢？ 之前一直将关系模型中的关系理解为，表之间的关系，但实际上是表内不同字段间的关系。 阅读全文
数据库设计系列[02]为什么要学习数据库设计
2012-12-17 22:57 by Mike.Jiang, 1564 阅读, 收藏, 编辑
摘要：
1，不好的数据库设计，产生的问题?在数据库概念设计阶段，对于同一领域建模，不同的建模人员得到的结果不一样，从而转换后的关系模式也不一样。这样就存在关系模式的优劣之分。学习数据库设计，就是要学习前人总结的一些规则，常用的表示方法。在学习如何进行设计之前，我们先了解下差的设计产生的问题。2，示例场景在采购的场景中，需要记录订单号、商品信息和操作人信息。如果我们这样设计存在的问题有：数据冗余、插入异常、更新异常和删除异常；2.1数据冗余在这个应用设计中，OrderNum和CreateName重复存储了。当订单量很大，这样的浪费就很可观了。2.2 插入异常从这个关系模式的设计中，我们可以看到Order 阅读全文
常见数据库设计（4）——树形结构数据
2012-08-29 10:39 by Mike.Jiang, 41700 阅读, 收藏, 编辑
摘要：
1 概述树形数据，主要关注的是：1> 如何将数据高效地以树形的形式展现给用户2> 通过某个节点找到所有的父节点。3> 获取某个节点的所有的后继节点（包括子节点的子节点）至于添加、修改、删除和通过一个父节点获取对应的子节点，都是可以很容易的实现。2 邻接模型2.1业务：文件存放位置，在档案管理中，需要为文件的存放位置建模，文件存在抽屉，然后抽屉在某个柜子中，柜子在某个房间中。2.2表结构：2.3备注可以在表中再加入一个level_num字段(表示所处在树的深度)，这样就少了那一个递归查询的操作，但是在管理上有做一些处理。2.4 Normal 0 7.8 磅 0 2 ... 阅读全文
常见数据库设计（3）——历史数据问题之多记录变更
2012-08-28 22:13 by Mike.Jiang, 9121 阅读, 收藏, 编辑
摘要：
关于历史数据的单记录变更：常见数据库设计(2)——历史数据问题之单记录变更1．概述在保存客户操作历史数据时，有一种数据，如标书的标书流水+标书清单、细化方案的细化方案流水+细化方案清单、商品价格的价格变动流水+变动清单等等。这样的历史数据，它们都有一个控制流水版本的主流水表，还有一个与某个版本对应的清单表。2. 多记录变更、无储存未来历史记录的需求，储存于单表中业务：在做付款计划时，需要保存计划的历史版本数据，同时也要记录每一计划针对哪些物资进行付款的。表结构说明：如单记录一样，版本的控制在付款计划表中。主体如何实现版本控制请参见单记录变更3. 多记录变更、无储存未来历史记录的需求，储存于多表 阅读全文
常见数据库设计(2)——历史数据问题之单记录变更
2012-06-05 01:31 by Mike.Jiang, 6511 阅读, 收藏, 编辑
摘要：
在各种应用软件中，客户总是希望看到自己操作关键业务的历史数据（更或者是将来的历史数据，如本年计划明年的商品价格），并且要跟踪变化来源于哪一个版本。历史记录，如果我们按某次修改时，需要新增的记录条件的角度来看，如果只需要新增一条记录（如商品价格的变动，一次只变动），我们称之为单记录变更；如果我们需要新增一条记录，并且还需要在不同的表中新增对应的详细记录并且是一对多的关系时（如报价时，我们需要储存报价流水和报价物品清单列表），我们称之为多记录变更。一，单记录变更、无储存未来历史记录的需求，储存于单表中付款计划 PayPlan 字段名 类型 是否可空 中文名 描述id c... 阅读全文
常见数据库设计（1）——字典数据
2012-05-30 10:33 by Mike.Jiang, 35667 阅读, 收藏, 编辑
摘要：
在稍大一些的项目中，我们总是需要管理各种各样的类型类型数据（如商品类型、游戏类型。。。）。对于这些类型的管理类似，如果为每一种类型都建立一张表去维护（而在项目中，正常出现50种类型），那工作量是可想而之大，并且我们不得不去了解每一个类型表的名字，以去关联它。 因此，我们需要一种数据模型以完成对多种多样类型管理的需求。字典表dictionary 字段名 类型 是否可空 中文名 描述dict_name varchar(50) no 字典名字 dict_value int no 字典值 固定的，不变的字典数据表dictionarydata 字段名... 阅读全文