论坛数据库设计

⑴ 做论坛对于视频文件如何储存,数据库库如何设计

1、正常创一个文件信息表，主键，文件名，文件真实名，文件存储路径，文件类型，关晌如册橡枣联表id，上传时间。

2、存在数据库中的肯定是文件的存储路径。取得时候就是通过路径去取。

3、你上传视频文件，数据库保存文件名字，路径

4、全部转换宴宏成二进制，存到数据库中，或者存为url

⑵ 数据库如何设计

数据库设计的基本步骤

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下6个阶段

1.需求分析

2.概念结构设计

3.逻辑结构设计

4.物理结构设计

5.数据库实施

6.数据库的运行和维护

数据库设计通常分为6个阶段1分析用户的需求，包括数据、功能和性能需求；2概念结构设计：主要采用E-R模型进行设计，包括画E-R图；3逻辑结构设计：通过将转换成表，实现从E-R模型到关系模型的转换；4：主要是为所设计的数据库选择合适的和存取路径；5数据库的实施：包括编程、测试和试运行；6数据库运行与维护：系统的运行与数据库的日常维护。）,主要讨论其中的第3个阶段,即逻辑设计。

在数据库设计过程中，需求分析和概念设计可以独立于任何数据库管理系统进行，逻辑设计和物理设计与选用的DAMS密切相关。

1.需求分析阶段（常用自顶向下）

进行数据库设计首先必须准确了解和分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，也是最困难，最耗时的一步。需求分析是否做得充分和准确，决定了在其上构建数据库大厦的速度与质量。需求分析做的不好，会导致整个数据库设计返工重做。

需求分析的任务，是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求，然后在此基础上确定新的系统功能，新系统还得充分考虑今后可能的扩充与改变，不仅仅能够按当前应用需求来设计。

调查的重点是，数据与处理。达到信息要求，处理要求，安全性和完整性要求。

分析方法常用SA(Structured Analysis) 结构化分析方法，SA方法从最上层的系统组织结构入手，采用自顶向下，逐层分解的方式分析系统。

数据流图表达了数据和处理过程的关系，在SA方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。在处理功能逐步分解的同事，系统中的数据也逐级分解，形成若干层次的数据流图。系统中的数据则借助数据字典（data dictionary，DD）来描述。数据字典是系统中各类数据描述的集合，数据字典通常包括数据项，数据结构，数据流，数据存储，和处理过程5个阶段。

2.概念结构设计阶段（常用自底向上）

概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合，归纳与抽象，形成了一个独立于具体DBMS的概念模型。

设计概念结构通常有四类方法：

• 自顶向下。即首先定义全局概念结构的框架，再逐步细化。

• 自底向上。即首先定义各局部应用的概念结构，然后再将他们集成起来，得到全局概念结构。

• 逐步扩张。首先定义最重要的核心概念结构，然后向外扩张，以滚雪球的方式逐步生成其他的概念结构，直至总体概念结构。

• 混合策略。即自顶向下和自底向上相结合。

3.逻辑结构设计阶段（E-R图）

逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型，并将进行优化。

在这阶段，E-R图显得异常重要。大家要学会各个实体定义的属性来画出总体的E-R图。

各分E-R图之间的冲突主要有三类：属性冲突，命名冲突，和结构冲突。

E-R图向关系模型的转换，要解决的问题是如何将实体性和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。

4.物理设计阶段

物理设计是为逻辑数据结构模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。

首先要对运行的事务详细分析，获得选择物理数据库设计所需要的参数，其次，要充分了解所用的RDBMS的内部特征，特别是系统提供的存取方法和存储结构。

常用的存取方法有三类：1.索引方法，目前主要是B+树索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。

5.数据库实施阶段

数据库实施阶段，设计人员运营DBMS提供的数据库语言（如sql）及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行。

6.数据库运行和维护阶段

数据库应用系统经过试运行后，即可投入正式运行，在数据库系统运行过程中必须不断地对其进行评价，调整，修改。

数据库设计5步骤
Five Steps to design the Database

1.确定entities及relationships

a)明确宏观行为。数据库是用来做什么的？比如，管理雇员的信息。

b)确定entities。对于一系列的行为，确定所管理信息所涉及到的主题范围。这将变成table。比如，雇用员工，指定具体部门，确定技能等级。

c)确定relationships。分析行为，确定tables之间有何种关系。比如，部门与雇员之间存在一种关系。给这种关系命名。

d)细化行为。从宏观行为开始，现在仔细检查这些行为，看有哪些行为能转为微观行为。比如，管理雇员的信息可细化为：

· 增加新员工

· 修改存在员工信息

· 删除调走的员工

e)确定业务规则。分析业务规则，确定你要采取哪种。比如，可能有这样一种规则，一个部门有且只能有一个部门领导。这些规则将被设计到数据库的结构中。

====================================================================
范例：
ACME是一个小公司，在5个地方都设有办事处。当前，有75名员工。公司准备快速扩大规模，划分了9个部门，每个部门都有其领导。
为有助于寻求新的员工，人事部门规划了68种技能，为将来人事管理作好准备。员工被招进时，每一种技能的专业等级都被确定。


定义宏观行为
一些ACME公司的宏观行为包括：
● 招聘员工
● 解雇员工
● 管理员工个人信息
● 管理公司所需的技能信息
● 管理哪位员工有哪些技能
● 管理部门信息
● 管理办事处信息
确定entities及relationships
我们可以确定要存放信息的主题领域(表)及其关系，并创建一个基于宏观行为及描述的图表。
我们用方框来代表table，用菱形代表relationship。我们可以确定哪些relationship是一对多，一对一，及多对多。
这是一个E-R草图，以后会细化。



细化宏观行为
以下微观行为基于上面宏观行为而形成：
● 增加或删除一个员工
● 增加或删除一个办事处
● 列出一个部门中的所有员工
● 增加一项技能
● 增加一个员工的一项技能
● 确定一个员工的技能
● 确定一个员工每项技能的等级
● 确定所有拥有相同等级的某项技能的员工
● 修改员工的技能等级

这些微观行为可用来确定需要哪些table或relationship。

确定业务规则
业务规则常用于确定一对多，一对一，及多对多关系。
相关的业务规则可能有：
● 现在有5个办事处；最多允许扩展到10个。
● 员工可以改变部门或办事处
● 每个部门有一个部门领导
● 每个办事处至多有3个电话号码
● 每个电话号码有一个或多个扩展
● 员工被招进时，每一种技能的专业等级都被确定。
● 每位员工拥有3到20个技能
● 某位员工可能被安排在一个办事处，也可能不安排办事处。

2.确定所需数据

要确定所需数据：

a)确定支持数据

b)列出所要跟踪的所有数据。描述table(主题)的数据回答这些问题：谁，什么，哪里，何时，以及为什么

c)为每个table建立数据

d)列出每个table目前看起来合适的可用数据

e)为每个relationship设置数据

f)如果有，为每个relationship列出适用的数据

确定支持数据

你所确定的支持数据将会成为table中的字段名。比如，下列数据将适用于表Employee，表Skill，表Expert In。

Employee

Skill

Expert In

ID

ID

Level

Last Name

Name

Date acquired

First Name

Description

Department

Office

Address


如果将这些数据画成图表，就像：



• 需要注意：


• ● 在确定支持数据时，请一定要参考你之前所确定的宏观行为，以清楚如何利用这些数据。


• ● 比如，如果你知道你需要所有员工的按姓氏排序的列表，确保你将支持数据分解为名字与姓氏，这比简单地提供一个名字会更好。


• ● 你所选择的名称最好保持一致性。这将更易于维护数据库，也更易于阅读所输出的报表。


• ● 比如，如果你在某些地方用了一个缩写名称Emp_status，你就不应该在另外一个地方使用全名(Empolyee_ID)。相反，这些名称应当是Emp_status及Emp_id。


• ● 数据是否与正确的table相对应无关紧要，你可以根据自己的喜好来定。在下节中，你会通过测试对此作出判断。

3.标准化数据

标准化是你用以消除数据冗余及确保数据与正确的table或relationship相关联的一系列测试。共有5个测试。本节中，我们将讨论经常使用的3个。
关于标准化测试的更多信息，请参考有关数据库设计的书籍。

标准化格式
标准化格式是标准化数据的常用测试方式。你的数据通过第一遍测试后，就被认为是达到第一标准化格式；通过第二遍测试，达到第二标准化格式；通过第三遍测试，达到第三标准化格式。

