MYSQL编程：数据库正轨化和计划技能(3)
你不用花费很多时间和金钱来培训现有的职工，或者去花大价钱雇用那些拥有各种证书的开发者。因为MySQL的维护和管理在很大程度上是“傻瓜型”的。技能|计划|数据|数据库数据干系在界说第四个正轨化的情势前，我想起首提一下三种基础的数据干系：一对一，一对多和多对多。我们转头看一下经由第一个正轨化的users表。如果我们将url的字段放在一个自力的表中，每次在users表中拔出一个纪录，我们就会在urls表中拔出一行。我们将失掉一个一对一的干系：用户表中的每行，都将在urls表中找到响应的一行。关于我们的使用来说，这既不有用也不尺度。
然后看看第二个正轨化的例子。关于每一个用户纪录，我们的表格同意有多个urls的纪录与之联系关系。这是一个一对多的干系，这是一个很罕见的干系。
关于多对多的干系来讲，就有点庞大了。在我们的第三个正轨化情势的例子中，我们的一个用户与良多的url有关，而我们想将该布局变成同意多个用户与多个的urls有关，如许我们就能够失掉一个多对多的布局。在会商前，我们先看看表格布局会有些甚么变更
users
userIdnamerelCompId
1Joe1
2Jill2
companies
compIdcompanycompany_address
1ABC1WorkLane
2XYZ1JobStreet
urls
urlIdurl
1abc.com
2xyz.com
url_relations
relationIdrelatedUrlIdrelatedUserId
111
212
321
422
为了进一步减低数据的冗余，我们使用第四级正轨化情势。我们创立了一个颇奇异的url_relations表，内里的字段均为主键大概foreignkey。经由过程这个表，我们就能够打消urls表中的反复项目。以下是第四个正轨化情势的详细请求：
第四个正轨化情势
1.在一个多对多的干系中，自力的实体不克不及寄存在统一个表格中
因为它仅使用于多对多的干系，因而年夜多半的开辟者能够疏忽这条划定。不外在某些情形下，它长短常有用的，这个例子就是如许，我们经由过程将不异的实体分别出来，而且将干系移到它们本人的表格中，从而改善了urls表格。
为了令你更简单分明，我们举个详细的例子，以下将用一个SQL语句选择出一切属于joe的urls：
SELECTname,urlFROMusers,urls,url_relationsswheresurl_relations.relatedUserId=1AND
users.userId=1ANDurls.urlId=url_relations.relatedUrlId
假如我们想要遍历每一个人的团体信息和url信息，我们能够如许做：
SELECTname,urlFROMusers,urls,url_relationsswheresusers.userId=url_relations.relatedUserIdAND
urls.urlId=url_relations.relatedUrlId
第五级正轨化情势
另有一级正轨化的情势，它其实不罕见，有点深邃，而且在年夜部分的情形下都是不用要的。它的准绳是：
1.本来的表格必需能够经由过程由它分别进来的表格从头构建
利用这个划定的优点是，你能够确保不会在分别的表格中引进过剩的列，一切你创立的表格布局都与它们的实践必要一样年夜。使用这条划定是一个好习气，不外除非你要处置一个十分年夜型的数据，不然你将不必要用到它。
但愿这篇文章对你有效，而且能够匡助你在一切的项目中使用这些正轨化的划定。你大概想晓得这些办法是从哪来的，我能够告知你，后面三个正轨化的划定是1972年，Dr.E.F.Codd在他的论文“进一步正轨化数据库的干系模子中”提出的，其他的划定是经由厥后的汇合实际和干系数学家实际化的。批评：正所谓物级必反，将表格分得细致偶然其实不好，由于如许必要将各表举行各类的联系关系，这会令查询时变得庞大，并且效力也大概下降，这些正轨化的划定能够参考，在实践使用时，要依据项目标巨细，需要时能够举行一些测试，以计划出更公道的表格布局。
人们常说“成功孕育成功”，这种说法明显非常适合MySQL的情况。MySQL学习教程这个开源数据库号称在全世界有超过110万份的完全安装。 原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。 分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。 不过话说回来了，绝大多数的性能优化准则与对sqlserver存储的结构理解息息相关 作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！ 对于数据库来说，查询是数据库的灵魂，那么SQL查询效率究竟效率如何呢？下文将带对SQL查询的相关问题进行讨论，供您参考。 只能告诉你，学好数据库语言和原理，多见识几种数据库软件，比一棵树上吊死要好。
页:
[1]