下载掌阅APP，畅读海量书库
立即打开
别问我数据库是什么。MOL说过，这本书里不讲基础知识。在这里讲的是如何去设计数据库。
MOL相信很多大学老师一定是这样教学的：设计数据库一定要先设计数据字典，这个字典看起来像这样，如表1-1所示。
表1-1 登录信息的数据字典
这个字典描述了一个用户登录信息表。设计好这个字典以后，再去数据库（SQLServer\Oracle\MySQL……）中去实现这个字典，实现的方法无非就是SQL语句create table，或者用图形化工具去设计表。
大家有没有觉得这个字典设计得有点鸡肋？如果要改需求，比如加入注册时间这个字段，试问，你会先修改字典，然后再去修改数据库吗？如果需求更改得比较频繁，那么你一定会厌烦“数据字典”这个东西的。
其实不然，数据字典是一个神器，只是你的打开方式不对。
面向对象是本书的一条主线，本书中对面向对象的表述甚至有些“极端”，但是一定可以把OO（面向对象）思想灌输给大家的。
面向对象里说，一切皆对象。也就是说，数据库是对象，数据库中的表也是对象。因此，我们将以对象的形式来描述一个数据库表，这个描述将以用户登录信息来举例。
在数据库里，对“对象”的体现莫过于“属性”，属性是什么？说白了，属性就是字段。怎么理解？一个登录对象，必然有用户名和密码，这是它的属性。那么反映到数据库中，就是用户名字段和密码字段，这样就理解了吧。
为了让一个数据字典看起来更像是一个对象，我们将借助PowerDesigner（以下简称PD）工具来设计。如果不会用PD，请自行去“某度”或“某狗”去搜索一下。
下面先来做一个概念模型CDM（Concept Data Model），如图1-2所示。
图1-2 登录信息的概念模型
这样看是不是有点对象的意思了？有对象名，有对象属性。
那为什么建立的是CDM而不是物理模型PDM（Physical Data Model）？先不着急来回答这个问题，先把建立的CDM生成PDM，然后进行对比。生成的PDM如图1-3所示。
图1-3 登录信息的物理模型
看起来二者好像没什么区别，那么下面再建立一个用户订单的对象。我们知道，一个用户可以有0个或多个订单，那么用户&订单的CDM看起来像下面这样，如图1-4所示。
图1-4 多表间关系的概念模型
它生成的PDM如图1-5所示。
图1-5 多表间关系物理模型
到这一步，就看出二者的区别了吧。PDM的描述更接近于数据库，因为可以从PDM中清晰地看到关于外键等数据库表的描述；而CDM更接近于需求，我们只需要关心一个用户有多个订单就可以了，至于外键之类，不是CDM要关心的问题。
在设计数据库的时候，一定是从需求出发，所以设计CDM会更贴近需求，也会更容易一些。
OK，我们再回到数据字典的问题，为什么要用PD来画一个CDM，而不是用Excel之类的软件来做一个数据字典的表格？用PD做数据库设计的好处有很多，这里只列举两点：
以上两点好处，足以让我们选择PD来设计和维护数据库了。
相信很多新手程序员都喜欢用大量的SQL语句来实现一个又一个复杂的功能，而且非常有成就感。但本书不会教你怎样写SQL语句，而且会劝大家尽量少写SQL语句。为什么呢？很简单，我们要面向对象！一个复杂的SQL语句是很难体现对象特性的。那么如何保证尽量少地去写SQL语句呢？这是第3章的内容，这里先不做介绍。
少写SQL语句，并不是不写SQL语句。那么哪些地方需要写SQL呢？答案是存储过程、事务、触发器。可以看出来，这里列举了存储过程、事务、触发器这3种SQL语句的出现形式，它们有一个共同点，就是业务规则是相对固定的。比如，新用户注册完成以后，数据库要悄悄地给这个用户添加一个购物车，这种业务场景最好使用触发器。关于触发器的优势，这里也不会细说，MOL只会轻轻地告诉你，触发器比你写代码提交快很多。
既然项目中出现了SQL语句，那么就需要对这些SQL语句进行分析，看它们的执行效率是否符合要求。比如一个select语句要执行10分钟，那么这个SQL语句就得“枪毙”重写了。通常，看一个SQL语句的执行效率，主要集中在全表扫描和索引上面，尽量不使用全表扫描，尽量使用索引，目的都是让SQL执行起来更快一些。
关于数据库，要说的最后一点是主键的问题。主键的类型有多种多样，可以使用数字、字母、时间等，只要保证它是唯一的就可以了。那么我们到底应该取用什么类型呢？一些专家一定会说：看情况而定。MOL当然不会这么说。建议大家使用GUID类型。使用GUID类型的好处就是：它的长度是固定的，而且永远都不会重复。如果使用int类型，虽然可以很轻松地使用主键自增保证它是唯一的，但当它增长到一定数量的时候，int已经不足以描述了。
MOL曾经经历过一件事，彩票奖池金额在2016年元月的时候已经到达2.4亿多，这个数字是无法用int来描述的，所以把程序中所有用int描述主键的地方都改成了long。其他的数据类型都有自己的缺陷，所以使用GUID来作为主键字段的数据类型。当然，GUID也有自己的缺陷，如不直观、没有数据含义等。但这些功能其实都可以解决和避免，所以为了简单和实用，我们使用GUID作为主键字段的数据类型。可以看到，MOL说建议GUID这件事情时说了3遍，正所谓重要的事情说3遍嘛。
前端和数据库都描述完了，最重要的代码就要登场了，你以为代码就是一堆C#关键词的集合？我就只能“呵呵”了。
那么我们应该如何去组织代码呢？面对频繁的数据库操作，要如何尽量少地写SQL语句呢（在本书的项目中，C#代码中是不掺杂任何SQL语句的）？大量的SQL查询是否会影响网站速度？……
这些疑问，将在后面的章节中一一解答。