如何标准格式：
1． 列出数据
2． 为每个表确定至少一个键。每个表必须有一个主键。
3． 确定relationships的键。relationships的键是连接两个表的键。
4． 检查支持数据列表中的计算数据。计算数据通常不保存在数据库中。
5． 将数据放在第一遍的标准化格式中：
6． 从tables及relationships除去重复的数据。
7． 以你所除去数据创建一个或更多的tables及relationships。
8． 将数据放在第二遍的标准化格式中：
9． 用多于一个以上的键确定tables及relationships。
10． 除去只依赖于键一部分的数据。
11． 以你所除去数据创建一个或更多的tables及relationships。
12． 将数据放在第三遍的标准化格式中：
13． 除去那些依赖于tables或relationships中其他数据，并且不是键的数据。
14． 以你所除去数据创建一个或更多的tables及relationships。

数据与键
在你开始标准化（测试数据）前，简单地列出数据，并为每张表确定一个唯一的主键。这个键可以由一个字段或几个字段（连锁键）组成。

主键是一张表中唯一区分各行的一组字段。Employee表的主键是Employee ID字段。Works In relationship中的主键包括Office Code及Employee ID字段。给数据库中每一relationship给出一个键，从其所连接的每一个table中抽取其键产生。

RelationShip

Key

Office

*Office code

Office address

Phone number

Works in

*Office code

*Employee ID

Department

*Department ID

Department name

Heads

*Department ID

*Employee ID

Assoc with

*Department ID

*EmployeeID

Skill

*Skill ID

Skill name

Skill description

Expert In

*Skill ID

*Employee ID

Skill level

Date acquired

Employee

*Employee ID

Last Name

First Name

Social security number

Employee street

Employee city

Employee state

Employee phone

Date of birth


将数据放在第一遍的标准化格式中
● 除去重复的组
● 要测试第一遍标准化格式，除去重复的组，并将它们放进他们各自的一张表中。
● 在下面的例子中，Phone Number可以重复。（一个工作人员可以有多于一个的电话号码。）将重复的组除去，创建一个名为Telephone的新表。在Telephone与Office创建一个名为Associated With的relationship。

将数据放在第二遍的标准化格式中
● 除去那些不依赖于整个键的数据。
● 只看那些有一个以上键的tables及relationships。要测试第二遍标准化格式，除去那些不依赖于整个键的任何数据（组成键的所有字段）。
● 在此例中，原Employee表有一个由两个字段组成的键。一些数据不依赖于整个键；例如，department name只依赖于其中一个键（Department ID）。因此，Department ID，其他Employee数据并不依赖于它，应移至一个名为Department的新表中，并为Employee及Department建立一个名为Assigned To的relationship。


将数据放在第三遍的标准化格式中
● 除去那些不直接依赖于键的数据。
● 要测试第三遍标准化格式，除去那些不是直接依赖于键，而是依赖于其他数据的数据。
● 在此例中，原Employee表有依赖于其键（Employee ID）的数据。然而，office location及office phone依赖于其他字段，即Office Code。它们不直接依赖于Employee ID键。将这组数据，包括Office Code，移至一个名为Office的新表中，并为Employee及Office建立一个名为Works In的relationship。

4.考量关系

当你完成标准化进程后，你的设计已经差不多完成了。你所需要做的，就是考量关系。

考量带有数据的关系
你的一些relationship可能集含有数据。这经常发生在多对多的关系中。

遇到这种情况，将relationship转化为一个table。relationship的键依旧成为table中的键。

考量没有数据的关系
要实现没有数据的关系，你需要定义外部键。外部键是含有另外一个表中主键的一个或多个字段。外部键使你能同时连接多表数据。

有一些基本原则能帮助你决定将这些键放在哪里：

一对多在一对多关系中，“一”中的主键放在“多”中。此例中，外部键放在Employee表中。

一对一在一对一关系中，外部键可以放进任一表中。如果必须要放在某一边，而不能放在另一边，应该放在必须的一边。此例中，外部键（Head ID）在Department表中，因为这是必需的。

多对多在多对多关系中，用两个外部键来创建一个新表。已存的旧表通过这个新表来发生联系。

5.检验设计

在你完成设计之前，你需要确保它满足你的需要。检查你在一开始时所定义的行为，确认你可以获取行为所需要的所有数据：
● 你能找到一个路径来等到你所需要的所有信息吗？
● 设计是否满足了你的需要？
● 所有需要的数据都可用吗？
如果你对以上的问题都回答是，你已经差不多完成设计了。

最终设计
最终设计看起来就像这样：

设计数据库的表属性
数据库设计需要确定有什么表，每张表有什么字段。此节讨论如何指定各字段的属性。

对于每一字段，你必须决定字段名，数据类型及大小，是否允许NULL值，以及你是否希望数据库限制字段中所允许的值。

选择字段名
字段名可以是字母、数字或符号的任意组合。然而，如果字段名包括了字母、数字或下划线、或并不以字母打头，或者它是个关键字（详见关键字表），那么当使用字段名称时，必须用双引号括起来。

为字段选择数据类型
SQL Anywhere支持的数据类型包括：
整数（int, integer, smallint）
小数（decimal, numeric）
浮点数（float, double）
字符型（char, varchar, long varchar）
二进制数据类型（binary, long binary）
日期/时间类型（date, time, timestamp）
用户自定义类型

关于数据类型的内容，请参见“SQL Anywhere数据类型”一节。字段的数据类型影响字段的最大尺寸。例如，如果你指定SMALLINT，此字段可以容纳32,767的整数。INTEGER可以容纳2,147,483,647的整数。对CHAR来讲，字段的最大值必须指定。

长二进制的数据类型可用来在数据库中保存例如图像(如位图)或者文字编辑文档。这些类型的信息通常被称为二进制大型对象，或者BLOBS。

关于每一数据类型的完整描述，见“SQL Anywhere数据类型”。

⑶ 如何设计合理高效的数据库

一、 引言数据库对于企业信息化的重要性是不言而喻的。数据库存储着现代企业最重要的数据，包括生产、经营、管理等各类数据，这些数据作为企业的核心信息，通过各类信息系统，为用户提供及时准确的信息，帮助用户分析，为用户提供决策依据。为提高企业的工作效率，提升企业形象，具有传统模式无法比拟的优势。其中构建合理高效的数据库，是数据库建设关键之一。如何构建合理高效的数据库是企业信息化过程要解决的问题。下面就数据库的构建谈谈自己的一些经验，希望能对大家有所帮助。 二、 设计数据库之前
数据库并不是凭空想象出来的，而是根据业务部门的需要设计符合业务需求的数据库。因此在形成数据库之前需要充分了解业务需求。 1. 充分理解业务需求。需求分析是整个设计过程的基础，是最困难、最耗费时间的一步。在这期间通过与业务部门交流，了解用户的想法以及工作流程，通过双方多次交流，会形成初步的数据模型，当然这时的数据模型不会是最终的模型，还需要和用户进行交流，并且在以后的信息系统开发过程中还会反复修改。 2. 重视输入输出。在定义数据库表和字段需求（输入）时，首先应了解数据产生源和数据流程，也就是必需要知道每个数据在那儿产生，数据在那儿表现，以什么样的形式表现等等，然后根据用户提供的报表或者设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。 3. 创建数据字典和ER 图表。ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。 需要注意的是，在需求分析调研过程中，并不是一帆风顺的，因为业务人员对于业务的理解不同，以及对于信息知识的缺乏，会影响需求分析的质量，为了提高质量，各方要用更多的时间交流与相互理解，业务部门需要精通业务的人员自始至终全力配合，而开发人员则尽量使用用户理解的业务术语交流，这样会避免出现理解不同而产生的歧义。 三、 设计合理的表结构
通常合理的表结构会减少数据冗余，提高数据库的性能。设计合理的表结构要遵循以下两点。 1. 标准化和规范化 数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但3NF(第三范式)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF标准的数据库的表设计原则是：某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。 例如：某个存放单井信息及其有关油井生产日报信息的3NF数据库就有两个表：单井基础信息和油井日报信息。日报信息不包含单井的任何信息，但表内会存放一个键值，该键指向单井基础信息里包含该油井信息的那一行。 不过也有例外，有时为了效率的缘故，对表不进行标准化也是必要的。 2. 考虑各种变化 在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。使数据库更具扩展性，从而减少将来数据变更所带来的损失。 例如，日期类型字段，有时我们会考虑使用字符类型代替日期类型，因为在处理日期字段上容易产生数据错误，所以我们就使用字符类型。这样的例子还很多，在做前期设计时都要考虑的。 表结构的设计不是一次就能成功的，在信息系统开发过程中会存在数据读取、录入或统计困难，为了解决这些问题会修改表结构，或增加一些字段，或修改一些字段的属性。这个过程不断重复，因此不要想一次能成功。建议使用专门设计工具来做这些工作，笔者经常使用：SYBASE PowerDesigner ，当然还有其它的工具：ORACLE Designer 2000 ，ROSE等工具。这样会使你的工作事半功倍。 四、 选择合理的索引
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。 1. 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。 2. 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。 3. 不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。如MEMO(备注)、TEXT(文本)等字段。 4. 不要索引常用的小型表 不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。如代码表，或系统参数表。 五、 保证数据完整性
数据的完整性非常重要，这关系到数据的准确性，不准确的数据是毫无价值的，因此保证数据的完整性非常重要。 1. 完整性实现机制：实体完整性：主键参照完整性： 父表中删除数据：级联删除；受限删除；置空值父表中插入数据：受限插入；递归插入 父表中更新数据：级联更新；受限更新；置空值 DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制用户定义完整性：NOT NULL；CHECK；触发器 以上完整性机制需要熟悉和掌握，它对于数据的完整性非常重要。 2. 用约束而非业务规则强制数据完整性 采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于业务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。 3. 强制指示完整性 在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。 4. 使用查找控制数据完整性 控制数据完整性的最佳方式就是限制用户的录入。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：性别代码、单位代码等。 5. 采用视图 视图是一个虚拟表，其内容由SQL语句定义，视图不仅可以简化用户对数据的理解，也可以简化他们的操作。那些被经常使用的查询可以被定义为视图，从而使得用户不必为以后的操作每次指定全部的条件。另外通过视图用户只能查询和修改他们所能见到的数据。数据库中的其它数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上，增强数据的安全性。 六、 结束语
数据库的高效运行不仅需要技术上的支持，也需要硬件平台和网络的支持以及数据库管理员的有效管理，本文只是从技术的角度说明如何提高数据库的效率，但在实际应用过程中其它方面的支持也是不可缺少的，尤其是数据库管理，数据库建设是“三分技术，七分管理，十二分基础数据”，因此对于数据库管理一定要重视，在管理到位的情况下技术才能发挥应有的作用。

