搭建论坛《搭建之星》论坛数据库交流 → [转帖]数据库设计指南6


  共有2018人关注过本帖树形打印

主题:[转帖]数据库设计指南6

帅哥哟,离线,有人找我吗?
水手
  1楼 个性首页 | QQ | 信息 | 搜索 | 邮箱 | 主页 | UC


加好友 发短信 班长
等级:版主 帖子:998 积分:2851 威望:4 精华:3 注册:2002-4-17 8:42:46
[转帖]数据库设计指南6  发帖心情 Post By:2003-4-28 22:00:17

21. 避免使用触发器 触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采 用触发器,你最好集中对它文档化。 22. 包含版本机制 — kol 建议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要 求。时间一长,用户的需求总是会改变的。最终可能会要求修改数据库结构。虽然你可以通过检 查新字段或者索引来确定数据库结构的版本,但我发现把版本信息直接存放到数据库中不更为方 便吗?。 23. 给文本字段留足余量 24. 列命名技巧 — tlundin 我们发现,假如你给每个表的列名都采用统一的前缀,那么在编写SQL 表达式的时候会得到大 大的简化。这样做也确实有缺点,比如破坏了自动表连接工具的作用,后者把公共列名同某些数 据库联系起来,不过就连这些工具有时不也连接错误嘛。举个简单的例子,假设有两个表: Customer 和Order。Customer 表的前缀是cu_,所以该表内的子段名如下:cu_name_id、 — Richard Foster ID 类型的文本字段,比如客户ID 或定单号等等都应该设置得比一般想象更大,因为时间不长你 多半就会因为要添加额外的字符而难堪不已。比方说,假设你的客户ID 为10 位数长。那你应该 把数据库表字段的长度设为12 或者13 个字符长。这算浪费空间吗?是有一点,但也没你想象的 那么多:一个字段加长3 个字符在有1 百万条记录,再加上一点索引的情况下才不过让整个数据 库多占据3MB 的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模 的增长了。 cu_surname、cu_initials 和cu_address 等。Order 表的前缀是or_,所以子段名是: or_order_id、or_cust_name_id、or_quantity 和or_description 等。 这样从数据库中选出全部数据的SQL 语句可以写成如下所示: Select * from Customer, Order Where cu_surname = "MYNAME" and cu_name_id = or_cust_name_id and or_quantity = 1; 在没有这些前缀的情况下则写成这个样子: Select * from Customer, Order Where Customer.surname = "MYNAME" and Customer.name_id = Order.cust_name_id and Order.quantity = 1 第1 个SQL 语句没少键入多少字符。但如果查询涉及到5 个表乃至更多的列你就知道这个技巧 多有用了。 — Bryce Stenberg Page 9 . CNET Networks Inc. 2002 www.zdnet.com.cn/developer — hscovell 可操作数据仓库(ODS)和数据仓库(DW)这两种环境下的数据索引是有差别的。在DW 环境 下,你要考虑销售部门是如何组织销售活动的。他们并不是数据库管理员,但是他们确定表内的 键信息。这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间 的最佳条件。 — teburlew 这一天类同技巧1,但我觉得有必要在这里重复提醒大家。假如你总是在设计数据库的时候采用 系统生成的键作为主键,那么你实际控制了数据库的索引完整性。这样,数据库和非人工机制就 有效地控制了对存储数据中每一行的访问。 采用系统生成键作为主键还有一个优点:当你拥有一致的键结构时,找到逻辑缺陷很容易。 — teburlew 为了分离命名字段和包含字段以支持用户定义的报表,请考虑分解其他字段(甚至主键)为其组 成要素以便用户可以对其进行索引。索引将加快SQL 和报表生成器脚本的执行速度。比方说, 我通常在必须使用SQL LIKE 表达式的情况下创建报表,因为case number 字段无法分解为 year、serial number、case type 和defendant code 等要素。性能也会变坏。假如年度和类型字 段可以分解为索引字段那么这些报表运行起来就会快多了。 — rdelval 第3 部分— 选择键和索引 1. 数据采掘要预先计划 我所在的市场部门一度要处理8 万多份联系方式,同时填写每个客户的必要数据(这绝对不是小 活)。我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候,我试图不 在主索引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘 既不准确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发现有一个指示计划相 当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢?我可以用传真号码 进行检索,但是它几乎就象系统类型一样对我来说并不重要。采用后者作为主字段,数据库更新 后重新索引和检索就快多了。 2. 使用系统生成的主键 3. 分解字段用于索引 4. 键设计4 原则 · 为关联字段创建外键。 · 所有的键都必须唯一。 · 避免使用复合键。 · 外键总是关联唯一的键字段。 — Peter Ritchie Page 10 . CNET Networks Inc. 2002 www.zdnet.com.cn/developer


HeaderSoft与您共同进步!

      衡德软件  http://www.headersoft.com

qhd.cw@163.com

QQ:106260929

支持(0中立(0反对(0单帖管理 | 引用 | 回复 回到顶部

返回版面帖子列表

[转帖]数据库设计指南6








签名