绝无经由的MySQL数据库的数据范例和建库战略

在我们工作的过程中，经常能听到很多不使用MySQL的理由，虽然其中有一些是对MySQL的误解，不过同样也有一些是合情合理的。　　不论你是巨大的收费数据库空间仍是年夜型电子商务网站，关于数据库来讲公道的计划表布局、充实使用空间都是非常需要的。这就请求我们对数据库体系的经常使用数据范例有充实的熟悉和公道的使用。上面我们将给人人先容一点心得体味但愿能匡助你在建库的时分能思索的加倍公道。

　　1、数字范例

　　数字范例依照我的分类办法分为三类：整数类、小数类和数字类。

　　我所谓的“数字类”，就是指DECIMAL和NUMERIC，它们是统一品种型。它严厉的说不是一种数字范例，由于他们实践上是将数字以字符串情势保留的;他的值的每位(包含小数点)占一个字节的存储空间，因而这类范例泯灭空间对照年夜。可是它的一个凸起的长处是小数的位数流动，在运算中不会“掉真”，以是对照合适用于“代价”、“金额”如许对精度请求不高但正确度请求十分高的字段。

　　小数类，即浮点数范例，依据精度的分歧，有FLOAT和DOUBLE两种。它们的上风是准确度，FLOAT能够暗示相对值十分小、小到约1.17E-38(0.000...0117，小数点前面有37个零)的小数，而DOUBLE更是能够暗示相对值小到约2.22E-308(0.000...0222，小数点前面有307个零)的小数。FLOAT范例和DOUBLE范例占用存储空间分离是4字节和8字节。假如必要用到小数的字段，精度请求不高的，固然用FLOAT了。但是说句其实话，我们“平易近用”的数据，哪有请求精度那末高的呢?这两品种型至今我没有效过DD我还没有碰到合适于利用它们的事例。

　　用的最多的，最值得一丝不苟的，是整数范例。从只占一个字节存储空间的TINYINT到占8个字节的BIGINT，选择一个“够用”而且占用存储空间最小的范例是计划数据库时应当思索的。TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT占用存储空间分离为1字节、2字节、3字节、4字节和8字节，就无标记的整数而言，这些范例能暗示的最年夜整数分离为255、65535、16777215、4294967295和18446744073709551615。假如用来保留用户的岁数(举例来讲，数据库中保留岁数是不成取的)，用TINYINT就够了;九城的《纵横》里，各项妙技值，用SMALLINT也够了;假如要用作一个一定不会凌驾16000000行的表的AUTO_INCREMENT的IDENTIFY字段，固然用MEDIUMINT不必INT，试想，每行勤俭一个字节，16000000行能够勤俭10兆多呢。

你可以配置MySQL运行在微小的嵌入式应用程序中，处理的数据可能不足1Mb??而你也可以用它来处理数Tb的数据。MySQL获得这种可扩展性的路径之一是通过一个人们所熟知的存储过程，这是一个运行在程序之外的微型、预编译程序。

如果，某一版本可以提供强大的并发响应，但是没有Oracle的相应版本稳定，或者价格较贵，那么，它就是不适合的。

作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!

入门没那么困难，精通没那么容易

至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。

仓酷云

总感觉自己还是不会SQL

比如，MicrosoftSQLServer2008的某一个版本可以满足现在的这个业务的需要，而且价格还比Oracle11g要便宜，那么这一产品就是适合的。

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。