⑷ 论坛的数据库怎么设计

常用的论坛设计方法，总结如下：
一 分割思想：
1 数据库切分：用户库、主题库、回复库
2 数据表水平切分：用户库1-n、主题库1-n、回复库1-n （比如按时间分）
3 分布式数据库：每台计算机中都有DBMS的一份完整拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的大型数据库。
4 论坛功能可以进行分隔，不同的服务器负责不同的功能
5 用主从数据库，master是写， slave是读
6 把内容与其它信息分开，好处就是可以让每个表的文件最小化,对数据库操作压力会减小，这样保证每张表数据量很小，操作速度会快，也可以在这里使用缓存
二 索引：
针对是否建立索引有着一定的分歧：
我觉得建立索引还是很有必要的。理由如下：
1）建立索引可以加快检索速度，对于论坛读和写的比例相差很大，用户体验当然是读多写少，所以综合考虑还是要用索引，而且是加在常用的读关键字上。
2）索引之所以会降低更新的速度，是因为更新还包括对索引的更新，从更新帖子10万左右，这句话是说，我们可能对发帖标题，发帖内容，回复标题，回复内容这4个字段做更新。需要注意的是，这四个字段并不是用来建立表连接的字段，为了优化查询速度我们不会在这四个字段上建立索引，所以从这道题目出发，我们建立的索引不会影响更新帖子的性能。只要被索引的列（例如回复表的标题ID）不被频繁更新,即使索引所在地行的其它列被频繁update,索引也不会被更新从而产生性能消耗,一张表一天30万次的索引更新,因它引起的性能消耗小到即使数据库安装在奔腾3单核CPU下都能轻松承担下来。
3）对于更新的速度慢的问题，我们有解决的方法，你提交更新了后，前台可以让程序返回一个正确结果，后台开个线程异步慢慢跟新数据库就是了，反正更新成功的前提就是假设数据库连接永远正确并处于可靠状态。在数据库和用户之间建立一个缓冲区。(如，将更新的数据放到内存中，达到一定数量的时候再统一更新数据库。假如以100条为例，一旦内存中达到100条数据量将这100条数据统一入库。减少insert操作)

三 缓冲：
读的时候的缓冲：缓存路由表
主题缓存表（这个取每个区的前面100条记录），一般来说负载最大的就是主题的第一页，所以缓存表是个小表。

另外使用hibernate，在数据库上面加了一层缓存。
生成静态页，缓存最热，最新的帖子。
对于经常更新的数据都设计成单独表 ，这样可以最大程度的利用hibernate缓存
缓存常用的数据和表，利用缓存来将经常被访问的帖子留在内存中，为每条缓存的记录添加一个访问时间，如果长时间没被访问就从缓存中删除掉，
避免内存过大，每次用户看帖的时候，首先检索缓存中时候有需要的帖子，没有的话再访问数据库，然后将数据库返回的帖子信息存储到缓存中。

写的时候的缓冲：数据库和用户之间建立缓存，将更新的数据放在内存中，异步操作的。所有的写贴操作 放到一个队列然后批量执行插入数据库操作。

预估计的缓冲：假如用户第一次打开某标题，那将此标题的相关的前100条数据缓存到客户断。这样避开对数据库的直接查询，减少数据库压力。
四 代码优化
1尽量避免表的连接约束通过代码来实现约束 例如用户id的验证在用户登录时验证这样就可以把帖子表的用户id外键去掉这样就成了单表操作、查询 而连接可以通过触发来实现这样最多是查询了3个表而不是连接中的笛卡尔笛卡尔积 回复表的查询限定每次查询的记录数例如限定10条其它的通过点击触发来操作"注代码优化容易出现bug 原因有些开发工具本身有优化"
五 数据库性能调优
尽量用硬件来代替软件优化 原则就是能用硬件的尽量用硬件 比如磁盘阵列 RAID0 有条件用RAID10 加大内存 .避免小表上建索引 对论坛来说数据帖子和回复不是很重要 可以定期删除一些垃圾帖子 楼主说的几百万条记录的论坛对现在的数据库管理系统和计算机来说永不着刻意的优化,定期维护打包备份数据库就可以了
提高速度的关键:
1.建立合理的索引并在查询时充分利用;
2.避免使用关联,这样避免整表扫描;使用关联不如多次使用主键查询来的快;
3.一些处理的功能尽可能放到内存中来做,比如组织主题和回复;
4.海量缓存（使用静态页面也是个不错的做法）
5 定期对表进行转储

⑸ 请简要的叙述一下数据库的主要设计过程

一、数据库设计过程

数据库技术是信息资源管理最有效的手段。

数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。

数据库设计的各阶段：

A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。

B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。

C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。

D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

1. 需求分析阶段

需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。

需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。

常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。

分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。

数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。

2. 概念结构设计阶段

通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。

概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。

概念模型特点：

(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。

(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。

概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2.1 第零步——初始化工程

这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。

2.2 第一步——定义实体

实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有 “代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。

2.3 第二步——定义联系

IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。

2.4 第三步——定义码

通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。

2.5 第四步——定义属性

从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。

2.6 第五步——定义其他对象和规则

定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。

3. 逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。

将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。

数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：

表内的每一个值都只能被表达一次。

表内的每一行都应该被唯一的标识(有唯一键)。

表内不应该存储依赖于其他键的非键信息。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

4. 数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

5. 数据库实施阶段

运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 ，(Data Definition Language(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)

●Create (新增有关数据库结构的东西，属DDL)

●Drop (删除有关数据库结构的东西，属DDL)

●Alter (更改结构，属DDL)

6. 数据库运行和维护阶段

在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

7. 建模工具的使用

为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。

ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用 ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。

设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。

二、数据库设计技巧

1. 设计数据库之前(需求分析阶段)

1) 理解客户需求，包括用户未来需求变化。

2) 了解企业业务类型，可以在开发阶段节约大量的时间。

3) 重视输入(要记录的数据)、输出(报表、查询、视图)。

4) 创建数据字典和ER 图表

数据字典(Data Dictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。

数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系

数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构]

数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结构]，平均流量，高峰期流量

数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式

处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]

ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2. 表和字段的设计(数据库逻辑设计)

表设计原则

1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。

2) 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。

举例，假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

4) 表名、报表名和查询名的命名规范

(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。用 sp_company 标识存储过程，用 udf_ (或者类似的标记)标识自定义编写的函数。

字段设计原则：

1) 每个表中都应该添加的3 个有用的字段。

dRecordCreationDate，在SQL Server 下默认为GETDATE()

sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER

nRecordVersion，记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。

2) 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

3) 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名

对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用 _N 后缀;字符类型：_C 后缀;日期类型：_D 后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

假设有两个表：

Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、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 个表乃至更多的列[字段]你就知道这个技巧多有用了。

