一种自动处理数据表的方法
在数据字段名中加入其数据类型,在程序中根据这个类型来生成sql,显示数据(比去系统表中找效率高,同时可以用在不同的数据库中),并可以在aspx中显示,或者添加字段posted @ 2005-10-15 02:33 偶卖糕的 阅读(578) 评论(0) 编辑
2005年10月15日
数据库正规化和设计技巧
数据库正规化和设计技巧
数据库正规化和设计技巧
在动态网站的设计中，数据库设计的重要性不言而喻。如果设计不当,查询起来就非常吃力，程序的性能也会受到影响。无论你使用的是mySQL或者Oracle数据库，通过进行正规化的表格设计，可以令你的PHP代码更具可读性，更容易扩展，从而也会提升应用的性能。
简单说来，正规化就是在表格设计时，消除冗余性和不协调的从属关系。在本文中，我将通过五个渐进的过程来告诉你在设计中应该了解的正规化技巧。从而建立一个可行而且效率高的数据库。本文也会详细分析一下可以利用的关系类型。
这里假定我们要建立一个用户信息的表格，其中要存储用户的名字、公司、公司地址和一些个人的收藏夹或url。在开始时，你可能定义一个如下的表格结构：
零状态形式
users
name company company_address url1 url2
Joe ABC 1 Work Lane abc.com xyz.com
Jill XYZ 1 Job Street abc.com xyz.com
由于没有进行任何的正规化处理，我们将这种形式的表称为零状态形式的表。留意其中的url1和url2字段---如果我们在应用中需要第三个url呢？这样你就要在表格中多加一列，很明显，这不是一个好办法。如果你要创建一个富有扩展性的系统，你就要考虑使用第一个正规化的形式，并且应用到该表格中。
第一级正规化形式
1．消除每个表格中重复的组
2．为每套相关的数据建立一个独立的表格
3．使用一个主键来标识每套相关的数据
以上的表格明显违反了上面第一条的规定，那么第三条的主键又是什么意思呢？很简单，它只是在每个记录中加入一个唯一的、自动增加的整型值。通过这个值，就可以将两个姓名一样的记录区分开来。通过应用第一级正规化形式，我们得到了以下的表格：
users
userId name company company_address url
1 Joe ABC 1 Work Lane abc.com
1 Joe ABC 1 Work Lane xyz.com
2 Jill XYZ 1 Job Street abc.com
2 Jill XYZ 1 Job Street xyz.com
现在我们的表格可以说已经处在第一级正规化的形式了，它已经解决了url字段的限制问题，不过这样的处理后又带来了一个新的问题。每次在user表中插入一条记录的时候，我们都必须重复所有的公司和用户数据。这样不仅令数据库比以前大了，而且很容易出错。因此还要经过第二级正规化处理。
第二级正规化形式
1．为应用在多条记录的字段建立独立的表格
2．通过一个foreign key来关联这些表格的值
我们将url的值放在一个独立的表格中，这样我们就可以在以后加入更多的数据，而无需担心产生重复的值。我们还通过主键值来关联这些字段：
users
userId name company company_address
1 Joe ABC 1 Work Lane
2 Jill XYZ 1 Job Street
urls
urlId relUserId url
1 1 abc.com
2 1 xyz.com
3 2 abc.com
4 2 xyz.com
如上所示，我们创建了独立的表格，users表中的主键userid现在与url表中的foreign key relUserId关联。现在的情况好象已经得到了明显的改善。不过，如果我们要为ABC公司加入一个员工记录呢？或者更多，200个？这样我们就必须重复使用公司名和地址，这明显不够冗余。因此我们将应用第三级正规化方法：
第三级正规化形式
1．消除不依赖于该键的字段
公司名及地址与User Id都是没有关系的，因此它们应用拥有自己的公司Id：
users
userId name relCompId
1 Joe 1
2 Jill 2
companies
compId company company_address
1 ABC 1 Work Lane
2 XYZ 1 Job Street
urls
urlId relUserId url
1 1 abc.com
2 1 xyz.com
3 2 abc.com
4 2 xyz.com
这样我们就将companies表中的主键comId和users表中名字为relCompId的foreign key关联起来，就算为ABC公司加入200个员工，在companies中也只有一条记录。我们的users和urls表可以不断地扩大，而无需担心插入不必要的数据。大部分的开发者都认为经过三步的正规化就足够了，这个数据库的设计已经可以很方便地处理整个企业的负担，此看法在大多数的情况下是正确的。
我们可以留意一下url的字段--你注意到数据的冗余了吗？如果给用户用户输入这些url数据的HTML页面是一个文本框，可任意输入的话，这并没有问题，两个用户输入同样收藏夹的概率较少，不过，如果是通过一个下拉式的菜单，只让用户选择两个url输入，或者更多一点。这种情况下，我们的数据库还可以进行下一级别的优化--第四步，对于大多数的开发者来说，这一步都是忽略的，因为它要依赖一个很特别的关系--一个多对多的关系，这在我们的应用中是还没有遇到过的。
数据关系
在定义第四个正规化的形式前，我想首先提一下三种基本的数据关系：一对一，一对多和多对多。我们回头看一下经过第一个正规化的users表。要是我们将url的字段放在一个独立的表中，每次在users表中插入一个记录，我们就会在urls表中插入一行。我们将得到一个一对一的关系：用户表中的每一行，都将在urls表中找到相应的一行。对于我们的应用来说，这既不实用也不标准。
然后看看第二个正规化的例子。对于每个用户记录，我们的表格允许有多个urls的记录与之关联。这是一个一对多的关系，这是一个很常见的关系。
对于多对多的关系来说，就有点复杂了。在我们的第三个正规化形式的例子中，我们的一个用户与很多的url有关，而我们想将该结构变为允许多个用户与多个的urls有关，这样我们就可以得到一个多对多的结构。在讨论前，我们先看看表格结构会有些什么变化
users
userId name relCompId
1 Joe 1
2 Jill 2
companies
compId company company_address
1 ABC 1 Work Lane
2 XYZ 1 Job Street
urls
urlId url
1 abc.com
2 xyz.com
url_relations
relationId relatedUrlId relatedUserId
1 1 1
2 1 2
3 2 1
4 2 2
为了进一步减低数据的冗余，我们运用第四级正规化形式。我们创建了一个颇奇怪的url_relations表，里面的字段均为主键或者foreign key。通过这个表，我们就可以消除urls表中的重复项目。以下是第四个正规化形式的具体要求：
第四个正规化形式
1．在一个多对多的关系中，独立的实体不能存放在同一个表格中
由于它仅应用于多对多的关系，因此大多数的开发者可以忽略这条规定。不过在某些情况下，它是非常实用的，这个例子就是这样，我们通过将相同的实体分离出来，并且将关系移到它们自己的表格中，从而改进了urls表格。
为了令你更容易明白，我们举个具体的例子，以下将用一个SQL语句选择出所有属于joe的urls：
SELECT name, url FROM users, urls, url_relations WHERE url_relations.relatedUserId = 1 AND users.userId = 1 AND urls.urlId = url_relations.relatedUrlId
如果我们想要遍历每个人的个人信息和url信息，我们可以这样做：
SELECT name, url FROM users, urls, url_relations WHERE users.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId
第五级正规化形式
还有一级正规化的形式，它并不常见，有点深奥，并且在大部分的情况下都是不必要的。它的原则是：
1．原来的表格必须可以通过由它分离出去的表格重新构建
使用这个规定的好处是，你可以确保不会在分离的表格中引入多余的列，所有你创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习惯，不过除非你要处理一个非常大型的数据，否则你将不需要用到它。
希望这篇文章对你有用，并且可以帮助你在所有的项目中应用这些正规化的规定。你可能想知道这些方法是从哪来的，我可以告诉你，前面三个正规化的规定是1972年，Dr. E.F. Codd在他的论文“进一步正规化数据库的关系模型中”提出的，其余的规定是经过后来的集合理论和关系数学家理论化的。 评论：正所谓物级必反，将表格分得过细有时并不好，因为这样需要将各表进行各种的关联，这会令查询时变得复杂，而且效率也可能降低，这些正规化的规定可以参考，在实际应用时，要根据项目的大小，必要时可以进行一些测试，以设计出更合理的表格结构。
posted @ 2005-10-15 02:28 偶卖糕的 阅读(969) 评论(0) 编辑
数据库规范化技巧
数据库规范化技巧Luke Chung
FMS 总裁
2002年9月
适用于：
Microsoft® Access
摘要：本文为开发人员提供了一些技巧，使用这些技巧可以在设计 Access 表时避免某些问题。本文适用于 Microsoft Access 数据库 (.mdb) 和 Microsoft Access 项目 (.adp)。
目录
简介
理解您的数据
您需要什么样的数据？
您打算如何处理这些数据？
数据之间如何相互关联？
随着时间的推移数据会发生什么样的变化？
学习如何使用查询
数据库规范化概念
将唯一信息存储在一个地方
记录是免费的，而新字段非常昂贵
了解何时需要复制数据
使用没有确切含义的字段作为主键字段
使用引用完整性
小结
简介
在设计数据库时，最重要的步骤是要确保数据正确分布到数据库的表中。使用正确的数据结构，可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称是“数据库规范化”。
本文简要介绍数据库规范化的基本概念和一些需要注意并力求避免的常见问题。
理解您的数据
在设计表之前，应明确您打算如何处理数据，还要了解随着时间的推移数据会发生什么样的变化。您所做的假设将会影响最终的设计。
您需要什么样的数据？
设计应用程序时，关键要了解设计的最终结果，以便确保您准备好所有必需的数据并知道其来源。例如，报表的外观、每个数据的来源以及所需的所有数据是否都存在。对项目损失最大的莫过于在项目后期发现重要报表缺少数据。
知道需要什么样的数据后，就必须确定数据的来源。数据是否从其他数据源中导入？数据是否需要清理或验证？用户是否需要输入数据？
明确所需数据的类型和来源是数据库设计的第一步。
您打算如何处理这些数据？
用户是否需要编辑这些数据？如果需要，应如何显示数据以便于用户理解和编辑？有没有验证规则和相关的查找表？要求对编辑和删除保留备份的数据输入有没有相关联的审核问题？需要为用户显示哪些摘要信息？是否需要生成导出文件？了解这些信息后，就可以想象字段之间是如何相互关联的了。
数据之间如何相互关联？
将数据分组放入相关字段（例如与客户相关的信息、与发票相关的信息等），每个字段组都代表要建立的表。然后考虑如何将这些表相互关联。例如，哪些表具有一对多关系（例如，一个客户可能持有多张发票）？哪些表具有一对一关系（这种情况下，通常会考虑将其组合到一个表中）？
随着时间的推移数据会发生什么样的变化？
设计表之后，常常会由于没有考虑时间的影响而导致以后出现严重问题。许多表设计在当时使用时效果非常好，但是，常常会因为用户修改数据、添加数据以及随时间的推移而崩溃。开发人员经常会发现需要重新设计表的结构来适应这些变化。表的结构发生变化时，所有相关的内容（查询、窗体、报表、代码等）也必须随之更新。理解并预测数据会随时间推移发生哪些变化，可以实现更好的设计，减少问题的发生。
学习如何使用查询
了解如何分析和管理数据同样很重要。您应该深刻理解查询的工作原理，理解如何使用查询在多个表之间链接数据，如何使用查询对数据进行分组和汇总，以及如何在不需要以规范化格式显示数据时使用交叉表查询。
好的数据设计的最终目标就是要平衡两个需要：既要随着时间的推移有效地存储数据，又要轻松地检索和分析数据。理解查询的功能对正确设计表很有帮助。
数据库规范化概念
这部分介绍数据库规范化所涉及的基本概念，而不是对数据库规范化进行理论性的探讨。如何在您的实际情况中应用这些概念可能会随着应用程序需要的不同而有所变化。这部分的目的是理解这些基本概念、根据实际需要应用它们，并理解偏离这些概念将会出现哪些问题。
将唯一信息存储在一个地方
大部分数据库开发人员都理解数据库规范化的基本概念。理想情况下，您希望将相同的数据存储在同一个地方，并在需要引用时使用 ID 来进行引用。因此，如果某些信息发生了变化，则可以在一个地方进行更改，而整个程序中的相应信息也会随之更改。
例如，客户表会存储每个客户的记录，包括姓名、地址、电话号码、电子邮件地址以及其他特征信息。客户表中可能包含唯一的 CustomerID 字段（通常是 Autonumber 字段），这个字段即该表的主键字段，其他表使用它来引用该客户。因此，发票表可以只引用客户的 ID 值，而不是在每张发票中存储客户的所有信息（因为同一个客户可能会持有多张发票），这样利用客户的 ID 值即可从客户表中查找客户的详细信息。使用 Access 中功能强大的窗体（使用组合框和子窗体），可以轻松地完成这项工作。如果需要修改客户信息（例如新增电话号码），只需在客户表中修改，应用程序中引用该信息的任何其他部分都会随之自动更新。
使用正确规范化的数据库，通过简单的编辑即可轻松处理数据随时间推移而发生的更改。使用未正确规范化的数据库，通常需要利用编程或查询来更改多条记录或多个表。这不仅会增加工作量，还会增加由于未正确执行代码或查询而导致数据不一致的可能性。
记录是免费的，而新字段非常昂贵
理想的数据库应该只需要随着时间的推移添加新的记录，数据库表应该能够保存大量记录。但是，如果您发现需要增加更多字段，则可能会碰到设计问题。
电子表格专家经常会遇到上述问题，因为他们习惯于按照设计电子表格的方式设计数据库。设计经常随时间变化的字段（例如，年、季度、产品和销售人员）需要在将来添加新字段。而正确的设计应该是转换信息并将随时间变化的数据放在一个字段内，这样就可以添加更多记录。例如，只需创建“年”字段，然后在该字段中输入各记录相应的年份值即可，无需为每年创建一个单独的字段。
增加额外的字段可能会产生问题，因为表结构的变化会对应用程序的其他部分产生影响。在表中添加更多字段时，依赖该表的对象和代码也需要更新。例如，查询需要获取额外的字段，窗体需要显示这些字段，而报表则需要包含这些字段，等等。但是，如果数据已经规范化，则现有对象会自动检索新数据，并正确计算或显示这些数据。查询功能尤其强大，因为它允许您按“年”字段进行分组，以逐年显示摘要（不管表中包含哪些年份）。
但是，数据规范化并不意味着不能显示或使用随时间而变化或依赖时间的字段。需要浏览或显示这类信息的开发人员通常可以使用交叉表查询来达到这一目的。如果您不熟悉交叉表查询，应该学习如何使用它们。虽然它们与表有所不同（尤其是用户无法编辑交叉表查询的结果），但它们的确可以用于在数据表中显示信息（最多可以达到 255 个字段）。如果要在报表中使用它们，则会更加复杂，因为报表需要包含额外的或不断变化的字段名。这就是为什么大多数报表将数据作为独立的分组（而不是独立的列）显示的原因。对于那些别无选择的情况，您必须花时间去解决这个问题。希望所有人都能够理解这种决定会随着时间的变化对其他资源产生的影响。
这就是为什么增加记录是免费的（这是数据库的巨大优势）而增加字段是如此昂贵的原因。如果数据库设计正确，则可以适应各种各样的变化。
了解何时需要复制数据
有时数据需要反规范化，以便保存可能会随时间变化的信息。
在通过客户 ID 号将发票链接到客户表的简单示例中，我们可能需要保留开出发票时的客户地址（而不是制作发票时的地址，因为客户信息在这两个事件之间可能会有所变化）。如果开出发票时未保留客户地址，而将来又必须更新客户信息，则可能无法确定发送某些发票的确切地址。这可能会导致非常严重的商业问题。当然，有些信息（如客户的电话号码）可以不保存。因此，应该有选择地决定需要复制哪些数据。
需要复制数据的另一个例子是填写发票的明细项。报价单通常用于挑选客户订购的商品。我们可以只存储报价单 ID，而 ID 指向包含产品说明、价格和其他详细信息的报价单。但是，产品说明和价格会随着时间而改变。如果不将数据从报价单复制到明细表中，将来则无法准确地重新打印原始发票。如果您尚未收到付款，问题将非常严重。
因此，虽然规范化可以将相同的数据很好地保存在一个地方并能简化编辑工作，但某些情况下却不需要这些优势。如果以后由于历史原因需要数据的快照，则必须从一开始就在数据库中设计好。否则，一旦数据被覆盖就无法再找回。
使用没有确切含义的字段作为主键字段
为了提高效率，每个表都应该有一个主键字段。主键字段定义了在表中的唯一性，并由索引在其他字段中使用，以提高搜索性能。例如，客户表可以包含为每个客户定义唯一编号的 CustomerID 字段。为了便于讨论，假定表中包含多个字段，而不仅仅是简单的单一表查找（例如国家/地区列表）。
一般来说，主键字段应具有如下特征：
应该只包含一个字段
可以将多个字段定义为表的主键字段，但最好是使用一个字段。首先，如果需要使用多个字段来定义唯一性，则需要占用更多的空间来存储主键。其次，表中的其他索引还必须使用主键字段的组合，这样所占用的空间比使用一个字段所占用的空间要多。最后，在表中标识记录需要获取字段组合。使用一个 CustomerID 字段定义客户比使用其他字段组合要好得多。
应该为数字类型
Access 提供的 AutoNumber 字段类型是一个 Long Integer（长整数），非常适用于主键字段。这些值可以自动保证每个记录的唯一性，同时也支持多用户数据输入。
不会随时间而改变
主键字段不应该随时间而改变。一旦标识了主键字段，就应该永远不变（象社会保障号一样）。更改过的主键字段将很难再使用历史数据，因为其中的链接被破坏了。
应该没有确切含义
要确保主键字段不会随时间而更改，它应该没有确切含义。没有确切含义的主键值在其他数据不完整时也非常有用。例如，您可以指定一个客户编号，而无需该客户的完整地址。应用程序的其余部分可以很好地工作，您也可以在检索记录时添加信息。如果表中使用了国家/地区字段或其他您没有的标识字段作为主键的一部分，则很可能会导致无法使用应用程序。
鉴于上述原因，我们建议在大部分表中使用 AutoNumber 字段作为主键字段。通过使用组合框和隐藏列，可以将字段绑定到 AutoNumber 字段并将其隐藏，使用户无法看到。
使用引用完整性
对表进行定义并理解各表是如何关联的之后，请确保添加引用完整性来巩固各表之间的关系。这样可以避免错误地修改链接字段而留下孤立的记录。Microsoft Jet 数据库引擎支持复杂的引用完整性，允许用户进行级联更新和删除。一般情况下，不应修改 ID 字段。因此，级联更新用得较少，但级联删除却非常有用。
例如，如果发票表与订单表相关联，其中的一张发票可能有无限多个订单（明细项），并且每个订单记录包含它所链接的发票编号，则可以使用级联删除操作来删除发票记录，并自动删除所有相应的订单记录。这样可以避免出现没有相应发票记录的订单记录。
小结
我们希望您能尽快将这些数据库设计概念应用到您的应用程序设计中，从而最大程度地减少问题，减少未实现此类设计时需要进行的修正。祝您好运。
Luke Chung 是 FMS Inc. 的创始人兼总裁。FMS Inc. 是业界领先的第三方产品供应商，其产品适用于 Microsoft Access 用户和开发人员。
posted @ 2005-10-15 02:27 偶卖糕的 阅读(957) 评论(1) 编辑
ADO中的多层次数据集,类似于dataset
SHAPE是做子查询的操作，我把帮助贴上来给您看吧Shape Append 命令
Shape APPEND 命令将子 Recordset 分配给父 Recordset 中 Field 对象的 Value 属性。
语法
SHAPE {parent-command} [[AS] parent-alias]
APPEND ({child-command} [AS] child-alias
RELATE parent-column TO child-column...) [[AS] chapter-alias] ...
组成说明
该命令的组成部分为：
parent-command, child-command 如下之一。
在尖括号（“{}”）中的查询命令，返回 Recordset 对象。命令发布给基本数据提供者，其语法取决于该提供者的要求。虽然 ADO 并不要求使用任何指定的查询语言，但通常是使用结构化查询语言 (SQL)。圆括号（“()”）是必需的关键字，它们将子集列追加到引用由查询命令返回的 Recordset 的父。
以前成形的 Recordset 的名称。
另一个 Shape 命令。
TABLE 关键字，后跟表的名称。
parent-column 由 parent-command 返回的 Recordset 中的列。
child-column 由 child-command 返回的 Recordset 中的列。
... “parent-column TO child-column”子句实际上是列表，并用逗号将每个定义关系分隔开。
chapter-alias 别名，对追加到父的列的引用。
parent-alias 别名，对父 Recordset 的引用。
child-alias 别名，对子 Recordset 的引用。
... 在 APPEND 关键字后面的子句实际上是列表（每个子句使用逗号分隔），定义被追加到父的另一个列。
操作
发出 parent-command 并返回父 Recordset。然后发出 child-command 并返回子 Recordset。
例如，parent-command 可以从客户表返回公司的客户 Recordset，而 child-command 从定货表返回所有客户的定单 Recordset。
一般，父和子 Recordset 对象必须各自拥有用于关联父和子的列。列在 RELATE 子句中命名，parent-column 在先，child-column 在后。在各自的 Recordset 中，列可以有不同名称，但必须引用相同信息以便指定有意义的关系。例如，Customers 和 Orders Recordsets 可以同时拥有 customerID 字段。
数据构形将子集列追加到父 Recordset。子集列中的值是对子 Recordset 中列的引用，子 Recordset 满足 RELATE 子句。即在给定父行中的 parent-column 与在子集子的所有行中的 child-column 具有相同的值。
当您访问在子集列中的引用时，ADO 将自动检索由引用表示的 Recordset。注意尽管已经检索了全部子 Recordset，但子集（chapter）仅表示行的子集。
如果追加的列没有 chapter-alias，则会自动生成其名称。列的 Field 对象将被追加到 Recordset 对象的 Fields 集合，其数据类型将是 adChapter。
有关定位分级 Recordset 的详细信息，请参阅访问分级 Recordset 中的行。
参数化命令
如果您正在处理大的子 Recordset（尤其是比父 Recordset 大），却只需要访问部分子子集，那么，使用参数化命令会更有效。
non-parameterized command（非参数化命令）同时检索整个父和子 Recordsets，并将子集列追加到父，然后为每个父行指定相关子子集的引用。
parameterized command（参数化命令）检索整个父 Recordset，但在访问子集列时仅检索子集 Recordset。这种检索策略的差别可以有益的性能好处。
例如，可以指定如下：
"SHAPE {SELECT * FROM customer}
APPEND ({SELECT * FROM orders WHERE cust_id = ?}
RELATE cust_id TO PARAMETER 0)"
父和子表通常拥有列名 cust_id。child-command 有占位符（即“？”），受 RELATE 子句引用（即“...PARAMETER 0”）。关系在于显性标识的 customer 表 parent-column（即 cust_id）和隐性标识的 orders 表 child-column（即 cust_id）之间，由占位符和“PARAMETER 0”指定。
注意 PARAMETER 子句仅属于 Shape 命令语法。与 ADO Parameter 属性和 Parameters 集合均无关联。
在执行 Shape 命令时，发生如下情形：
执行 parent-command，并返回 customer 表的父 Recordset。
子集列被追加到父 Recordset。
在访问父行的子集列时，customer.cust_id 列的值将替换 orders.cust_id 的占位符，并执行 child-command。
orders 表（在此，orders.cust_id 列的值与 customer.cust_id 列的值相匹配）的所有行被检索。
对检索到的子行（即子 Recordset 的 chapter）的引用被放置在父 Recordset 当前行的子集列。
当访问另一个行的子集列时，重复步骤 3-5。
用Shape命令建立一个分层的记录集:
Dim Conn
Dim Rs
Dim ChildRs
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.ConnectionString = [your connectionstring]
Conn.Open
Set Rs = Server.CreateObject("ADODB.Recordset")
Rs.StayInSync = FALSE
Rs.Open "SHAPE {select distinct [class] from [thetable]} " & _
"APPEND ({select * from [thetable} " & _
"RELATE class TO class) AS classNum", conn
Set ChildRs = Server.CreateObject("ADODB.Recordset")
While Not Rs.Eof
Set ChildRs = rs("classNum").Value
Response.Write "<table>"
While Not ChildRs.Eof
Response.Write "<tr><td>" & ChildRs("Class") & "</td><td>" & ChildRs("Name") & "</td><td>" & ChildRs("Resume") & "</td><td>" & ChildRs(Regdate) & "</td></tr>"
ChildRs.MoveNext
Wend
Response.Write "</table>"
Rs.MoveNext
Wend
posted @ 2005-10-15 02:23 偶卖糕的 阅读(964) 评论(0) 编辑
数据库设计,错误设计的想法
当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。程序设计的精华就在于高度抽象,将最复杂的情况,抽象为最简单的几种情况的组合.而不是简单的将现世世界情况复制到程序代码中.
想到一个.net的错误处理方式,用一个统一的错误处理单元,接收各种类型的错误(catch 中的),在这个单元中进行日志等操作,然后按预先设想的逻辑,分不同情况,抛出异常. 如在catch中传入错误时同时传入需要的错误处理方式(1,直接抛出,2,拦截不抛出,3,传回"数据出错这样的字符串",4,如果是插入重复记录造成的sql错误,返回"你插入了重复记录")
posted @ 2005-10-15 01:33 偶卖糕的 阅读(668) 评论(0) 编辑
