标签：
在做完了之前的一系列工作之后，终于要进行应用后台的设计和实现环节了。在后台设计中，我们觉得数据库的设计是最重要的根基，因为所有业务逻辑均是架构在数据库的基础之止，如果对数据库进行修改，程序可能需要大改，工作量将非常之大，所以数据库设计必须非常重视。
在谈数据库设计之前，我们先谈一下ORM，即关系数据库与面向对象系统的映射，其理由是面向对象开发人员，不了解关系型数据库，因些引入ORM，使其不需要学习关系型数据库就可以进行数据库开发。我们认为，关系型数据已经有了几十年的发展历史，理论和实践都很成熟，反观ORM发展不过十来年左右，理论、功能和性能方面，都有很多问题，虽然在当前大行其道，但是我们认为其引入的问题，远比所解决的问题要多。我们认为，如果一个面向对象程序员，如果学习关系型数据库觉得有困难，那么不是这种技术不好，而是他可能根本不适合编程。因此我们倡导直接采用关系型数据库技术，不采用任何ORM框架。
回到数据库设计的话题，说到数据库设计，其理论基础是范式，尤其是第二和第三范式，是数据库设计的基础，我们必须对这些范式非常熟悉。当然，因为在其际项目中，由于性能方面的考虑，可能会违反范式，引入数据冗余，但是理解和掌握范式，对于我们设计出合理的数据库逻辑模型还是非常有帮助的。
关于数据库设计范式的详细内容，大家可对考百度百科的词条（百度百科数据库范式）。这里就不再讨论了。
我们这里讨论的是用户注册，看似用户数据库设计很简单，但是在实际应用中，却是一个比较复杂的问题。比如，在移动医疗应用中，我们应用的用户比如说是张三，他直接作为患者是一种简单的情况，但是他可能要替他的父母和孩子挂号看病，这时张三还是用户，但是实际接受服务的主体是他的父母和孩子，这需要怎么表示呢？还不仅如此，到医院就诊还需要就诊卡，而通常情况下，一个人可能有多张就诊卡，医院是只认就诊卡的，怎么将就诊卡对应到真实患者呢？再有，有些医院有会员系统，用户可以给会员卡充值，从而享受优惠，张三的会员卡，可以同时给父母和孩子使用，这种情况又如何表示呢？
以上分析的还仅仅是医疗方面的应用，在其他方面的应用，同样存在这样的问题，例如社区O2O中，社区便利店，实际服务的是某个房间，可能与业主是无关，同时，业主可能同时有几套房，O2O运营商怎么识别出该业主同时有几套房需要服务的信息，或者是业主全家迁移到新的住处，按照其以往的消费习惯，直接配送其所需的产品和服务。
上面所讲的应用场景，都需要在用户数据库设计中加以考虑。为了讨论问题方便，这里以移动医疗的用户数据库设计为例，讨论如何设计出更好的数据库结构，以满足实际应用的需要。
我们先对用户进行分类，明确以下几个概念：用户是直接使用我们产品的人，在上面的例子中，就是张三；客户是为产品和服务付费的实体，可以是张三绑定了会员卡；消费者是享受我们产品和服务的人，如果张三替父母或孩子咨询问题，那么张三的父母和孩子就是消费者，消费者是一个通用的概念，在这里就是患者。
如上图所示，用户只保存用户登录所需要的基本信息，这里需要注意的一点，虽然很多应用都是用手机号登录，但是千万不要把手机号作为登录名，因为用户手机号可能改变，所以用专门的手机号来存储比较合理，可以取登录名初始时与手机号一致。
系统的会员卡用账户来表示，一个会员卡代表一个账户，用户绑定一个账户后，就变成了客户，客户是用于付款的实体。
张三、张三的父母和孩子都是消费者，对应于consumer表中的一条记录，当用户登录后，会自动绑定自己缺省的consumer。当张三想要给自己的父母咨询时，其可以绑定父母的consumer，然后进行咨询，这时与医生聊天时，就会显示张三父母的头像，点击头像就可以显示张三父母的病历。系统记录本次咨询记录时，记录user_consumer_id作为咨询者信息，如果医生想要联系患者，可以通过这条记录，找到用户，然后通过用户信息，联系到患者。如果联系不上的话，还可以查看该consumer下还有哪些用户，然后依次与这些用户联系，达到最终联系患者的目的。
华丽的分隔线
******************************************************************************************************************************************************************************
希望大家多支持，有大家的支持，我才能走得更远，谢谢！
银行账号：622202 0200 1078 56128 闫涛
我的支付宝：yt7589@hotmail.com
最老程序员创业开发实训14---PHP---用户体系数据库设计
标签：
原文地址：http://blog.csdn.net/yt7589/article/details/48520467