5) 选择数字类型和文本类型的长度应尽量充足

假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

6) 增加删除标记字段

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。

7) 提防大小写混用的对象名和特殊字符

采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。

8) 小心保留词

要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用 DESC 作为说明字段名。后果可想而知!DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用，但得到的却是一大堆毫无用处的信息。

9) 保持字段名和类型的一致性

在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，就别在表2里把名字改成 “ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID，则为了可读性，在表2做关联时可以命名为 ABC_ID。

10) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

3. 选择键和索引(数据库逻辑设计)

参考：《SQL优化-索引》一文

4. 数据完整性设计(数据库逻辑设计)

1) 完整性实现机制：

实体完整性：主键

参照完整性：

父表中删除数据：级联删除;受限删除;置空值

父表中插入数据：受限插入;递归插入

父表中更新数据：级联更新;受限更新;置空值

DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：

NOT NULL;CHECK;触发器

2) 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键) 的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。

3) 强制指示完整性

在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

4) 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

5) 采用视图

为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

6) 分布式数据系统

对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记，在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。

7) 关系

如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。

8) 给数据保有和恢复制定计划

考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。

9) 用存储过程让系统做重活

提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

5. 其他设计技巧

1) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

2) 使用常用英语(或者其他任何语言)而不要使用编码

在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。

3) 保存常用信息

让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

4) 包含版本机制

在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

5) 编制文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列、触发器等加注释的 数据库工具。对开发、支持和跟踪修改非常有用。

对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。

6) 测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

7) 检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

三、数据库命名规范

1. 实体(表)的命名

1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4 个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推)

对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

举例：

定义的缩写 Sales: Sal 销售;

Order: Ord 订单;

Detail: Dtl 明细;

则销售订单明细表命名为：Sal_Ord_Dtl;

2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。

举例：

定义的缩写 Material Ma 物品;

物品表名为：Material, 而不是 Ma.

但是字段物品编码则是：Ma_ID;而不是Material_ID

3) 所有的存储值列表的表前面加上前缀Z

目的是将这些值列表类排序在数据库最后。

4) 所有的冗余类的命名(主要是累计表)前面加上前缀X

冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表

5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。

关联表用于保存多对多关系。

如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。

举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object;

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2. 属性(列)的命名

1) 采用有意义的列名

表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;

A、如果是数据库自动生成的编码，统一命名为：ID

B、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名，即“XXXX_ID”

C、如果键是数字类型，你可以用_NO 作为后缀;

D、如果是字符类型则可以采用_CODE 后缀

E、对列名应该采用标准的前缀和后缀。

举例：销售订单的编号字段命名：Sal_Ord_ID;如果还存在一个数据库生成的自动编号，则命名为：ID。

2) 所有的属性加上有关类型的后缀

注意，如果还需要其它的后缀，都放在类型后缀之前。

注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。

3) 采用前缀命名

给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。

3. 视图的命名

1) 视图以V作为前缀，其他命名规则和表的命名类似;

2) 命名应尽量体现各视图的功能。

4. 触发器的命名(尽量不使用)

触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。

5. 存储过程名

存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。

6. 变量名

变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。

7. 命名中其他注意事项

1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。

2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。

3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突

4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。

⑹ 试述数据库完整的设计过程

数据库设计的过程(六个阶段)
1.需求分析阶段
准确了解与分析用户需求（包括数据与处理）
是整个设计过程的基础，是最困难、最耗费时间的一步
2.概念结构设计阶段
是整个数据库设计的关键
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
3.逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型
对其进行优化
4.数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
5.数据库实施阶段
运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果
建立数据库，编制与调试应用程序，组织数据入库，并进行试运行
6.数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改
设计特点:
在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

⑺ 濡备綍璁捐′竴涓浼樼镄勬暟鎹搴

鏁版嵁搴撹捐(Database Design)鏄鎸囧逛簬涓涓缁椤畾镄勫簲鐢ㄧ幆澧冿纴鏋勯犳渶浼樼殑鏁版嵁搴撴ā寮忥纴寤虹珛鏁版嵁搴揿强鍏跺簲鐢ㄧ郴缁燂纴浣夸箣鑳藉熸湁鏁埚湴瀛桦偍鏁版嵁锛屾弧瓒冲悇绉岖敤鎴风殑搴旂敤闇姹傦纸淇℃伅瑕佹眰鍜屽勭悊瑕佹眰锛夈 鍦ㄦ暟鎹搴挞嗗烟鍐咃纴甯稿父鎶娄娇鐢ㄦ暟鎹搴撶殑钖勭被绯荤粺缁熺О涓烘暟鎹搴撴暟鎹搴撹捐(database design)鏄鎸囧逛簬涓涓缁椤畾镄勫簲鐢ㄧ幆澧冿纴鏋勯犳渶浼樼殑鏁版嵁搴撴ā寮忥纴寤虹珛鏁版嵁搴揿强鍏跺簲鐢ㄧ郴缁燂纴浣夸箣鑳藉熸湁鏁埚湴瀛桦偍鏁版嵁锛屾弧瓒冲悇绉岖敤鎴风殑搴旂敤闇姹傦纸淇℃伅瑕佹眰鍜屽勭悊瑕佹眰锛夈 鍦ㄦ暟鎹搴挞嗗烟鍐咃纴甯稿父鎶娄娇鐢ㄦ暟鎹搴撶殑钖勭被绯荤粺缁熺О涓烘暟鎹搴揿簲鐢ㄧ郴缁熴 涓銆佹暟鎹搴揿拰淇℃伅绯荤粺 (1)鏁版嵁搴撴槸淇℃伅绯荤粺镄勬牳蹇冨拰锘虹锛屾妸淇℃伅绯荤粺涓澶ч噺镄勬暟鎹鎸変竴瀹氱殑妯″瀷缁勭粐璧锋潵锛屾彁渚涘瓨鍌ㄣ佺淮鎶ゃ佹绱㈡暟鎹镄 锷熻兘锛屼娇淇℃伅绯荤粺鍙浠ユ柟渚裤佸强镞躲佸嗳纭鍦颁粠鏁版嵁搴扑腑銮峰缑镓闇镄勪俊鎭銆 (2)鏁版嵁搴撴槸淇℃伅绯荤粺镄勫悇涓閮ㄥ垎鑳藉惁绱у瘑鍦扮粨钖埚湪涓璧蜂互鍙婂备綍缁揿悎镄勫叧阌镓鍦ㄣ (3)鏁版嵁搴撹捐℃槸淇℃伅绯荤粺寮鍙戝拰寤鸿剧殑閲嶈佺粍鎴愰儴鍒嗐 (4)鏁版嵁搴撹捐′汉锻桦簲璇ュ叿澶囩殑鎶链鍜岀煡璇嗭细 鏁版嵁搴撶殑锘烘湰鐭ヨ瘑鍜屾暟鎹搴撹捐℃妧链 璁＄畻链虹戝︾殑锘虹鐭ヨ瘑鍜岀▼搴忚捐＄殑鏂规硶鍜屾妧宸 杞浠跺伐绋嬬殑铡熺悊鍜屾柟娉 搴旂敤棰嗗烟镄勭煡璇 浜屻佹暟鎹搴撹捐＄殑鐗圭偣 鏁版嵁搴揿缓璁炬槸纭浠躲佽蒋浠跺拰骞蹭欢镄勭粨钖 涓夊垎鎶链锛屼竷鍒嗙＄悊锛屽崄浜屽垎锘虹鏁版嵁 鎶链涓庣＄悊镄勭晫闱㈢О涔嬩负钬滃共浠垛 鏁版嵁搴撹捐″簲璇ヤ笌搴旂敤绯荤粺璁捐＄浉缁揿悎 缁撴瀯锛堟暟鎹锛夎捐★细璁捐℃暟鎹搴撴嗘灦鎴栨暟鎹搴撶粨鏋 琛屼负锛埚勭悊锛夎捐★细璁捐″簲鐢ㄧ▼搴忋佷簨锷″勭悊绛 缁撴瀯鍜岃屼负鍒嗙荤殑璁捐 浼犵粺镄勮蒋浠跺伐绋嫔拷瑙嗗瑰簲鐢ㄤ腑鏁版嵁璇涔夌殑鍒嗘瀽鍜屾娊璞★纴鍙瑕佹湁鍙鑳藉氨灏介噺鎺ㄨ繜鏁版嵁缁撴瀯璁捐＄殑鍐崇瓥镞╂湡镄勬暟鎹搴撹捐¤嚧锷涗簬鏁版嵁妯″瀷鍜屽缓妯℃柟娉旷爷绌讹纴蹇借嗕简瀵硅屼负镄勮捐 濡傚浘锛 涓夈佹暟鎹搴撹捐℃柟娉旷亩杩 镓嫔伐璇曞噾娉 璁捐¤川閲忎笌璁捐′汉锻樼殑缁忛獙鍜屾按骞虫湁鐩存帴鍏崇郴 缂轰箯绉戝︾悊璁哄拰宸ョ▼鏂规硶镄勬敮鎸侊纴宸ョ▼镄勮川閲忛毦浠ヤ缭璇 鏁版嵁搴撹繍琛屼竴娈垫椂闂村悗甯稿父鍙堜笉钖岀▼搴﹀湴鍙戠幇钖勭嶉梾棰桡纴澧炲姞浜嗙淮鎶や唬浠 瑙勮寖璁捐℃硶 镓嫔伐璁捐℃柟 锘烘湰镐濇兂 杩囩▼杩浠ｅ拰阃愭ユ眰绮 瑙勮寖璁捐℃硶(缁) 鍏稿瀷鏂规硶锛 (1)鏂板ゥ灏旇坛锛坣ew orleans锛夋柟娉曪细灏嗘暟鎹搴撹捐″垎涓哄洓涓阒舵 s.b.yao鏂规硶锛氩皢鏁版嵁搴撹捐″垎涓轰簲涓姝ラ i.r.palmer鏂规硶锛氭妸鏁版嵁搴撹捐″綋鎴愪竴姝ユ帴涓姝ョ殑杩囩▼ (2)璁＄畻链鸿緟锷╄捐 oracle designer 2000 sybase powerdesigner 锲涖佹暟鎹搴撹捐＄殑锘烘湰姝ラ 鏁版嵁搴撹捐＄殑杩囩▼(鍏涓阒舵) 1.闇姹傚垎鏋愰桩娈 鍑嗙‘浜呜В涓庡垎鏋愮敤鎴烽渶姹傦纸鍖呮嫭鏁版嵁涓庡勭悊锛 鏄鏁翠釜璁捐¤繃绋嬬殑锘虹锛屾槸链锲伴毦銆佹渶钥楄垂镞堕棿镄勪竴姝 2.姒傚康缁撴瀯璁捐￠桩娈 鏄鏁翠釜鏁版嵁搴撹捐＄殑鍏抽敭 阃氲繃瀵圭敤鎴烽渶姹傝繘琛岀患钖堛佸綊绾充笌鎶借薄锛屽舰鎴愪竴涓镫绔嬩簬鍏蜂綋dbms镄勬傚康妯″瀷 3.阃昏緫缁撴瀯璁捐￠桩娈 灏嗘傚康缁撴瀯杞鎹涓烘煇涓猟bms镓鏀鎸佺殑鏁版嵁妯″瀷 瀵瑰叾杩涜屼紭鍖 4.鏁版嵁搴撶墿鐞呜捐￠桩娈 涓洪昏緫鏁版嵁妯″瀷阃夊彇涓涓链阃傚悎搴旂敤鐜澧幂殑鐗╃悊缁撴瀯锛埚寘𨰾瀛桦偍缁撴瀯鍜屽瓨鍙栨柟娉曪级 5.鏁版嵁搴揿疄鏂介桩娈 杩愮敤dbms鎻愪緵镄勬暟鎹璇瑷銆佸伐鍏峰强瀹夸富璇瑷锛屾牴鎹阃昏緫璁捐″拰鐗╃悊璁捐＄殑缁撴灉 寤虹珛鏁版嵁搴掳纴缂栧埗涓庤皟璇曞簲鐢ㄧ▼搴忥纴缁勭粐鏁版嵁鍏ュ簱锛屽苟杩涜岃瘯杩愯 6.鏁版嵁搴撹繍琛屽拰缁存姢阒舵 鏁版嵁搴揿簲鐢ㄧ郴缁熺粡杩囱瘯杩愯屽悗鍗冲彲鎶曞叆姝ｅ纺杩愯屻 鍦ㄦ暟鎹搴撶郴缁熻繍琛岃繃绋嬩腑蹇呴’涓嶆柇鍦板瑰叾杩涜岃瘎浠枫佽皟鏁翠笌淇鏀 璁捐＄壒镣: 鍦ㄨ捐¤繃绋嬩腑鎶婃暟鎹搴撶殑璁捐″拰瀵规暟鎹搴扑腑鏁版嵁澶勭悊镄勮捐＄揣瀵嗙粨钖堣捣𨱒ュ皢杩欎袱涓鏂归溃镄勯渶姹傚垎鏋愩佹娊璞°佽捐°佸疄鐜板湪钖勪釜阒舵靛悓镞惰繘琛岋纴鐩镐簰鍙傜収锛岀浉浜掕ˉ鍏咃纴浠ュ畬锽勪袱鏂归溃镄勮捐 璁捐¤繃绋嫔悇涓阒舵电殑璁捐℃弿杩帮细 濡傚浘锛 浜斻佹暟鎹搴揿悇绾фā寮忕殑褰㈡垚杩囩▼ 1.闇姹傚垎鏋愰桩娈碉细缁煎悎钖勪釜鐢ㄦ埛镄勫簲鐢ㄩ渶姹 2.姒傚康璁捐￠桩娈碉细褰㈡垚镫绔嬩簬链哄櫒鐗圭偣锛岀嫭绔嬩簬钖勪釜dbms浜у搧镄勬傚康妯″纺(e-r锲) 3.阃昏緫璁捐￠桩娈碉细棣栧厛灏唀-r锲捐浆鎹㈡垚鍏蜂綋镄勬暟鎹搴扑骇鍝佹敮鎸佺殑鏁版嵁妯″瀷锛屽傚叧绯绘ā鍨嬶纴褰㈡垚鏁版嵁搴挞昏緫妯″纺锛涚劧钖庢牴鎹鐢ㄦ埛澶勭悊镄勮佹眰銆佸畨鍏ㄦх殑钥冭槛锛屽湪锘烘湰琛ㄧ殑锘虹涓婂啀寤虹珛蹇呰佺殑瑙嗗浘(view)锛屽舰鎴愭暟鎹镄勫栨ā寮 4.鐗╃悊璁捐￠桩娈碉细镙规嵁dbms鐗圭偣鍜屽勭悊镄勯渶瑕侊纴杩涜岀墿鐞嗗瓨鍌ㄥ畨鎺掞纴寤虹珛绱㈠紩锛屽舰鎴愭暟鎹搴揿唴妯″纺 鍏銆佹暟鎹搴撹捐℃妧宸 1. 璁捐℃暟鎹搴扑箣鍓嶏纸闇姹傚垎鏋愰桩娈碉级 1) 鐞呜В瀹㈡埛闇姹傦纴璇㈤梾鐢ㄦ埛濡备綍鐪嫔緟链𨱒ラ渶姹傚彉鍖栥傝╁㈡埛瑙ｉ喷鍏堕渶姹傦纴钥屼笖闅忕潃寮鍙戠殑缁х画锛岃缮瑕佺粡甯歌㈤梾瀹㈡埛淇濊瘉鍏堕渶姹备粛铹跺湪寮鍙戠殑鐩镄勪箣涓銆 2) 浜呜В浼佷笟涓氩姟鍙浠ュ湪浠ュ悗镄勫紑鍙戦桩娈佃妭绾﹀ぇ閲忕殑镞堕棿銆 3) 閲嶈呜緭鍏ヨ緭鍑恒 鍦ㄥ畾涔夋暟鎹搴撹〃鍜屽瓧娈甸渶姹傦纸杈揿叆锛夋椂锛岄栧厛搴旀镆ョ幇链夌殑鎴栬呭凡缁忚捐″嚭镄勬姤琛ㄣ佹煡璇㈠拰瑙嗗浘锛堣緭鍑猴级浠ュ喅瀹氢负浜嗘敮鎸佽繖浜涜緭鍑哄摢浜涙槸蹇呰佺殑琛ㄥ拰瀛楁点 涓句緥锛氩亣濡傚㈡埛闇瑕佷竴涓鎶ヨ〃鎸夌収闾鏀跨紪镰佹帓搴忋佸垎娈靛拰姹傚拰锛屼綘瑕佷缭璇佸叾涓鍖呮嫭浜嗗崟镫镄勯偖鏀跨紪镰佸瓧娈佃屼笉瑕佹妸闾鏀跨紪镰佺硡杩涘湴鍧瀛楁甸噷銆 4) 鍒涘缓鏁版嵁瀛楀吀鍜宔r 锲捐〃 er 锲捐〃鍜屾暟鎹瀛楀吀鍙浠ヨ╀换浣曚简瑙ｆ暟鎹搴撶殑浜洪兘鏄庣‘濡备綍浠庢暟鎹搴扑腑銮峰缑鏁版嵁銆俥r锲惧硅〃鏄庤〃涔嬮棿鍏崇郴寰堟湁鐢锛岃屾暟鎹瀛楀吀鍒栾存槑浜嗘疮涓瀛楁电殑鐢ㄩ斾互鍙娄换浣曞彲鑳藉瓨鍦ㄧ殑鍒钖嶃傚箂ql 琛ㄨ揪寮忕殑鏂囨。鍖栨潵璇磋繖鏄瀹屽叏蹇呰佺殑銆 5) 瀹氢箟镙囧嗳镄勫硅薄锻藉悕瑙勮寖 鏁版嵁搴揿悇绉嶅硅薄镄勫懡钖嶅繀椤昏勮寖銆 2. 琛ㄥ拰瀛楁电殑璁捐★纸鏁版嵁搴挞昏緫璁捐★级 琛ㄨ捐″师鍒 1) 镙囧嗳鍖栧拰瑙勮寖鍖 鏁版嵁镄勬爣鍑嗗寲链夊姪浜庢秷闄ゆ暟鎹搴扑腑镄勬暟鎹鍐椾綑銆傛爣鍑嗗寲链夊ソ鍑犵嶅舰寮忥纴浣唗hird normal form锛3nf锛夐氩父琚璁や负鍦ㄦц兘銆佹墿灞曟у拰鏁版嵁瀹屾暣镐ф柟闱㈣揪鍒颁简链濂藉钩琛°傜亩鍗曟潵璇达纴阆靛畧3nf 镙囧嗳镄勬暟鎹搴撶殑琛ㄨ捐″师鍒欐槸锛气涣ne fact in one place钬濆嵆镆愪釜琛ㄥ彧鍖呮嫭鍏舵湰韬锘烘湰镄勫睘镐э纴褰扑笉鏄瀹冧滑链韬镓鍏锋湁镄勫睘镐ф椂闇杩涜屽垎瑙ｃ傝〃涔嬮棿镄勫叧绯婚氲繃澶栭敭鐩歌繛鎺ャ傚畠鍏锋湁浠ヤ笅鐗圭偣锛氭湁涓缁勮〃涓挞棬瀛樻斁阃氲繃阌杩炴帴璧锋潵镄勫叧镵旀暟鎹銆 涓句緥锛氭煇涓瀛樻斁瀹㈡埛鍙婂叾链夊叧瀹氩崟镄3nf 鏁版嵁搴揿氨鍙鑳芥湁涓や釜琛锛歝ustomer 鍜宱rder銆俹rder 琛ㄤ笉鍖呭惈瀹氩崟鍏宠仈瀹㈡埛镄勪换浣曚俊鎭锛屼絾琛ㄥ唴浼氩瓨鏀句竴涓阌鍊硷纴璇ラ敭鎸囧悜customer 琛ㄩ噷鍖呭惈璇ュ㈡埛淇℃伅镄勯偅涓琛屻 浜嫔疄涓婏纴涓轰简鏁堢巼镄勭紭鏁咃纴瀵硅〃涓嶈繘琛屾爣鍑嗗寲链夋椂涔熸槸蹇呰佺殑銆 2) 鏁版嵁椹卞姩 閲囩敤鏁版嵁椹卞姩钥岄潪纭缂栫爜镄勬柟寮忥纴璁稿氱瓥鐣ュ彉镟村拰缁存姢閮戒细鏂逛究寰楀氾纴澶уぇ澧炲己绯荤粺镄勭伒娲绘у拰镓╁𪾢镐с 涓句緥锛屽亣濡傜敤鎴风晫闱㈣佽块梾澶栭儴鏁版嵁婧愶纸鏂囦欢銆亁ml 鏂囨。銆佸叾浠栨暟鎹搴撶瓑锛夛纴涓嶅Θ鎶婄浉搴旂殑杩炴帴鍜岃矾寰勪俊鎭瀛桦偍鍦ㄧ敤鎴风晫闱㈡敮鎸佽〃閲屻傝缮链夛纴濡傛灉鐢ㄦ埛鐣岄溃镓ц屽伐浣沧祦涔嬬被镄勪换锷★纸鍙戦侀偖浠躲佹墦鍗颁俊绗恒佷慨鏀硅板綍鐘舵佺瓑锛夛纴闾ｄ箞浜х敓宸ヤ綔娴佺殑鏁版嵁涔熷彲浠ュ瓨鏀惧湪鏁版嵁搴挞噷銆傝掕壊𨱒冮檺绠＄悊涔熷彲浠ラ氲繃鏁版嵁椹卞姩𨱒ュ畬鎴愩备簨瀹炰笂锛屽傛灉杩囩▼鏄鏁版嵁椹卞姩镄勶纴浣犲氨鍙浠ユ妸鐩稿綋澶х殑璐ｄ换鎺ㄧ粰鐢ㄦ埛锛岀敱鐢ㄦ埛𨱒ョ淮鎶よ嚜宸辩殑宸ヤ綔娴佽繃绋嬨 3) 钥冭槛钖勭嶅彉鍖 鍦ㄨ捐℃暟鎹搴撶殑镞跺栾冭槛鍒板摢浜涙暟鎹瀛楁靛皢𨱒ュ彲鑳戒细鍙戠敓鍙樻洿銆 涓句緥锛屽撴皬灏辨槸濡傛わ纸娉ㄦ剰鏄瑗挎柟浜虹殑濮撴皬锛屾瘆濡傚コ镐х粨濠氩悗浠庡か濮撶瓑锛夈傛墍浠ワ纴鍦ㄥ缓绔嬬郴缁熷瓨鍌ㄥ㈡埛淇℃伅镞讹纴鍦ㄥ崟镫镄勪竴涓鏁版嵁琛ㄩ噷瀛桦偍濮撴皬瀛楁碉纴钥屼笖杩橀梼锷犺捣濮嬫棩鍜岀粓姝㈡棩绛夊瓧娈碉纴杩欐牱灏卞彲浠ヨ窡韪杩欎竴鏁版嵁𨱒＄洰镄勫彉鍖栥 瀛楁佃捐″师鍒 4) 姣忎釜琛ㄤ腑閮藉簲璇ユ坊锷犵殑3 涓链夌敤镄勫瓧娈 drecordcreationdate锛屽湪vb 涓嬮粯璁ゆ槸now()锛岃屽湪sql server ? 涓嬮粯璁や负getdate() srecordcreator锛屽湪sql server 涓嬮粯璁や负not null default ? user nrecordversion锛岃板綍镄勭増链镙囱帮绂链夊姪浜庡嗳纭璇存槑璁板綍涓鍑虹幇null 鏁版嵁鎴栬呬涪澶辨暟鎹镄勫师锲 ? 5) 瀵瑰湴鍧鍜岀数璇濋噰鐢ㄥ氢釜瀛楁 鎻忚堪琛楅亾鍦板潃灏辩煭鐭涓琛岃板綍鏄涓嶅熺殑銆俛ddress_line1銆乤ddress_line2 鍜宎ddress_line3 鍙浠ユ彁渚涙洿澶х殑𨱔垫椿镐с傝缮链夛纴鐢佃瘽鍙风爜鍜岄偖浠跺湴鍧链濂芥嫢链夎嚜宸辩殑鏁版嵁琛锛屽叾闂村叿链夎嚜韬镄勭被鍨嫔拰镙囱扮被鍒銆 6) 浣跨敤瑙掕壊瀹炰綋瀹氢箟灞炰簬镆愮被鍒镄勫垪 鍦ㄩ渶瑕佸瑰睘浜庣壒瀹氱被鍒鎴栬呭叿链夌壒瀹氲掕壊镄勪簨鐗╁仛瀹氢箟镞讹纴鍙浠ョ敤瑙掕壊瀹炰綋𨱒ュ垱寤虹壒瀹氱殑镞堕棿鍏宠仈鍏崇郴锛屼粠钥屽彲浠ュ疄鐜拌嚜鎴戞枃妗ｅ寲銆 涓句緥锛氱敤person 瀹炰綋鍜宲erson_type 瀹炰綋𨱒ユ弿杩颁汉锻樸傛瘆鏂硅达纴褰搄ohn smith, engineer 鎻愬崌涓箦ohn smith, director 涔冭呖链钖庣埇鍒癹ohn smith, cio 镄勯珮浣嶏纴钥屾墍链変綘瑕佸仛镄勪笉杩囨槸鏀瑰彉涓や釜琛╬erson 鍜宲erson_type 涔嬮棿鍏崇郴镄勯敭鍊硷纴钖屾椂澧炲姞涓涓镞ユ湡/镞堕棿瀛楁垫潵鐭ラ亾鍙桦寲鏄浣曟椂鍙戠敓镄勚傝繖镙凤纴浣犵殑person_type 琛ㄥ氨鍖呭惈浜嗘墍链塸erson 镄勫彲鑳界被鍨嬶纴姣斿俛ssociate銆乪ngineer銆乨irector銆乧io 鎴栬卌eo 绛夈傝缮链変釜镟夸唬锷炴硶灏辨槸鏀瑰彉person 璁板綍𨱒ュ弽鏄犳柊澶磋旂殑鍙桦寲锛屼笉杩囱繖镙蜂竴𨱒ュ湪镞堕棿涓婃棤娉曡窡韪涓浜烘墍澶勪綅缃镄勫叿浣撴椂闂淬 7) 阃夋嫨鏁板瓧绫诲瀷鍜屾枃链绫诲瀷灏介噺鍏呰冻 鍦╯ql 涓浣跨敤smallint 鍜宼inyint 绫诲瀷瑕佺壒鍒灏忓绩銆傛瘆濡傦纴锅囧傛兂鐪嬬湅链堥攒鍞镐婚濓纴镐婚濆瓧娈电被鍨嬫槸smallint锛岄偅涔堬纴濡傛灉镐婚濊秴杩囦简$32,767 灏变笉鑳借繘琛岃＄畻镎崭綔浜嗐 钥宨d 绫诲瀷镄勬枃链瀛楁碉纴姣斿傚㈡埛id 鎴栧畾鍗曞彿绛夌瓑閮藉簲璇ヨ剧疆寰楁瘆涓鑸𨱍宠薄镟村ぇ銆傚亣璁惧㈡埛id 涓10 浣嶆暟闀裤傞偅浣犲簲璇ユ妸鏁版嵁搴撹〃瀛楁电殑闀垮害璁句负12 鎴栬13 涓瀛楃﹂暱銆备絾杩欓濆栧崰鎹镄勭┖闂村嵈镞犻渶灏嗘潵閲嶆瀯鏁翠釜鏁版嵁搴揿氨鍙浠ュ疄鐜版暟鎹搴撹勬ā镄勫为暱浜嗐 8) 澧炲姞鍒犻櫎镙囱板瓧娈 鍦ㄨ〃涓鍖呭惈涓涓钬滃垹闄ゆ爣璁扳濆瓧娈碉纴杩欐牱灏卞彲浠ユ妸琛屾爣璁颁负鍒犻櫎銆傚湪鍏崇郴鏁版嵁搴挞噷涓嶈佸崟镫鍒犻櫎镆愪竴琛岋绂链濂介噰鐢ㄦ竻闄ゆ暟鎹绋嫔簭钥屼笖瑕佷粩缁嗙淮鎶ょ储寮曟暣浣撴с 3. 阃夋嫨阌鍜岀储寮曪纸鏁版嵁搴挞昏緫璁捐★级 阌阃夋嫨铡熷垯锛 1) 阌璁捐4 铡熷垯 涓哄叧镵斿瓧娈靛垱寤哄栭敭銆 ? 镓链夌殑阌閮藉繀椤诲敮涓銆 ? 阆垮厤浣跨敤澶嶅悎阌銆 ? 澶栭敭镐绘槸鍏宠仈鍞涓镄勯敭瀛楁点 ? 2) 浣跨敤绯荤粺鐢熸垚镄勪富阌 璁捐℃暟鎹搴撶殑镞跺欓噰鐢ㄧ郴缁熺敓鎴愮殑阌浣滀负涓婚敭锛岄偅涔埚疄闄呮带鍒朵简鏁版嵁搴撶殑绱㈠紩瀹屾暣镐с傝繖镙凤纴鏁版嵁搴揿拰闱炰汉宸ユ満鍒跺氨链夋晥鍦版带鍒朵简瀵瑰瓨鍌ㄦ暟鎹涓姣忎竴琛岀殑璁块梾銆傞噰鐢ㄧ郴缁熺敓鎴愰敭浣滀负涓婚敭杩樻湁涓涓浼樼偣锛氩綋𨰾ユ湁涓镊寸殑阌缁撴瀯镞讹纴镓惧埌阃昏緫缂洪櫡寰埚规槗銆 3) 涓嶈佺敤鐢ㄦ埛镄勯敭(涓嶈╀富阌鍏锋湁鍙镟存柊镐) 鍦ㄧ‘瀹氶噰鐢ㄤ粈涔埚瓧娈典綔涓鸿〃镄勯敭镄勬椂鍊欙纴鍙涓瀹氲佸皬蹇幂敤鎴峰皢瑕佺紪杈戠殑瀛楁点傞氩父镄勬儏鍐典笅涓嶈侀夋嫨鐢ㄦ埛鍙缂栬緫镄勫瓧娈典綔涓洪敭銆 4) 鍙阃夐敭链夋椂鍙锅氢富阌 鎶婂彲阃夐敭杩涗竴姝ョ敤锅氢富阌锛屽彲浠ユ嫢链夊缓绔嫔己澶х储寮旷殑鑳藉姏銆 绱㈠紩浣跨敤铡熷垯锛 绱㈠紩鏄浠庢暟鎹搴扑腑銮峰彇鏁版嵁镄勬渶楂樻晥鏂瑰纺涔嬩竴銆95%镄勬暟鎹搴撴ц兘闂棰橀兘鍙浠ラ噰鐢ㄧ储寮曟妧链寰楀埌瑙ｅ喅銆 1) 阃昏緫涓婚敭浣跨敤鍞涓镄勬垚缁勭储寮曪纴瀵圭郴缁熼敭锛堜綔涓哄瓨鍌ㄨ繃绋嬶级閲囩敤鍞涓镄勯潪鎴愮粍绱㈠紩锛屽逛换浣曞栭敭鍒楅噰鐢ㄩ潪鎴愮粍绱㈠紩銆傝冭槛鏁版嵁搴撶殑绌洪棿链夊氩ぇ锛岃〃濡备綍杩涜岃块梾锛岃缮链夎繖浜涜块梾鏄钖︿富瑕佺敤浣滆诲啓銆 2) 澶у氭暟鏁版嵁搴挞兘绱㈠紩镊锷ㄥ垱寤虹殑涓婚敭瀛楁碉纴浣嗘槸鍙鍒蹇树简绱㈠紩澶栭敭锛屽畠浠涔熸槸缁忓父浣跨敤镄勯敭锛屾瘆濡傝繍琛屾煡璇㈡樉绀轰富琛ㄥ拰镓链夊叧镵旇〃镄勬煇𨱒¤板綍灏辩敤寰椾笂銆 3) 涓嶈佺储寮昺emo/note 瀛楁碉纴涓嶈佺储寮曞ぇ鍨嫔瓧娈碉纸链夊緢澶氩瓧绗︼级锛岃繖镙蜂綔浼氲╃储寮曞崰鐢ㄥお澶氱殑瀛桦偍绌洪棿銆 4) 涓嶈佺储寮曞父鐢ㄧ殑灏忓瀷琛 涓嶈佷负灏忓瀷鏁版嵁琛ㄨ剧疆浠讳綍阌锛屽亣濡傚畠浠缁忓父链夋彃鍏ュ拰鍒犻櫎镎崭綔灏辨洿鍒杩欐牱浣滀简銆傚硅繖浜涙彃鍏ュ拰鍒犻櫎镎崭綔镄勭储寮旷淮鎶ゅ彲鑳芥瘆镓鎻忚〃绌洪棿娑堣楁洿澶氱殑镞堕棿銆 4. 鏁版嵁瀹屾暣镐ц捐★纸鏁版嵁搴挞昏緫璁捐★级 1) 瀹屾暣镐у疄鐜版満鍒讹细 瀹炰綋瀹屾暣镐э细涓婚敭 鍙傜収瀹屾暣镐э细 鐖惰〃涓鍒犻櫎鏁版嵁锛氱骇镵斿垹闄わ绂鍙楅檺鍒犻櫎锛涚疆绌哄 鐖惰〃涓鎻掑叆鏁版嵁锛氩弹闄愭彃鍏ワ绂阃掑綊鎻掑叆 鐖惰〃涓镟存柊鏁版嵁锛氱骇镵旀洿鏂帮绂鍙楅檺镟存柊锛涚疆绌哄 dbms瀵瑰弬镦у畬鏁存у彲浠ユ湁涓ょ嶆柟娉曞疄鐜帮细澶栭敭瀹炵幇链哄埗锛堢害𨱒熻勫垯锛夊拰瑙﹀彂鍣ㄥ疄鐜版満鍒 鐢ㄦ埛瀹氢箟瀹屾暣镐э细 not null锛沜heck锛涜Е鍙戝櫒 2) 鐢ㄧ害𨱒熻岄潪鍟嗗姟瑙勫垯寮哄埗鏁版嵁瀹屾暣镐 閲囩敤鏁版嵁搴撶郴缁熷疄鐜版暟鎹镄勫畬鏁存с傝繖涓崭絾鍖呮嫭阃氲繃镙囧嗳鍖栧疄鐜扮殑瀹屾暣镐ц屼笖杩桦寘𨰾鏁版嵁镄勫姛鑳芥с傚湪鍐欐暟鎹镄勬椂鍊栾缮鍙浠ュ炲姞瑙﹀彂鍣ㄦ潵淇濊瘉鏁版嵁镄勬ｇ‘镐с备笉瑕佷緷璧栦簬鍟嗗姟灞备缭璇佹暟鎹瀹屾暣镐э绂瀹冧笉鑳戒缭璇佽〃涔嬮棿锛埚栭敭锛夌殑瀹屾暣镐ф墍浠ヤ笉鑳藉己锷犱簬鍏朵粬瀹屾暣镐ц勫垯涔嬩笂銆 3) 寮哄埗鎸囩ず瀹屾暣镐 鍦ㄦ湁瀹虫暟鎹杩涘叆鏁版嵁搴扑箣鍓嶅皢鍏跺墧闄ゃ傛縺娲绘暟鎹搴撶郴缁熺殑鎸囩ず瀹屾暣镐х壒镐с傝繖镙峰彲浠ヤ缭鎸佹暟鎹镄勬竻娲佽岃兘杩浣垮紑鍙戜汉锻樻姇鍏ユ洿澶氱殑镞堕棿澶勭悊阌栾𨱒′欢銆 4) 浣跨敤镆ユ垒鎺у埗鏁版嵁瀹屾暣镐 鎺у埗鏁版嵁瀹屾暣镐х殑链浣虫柟寮忓氨鏄闄愬埗鐢ㄦ埛镄勯夋嫨銆傚彧瑕佹湁鍙鑳介兘搴旇ユ彁渚涚粰鐢ㄦ埛涓涓娓呮榈镄勪环鍊煎垪琛ㄤ緵鍏堕夋嫨銆傝繖镙峰皢鍑忓皯阌鍏ヤ唬镰佺殑阌栾鍜岃瑙ｅ悓镞舵彁渚涙暟鎹镄勪竴镊存с傛煇浜涘叕鍏辨暟鎹鐗瑰埆阃傚悎镆ユ垒锛氩浗瀹朵唬镰併佺姸镐佷唬镰佺瓑銆 5) 閲囩敤瑙嗗浘 涓轰简鍦ㄦ暟鎹搴揿拰搴旂敤绋嫔簭浠ｇ爜涔嬮棿鎻愪緵鍙︿竴灞傛娊璞★纴鍙浠ヤ负搴旂敤绋嫔簭寤虹珛涓挞棬镄勮嗗浘钥屼笉蹇呴潪瑕佸簲鐢ㄧ▼搴忕洿鎺ヨ块梾鏁版嵁琛ㄣ傝繖镙峰仛杩樼瓑浜庡湪澶勭悊鏁版嵁搴揿彉镟存椂缁欎綘鎻愪緵浜嗘洿澶氱殑镊鐢便 5. 鍏朵粬璁捐℃妧宸 1) 阆垮厤浣跨敤瑙﹀彂鍣 瑙﹀彂鍣ㄧ殑锷熻兘阃氩父鍙浠ョ敤鍏朵粬鏂瑰纺瀹炵幇銆傚湪璋冭瘯绋嫔簭镞惰Е鍙戝櫒鍙鑳芥垚涓哄共镓般傚亣濡备綘纭瀹为渶瑕侀噰鐢ㄨЕ鍙戝櫒锛屼綘链濂介泦涓瀵瑰畠鏂囨。鍖栥 2) 浣跨敤甯哥敤鑻辫锛堟垨钥呭叾浠栦换浣曡瑷锛夎屼笉瑕佷娇鐢ㄧ紪镰 鍦ㄥ垱寤轰笅𨰾夎彍鍗曘佸垪琛ㄣ佹姤琛ㄦ椂链濂芥寜镦ц嫳璇钖嶆帓搴忋傚亣濡傞渶瑕佺紪镰侊纴鍙浠ュ湪缂栫爜镞侀梼涓婄敤鎴风煡阆撶殑鑻辫銆 3) 淇濆瓨甯哥敤淇℃伅 璁╀竴涓琛ㄤ笓闂ㄥ瓨鏀句竴鑸鏁版嵁搴扑俊鎭闱炲父链夌敤銆傚湪杩欎釜琛ㄩ噷瀛樻斁鏁版嵁搴揿綋鍓岖増链銆佹渶杩戞镆/淇澶嶏纸瀵笕ccess锛夈佸叧镵旇捐℃枃妗ｇ殑钖岖О銆佸㈡埛绛変俊鎭銆傝繖镙峰彲浠ュ疄鐜颁竴绉岖亩鍗曟満鍒惰窡韪鏁版嵁搴掳纴褰揿㈡埛鎶辨ㄤ粬浠镄勬暟鎹搴撴病链夎揪鍒板笇链涚殑瑕佹眰钥屼笌浣犺仈绯绘椂锛岃繖镙峰仛瀵归潪瀹㈡埛链/链嶅姟鍣ㄧ幆澧幂壒鍒链夌敤銆 4) 鍖呭惈鐗堟湰链哄埗 鍦ㄦ暟鎹搴扑腑寮曞叆鐗堟湰鎺у埗链哄埗𨱒ョ‘瀹氢娇鐢ㄤ腑镄勬暟鎹搴撶殑鐗堟湰銆傛椂闂翠竴闀匡纴鐢ㄦ埛镄勯渶姹傛绘槸浼氭敼鍙樼殑銆傛渶缁埚彲鑳戒细瑕佹眰淇鏀规暟鎹搴撶粨鏋勚傛妸鐗堟湰淇℃伅鐩存帴瀛樻斁鍒版暟鎹搴扑腑镟翠负鏂逛究銆 5) 缂栧埗鏂囨。 瀵规墍链夌殑蹇鎹锋柟寮忋佸懡钖嶈勮寖銆侀檺鍒跺拰鍑芥暟閮借佺紪鍒舵枃妗ｃ 閲囩敤缁栾〃銆佸垪銆佽Е鍙戝櫒绛夊姞娉ㄩ喷镄勬暟鎹搴揿伐鍏枫傚瑰紑鍙戙佹敮鎸佸拰璺熻釜淇鏀归潪甯告湁鐢ㄣ 瀵规暟鎹搴撴枃妗ｅ寲锛屾垨钥呭湪鏁版嵁搴撹嚜韬镄勫唴閮ㄦ垨钥呭崟镫寤虹珛鏂囨。銆傝繖镙凤纴褰撹繃浜嗕竴骞村氭椂闂村悗鍐嶅洖杩囧ご𨱒ュ仛绗2 涓鐗堟湰锛岀姱阌欑殑链轰细灏嗗ぇ澶у噺灏戙 6) 娴嬭瘯銆佹祴璇曘佸弽澶嶆祴璇 寤虹珛鎴栬呬慨璁㈡暟鎹搴扑箣钖庯纴蹇呴’鐢ㄧ敤鎴锋柊杈揿叆镄勬暟鎹娴嬭瘯鏁版嵁瀛楁点傛渶閲嶈佺殑鏄锛岃╃敤鎴疯繘琛屾祴璇曞苟涓斿悓鐢ㄦ埛涓阆扑缭璇侀夋嫨镄勬暟鎹绫诲瀷婊¤冻鍟嗕笟瑕佹眰銆傛祴璇曢渶瑕佸湪鎶婃柊鏁版嵁搴撴姇鍏ュ疄闄呮湇锷′箣鍓嶅畬鎴愩 7) 妫镆ヨ捐 鍦ㄥ紑鍙戞湡闂存镆ユ暟鎹搴撹捐＄殑甯哥敤鎶链鏄阃氲繃鍏舵墍鏀鎸佺殑搴旂敤绋嫔簭铡熷瀷妫镆ユ暟鎹搴撱傛崲鍙ヨ瘽璇达纴阍埚规疮涓绉嶆渶缁堣〃杈炬暟鎹镄勫师鍨嫔簲鐢锛屼缭璇佷綘妫镆ヤ简鏁版嵁妯″瀷骞朵笖镆ョ湅濡备綍鍙栧嚭鏁版嵁銆