【IT168 专稿】连锁酒店因为其成本、市场竞争等优势，迅速扩张，逐渐形成了与传统酒店相抗衡的局面。确实，连锁酒店行业，比起传统酒店，在运行的成本、市场认可度等方面具有很大的优势。从管理成本与管理效率的角度考虑，信息化的应用在这里起着很重要的角色。当然，任何一个信息化系统，后台都离不开数据库的支持。在这篇文章中，笔者会结合实际的项目经验，谈谈在连锁酒店行业中，该如何选择数据库。

　　一、连锁酒店运行的业务模式

　　在谈到数据库选型之前，笔者需要先介绍一下连锁型酒店其主要的业务模式。因为后续数据库的选型就是根据业务模式来展开的。总的来说，其连锁型酒店运营主要有三种模式：集团式运营、会员卡式运营和独立性运营。不同的业务模式，对于信息化的要求是不同的。所以对于后台数据库的选型，也有很大的差异。在后续的分析中，笔者将结合不同业务模式的特点，针对性的提出数据库选型的要点。希望这些内容，能够对各位读者有所帮助。

　　二、独立性运营连锁型酒店的数据库选型要点

　　独立性运营的连锁酒店，其实只是花钱买了一块牌子。当然，有时候也会引进一套管理方法，包括信息化管理软件。独立性运营的连锁酒店，其核心的特点就是，无论从业务上，还是财务上，与总部都是独立的。如具有独立的法人资格、有独立的定价权、总部不用在线查看酒店的财务状况等等。由于其业务特性的不同，反映在信息化管理软件，也有不同的要求。各个连锁型酒店的管理系统，基本上不需要进行数据的同步。酒店总部也不需要在线查询酒店的运营状况。再某些情况下，这种业务模式下的连锁型酒店，可能需要根据业务量，给总部一定比例的提成。此时也只是每个星期或者每个月，给总部一个财务报表即可。此时一般的做法是，连锁型酒店的财务人员，按一定的周期从系统中拉出一张报表，然后发送给总部。由于各个连锁型酒店使用的是相同的信息化管理系统，报表导出的格式是相同的。在总部可以很方便的将他们导入系统，进行业务分析和费用的计算。

　　这种业务模式的示意图如上图所示。各个连锁型酒店的信息化管理系统相互独立。彼此之间不需要进行数据的同步。针对这种情况，笔者给出的数据库选型意见如下：

　　1、开源、免费的数据库。以降低成本、提高数据库的稳定性。针对某个特定的连锁企业，一般只需要一台数据库服务器即可，即没有分布式部署的需要。为此根据笔者的经验，认为开源的免费的数据库已经够用了。如MySQL等等，已经可以满足日常工作的需要。这些开源的数据库，不仅免费。而且因为开源，其稳定性也比较高。可以帮助连锁型企业降低信息化管理的成本。其实做技术的人都知道，一般黑客等进行攻击，都有一定的目的性。如喜欢攻击那些商业性的软件。像微软的操作系统等等。但是对于一些开源的系统，往往不会进行攻击。这有多方面的原因。如使用范围比较窄、出于对支持开源的技术人员的尊重(其实很多黑客本身可能就是开源圈子里的人)、没有利益可图等等。所以开源的软件，包括操作系统、数据库管理系统等等，比起商业软件来说，安全性都是比较高的。以MySQL和SQL Server为例，前者的安全性与稳定性比后者要高。

　　2、方便管理。众所周知，连锁型企业出于成本的考虑，往往不会单独设置信息化团队。其信息化实力是比较薄弱的。根据笔者的经验，这种独立运营的连锁酒店，一般都没有专业的数据库管理员。其信息化的日常运维也往往是外包给其他公司来做。在这种情况下，数据库的选型就需要考虑维护成本的问题。选择的数据库应该是比较容易维护的。笔者企业的一部分客户就是这种独立运营的连锁型酒店。笔者给他们配套的数据库一般都是小型的数据库，可以直接嵌入到应用程序中的。简单的说，这个数据库可能只是应用程序中的一个文件。在应用程序安装过程中，会直接安装并进行相关的配置，而不需要单独安装。相关的维护工作，如数据备份、数据恢复等等，都是在应用程序界面上直接完成，而不需要在数据库中进行维护。对于用户来说，这个数据库就好像是不存在的。

　　3、跨平台的考虑。独立运营的连锁型酒店，总部对于其的控制力量是比较薄弱的。从信息化上考虑，其最多只提供一套信息化管理系统。至于其硬件的投资、操作系统的使用等等都没有限制。如笔者以前遇到过一个连锁型酒店的客户，其下面各个酒店，在操作系统上有使用微软的，也有使用Linux或者CentOS操作系统的。有的酒店为了充面子，给前台使用的还是苹果的电脑与操作系统。由于缺乏统一的采购与控制，导致各个酒店所使用的操作系统与硬件平台各有不同。这对于信息化管理软件来说，也提出了一个很大的条件。其中对于数据库来说，就要求其能够支持不同的操作系统平台。如至少要在微软、Linux、苹果等操作系统内核上，都可以使用。否则的话，就可能会对一些连锁型酒店造成不利的影响。

　　总之对于这种独立性比较高的连锁型企业，对于数据库的技术要求是比较低的。并不要求有分布式部署、数据库冗余、数据同步等高级的功能。其核心的需求就是稳定、维护方便、成本低廉、易于使用。为此笔者推荐使用开源的数据库系统。甚至就是文件数据库，可以很好的与应用系统进行整合。数据库对于用户来说，是透明的。

　　三、会员卡管理的连锁型酒店

　　通过会员卡充值、然后消费，这种连锁型酒店的运营模式也越来越普遍。因为通过会员卡消费，可以吸引很多回头客。而且在促销方案的管理上，也非常的方便，如充1000元实际消费1200元等活动。在实际工作中，会员卡的消费又可以分为三种情况。一种情况是哪里办卡、哪里消费的情形。如在酒店A充的值，只能够在酒店A消费。这种情形由于不能够对客户带来很大的吸引力，所以现在使用的比较少。第二种情况是在某个地区内通用。如在浙江地区内的所有连锁型酒店，会员卡内的金额可以通用。这第一种情形稍微好一点，扩大了使用的范围。但是其地区限制还是比较严重。如在浙江办的会员卡并冲值，但是到广州去出差就不能够使用了。所以这种情形在实际项目中也逐渐在淘汰。最后一种情况是全国通用。简单的说，只要在国内任何一家连锁型酒店办的会员卡，在国内其它的同品牌的连锁型酒店，都可以进行消费或者冲值。这种情形由于没有地域的限制，很受经常需要出差人员的欢迎。而且现在不少的企业，为了加强对出差人员的管理，都是以企业的名义办会员卡的。其市场的效益正在不断的显现出来。

　　这种会员卡消费的模式，对于信息化系统也提出了比较高的要求。简单的说，其在酒店A进行会员卡冲值，在酒店B中要能够马上体现出来。这酒店A与酒店B可能在同一个城市，也有可能天南地北，一个在北京、一个在广州。可见，会员卡的管理模式，对各个酒店的信息化系统之间的协作提出了比较高的要求。并且随着第三方支付平台的普及，用户也可以通过第三方支付平台，直接往会员卡中冲值。这就好像通过支付宝给手机冲值一样，对于数据的即时性会有比较高的要求。其实这种即时性的要求，最终是体现在对数据库的要求。如下图所示，是对会员卡管理模式数据库架构的示意图。针对会员卡消费模式的连锁型酒店，笔者提出如下的选型意见。

　　1、对数据的同步有一定的要求。由于会员卡冲值与消费的存在，对于数据库的数据同步有一定的要求。这里需要注意，笔者用了一个限定词“一定”。简单的说，其数据的同步往往只限于“会员卡”的冲值消费记录。由于这种运营模式的连锁性酒店，总部对于下面各个酒店的管理权利还是非常有效的。如下面各个酒店，可能有独立的定价权，或者独立的促销活动。会员卡在这里，可能只是起到一个“银行卡”的刷卡作用，而不不是代表总部对下面各个酒店就有很高的控制权限。针对这个特点，就要求各个酒店的数据库与总部的数据库有对接的要求，但是由于其数据量的传输是比较小的，所以对于数据库的性能要求并不是很大。如只需要酒店与总部的数据库数据能够对接，而对于如何进行对接、双方的数据库品牌并没有很高的限制。笔者以前做过一个项目。其总部使用的是Oracle数据库系统，而下面各个门店则使用的是MySQL数据库。这就好像长江与各个支流之间的关系。长江就好像是总部，其吞吐能力要比较大。不仅要有“海量”，能够迅速的将数据注入到各个门店的数据库中。而且还要有“度量”，各个门店的数据在短时间内汇集到总部的数据库，要能够迅速的作出反应。从这个分析中可以看出，会员卡消费的连锁型酒店，对于总部的数据库要求比较高，但是对于各个门店的数据库要求还是比较低的。为此门店从部署的成本考虑，没有必要选择与总部相同的数据库系统。

　　2、不同品牌数据库的兼容性。在第一点说过，会员卡消费的连锁型酒店，从经济效益的角度考虑，并不需要追求门店与总部数据库的统一。毕竟总部一般是使用Oracle等大型的数据库系统，而门店一般都是使用小型的、甚至是免费的数据库。而另外一方面，门店的数据库系统与总部的数据库系统之间又要进行一定量的数据交换，虽然说这个量并不是很大。这对于门店的数据库系统也提出了一定的要求。至少要求门店的数据库系统，能够与总部的数据库系统相互兼容。在实际项目中，一般会采取两种方式。一是对数据库提出比较苛刻的要求，即两者要求完全的兼容。如两个数据库全部采用国家通用的字符编码格式，并且在数据库设计过程中，也遵循相同的规则。一般采取这种方式的企业，都是在加盟的同时提供信息化管理软件。并且这个信息化管理软件，是集团统一进行设计开发的。只有如此，才能够具有相同的设计规格。另外一种方式，就是采取中间件的方式。如集团的数据库与门店的数据库可以有不兼容的规则。不过无论是从总部发出数据，还是从门店发出数据，都需要有一个转换的过程。如总部在接受门店的数据时，需要有一个转换的过程。如将精度的转换等等。然后再更新数据库中的数据。由于中间多了一个转换的过程，就可能导致数据的丢失。笔者是比较倾向于第一种处理方式。当然这个处理方式对于数据库的选型提出了一定的要求。至少两个数据库，都要能够支持国际化标准。如此的话，就可能将一些文件型的小型数据库排除在外。

　　四、集团型连锁酒店运营模式

　　比会员卡管理再高一级的连锁型酒店，就是集团型的运营模式。注意，笔者这里只是从管理的角度来讲，并不是代表法律意义上的集团控制。相比会员卡管理而言，集团型运营的连锁酒店，总部对各个门店的管理级别可能会比较高。如像速八等商务连锁型酒店，其定价权在与总部，而不在于各个门店。至少各个门店如果自行调整价格，需要有总部的审批。如不少商务型酒店，其在全国的价格是同一的。还有不少酒店，其在各个地区的价格是统一的。为了加强管理，总部会对各个门店的数据要求提出比较高的标准。如各个门店不能够私自更改价格，只有总部或者地区一级的价格部门才能够更改价格或者折扣率。以避免同一个地区之间的恶性竞争。

　　还有一种情况就是真的具有集团运作的背景。如外婆家连锁型酒店，其采用的是直营的方式。各个地区的外婆家虽然都有独立的法人身份，但是同属于一个集团。从信息化管理的角度讲，就会设计到财务报表的合并要求。其实类似的对于信息化管理的要求，最终大部分要求都是直接反映在数据库上的。

　　1、集团型运营模式的连锁酒店，一般情况下不会在各个门店设置单独的数据库。如此的话，数据比较难以控制。最多只是在门店设置一个数据的缓冲区。以免因为网络堵塞造成不必要的麻烦。集团总部往往是在一个地区设置一个数据库。如可能将这台数据库服务器委托给当地的电信部门托管。然后各个门店的管理系统直接连接到地区一级的数据库，进行数据的交互。每隔一定时间，如每隔4个小时，地区一级的数据库会将数据与总部之间的数据进行交互。可见，在集团型运作模式下，其数据库的选型主要是集中在地区一级和总部一级。为了提高数据交互的效率，通常情况下，地区一级的数据库产品与集团总部的数据库是相通的。这主要是因为其不但要保障数据的即时性，同时也需要考虑数据的安全性。如总部的数据库与地区一级的数据库除了数据同步的需要之外，还肩负着“冗余备份”的要求。如华东区的数据库如果出现问题，那么华东区下面各个门店的管理系统会自动连接到华北区或者总部的数据库管理系统。对于用户来说，这个切换的过程是透明的。同时因为以前有冗余备分，所以华北区数据库中的数据与华东区数据库中的数据其实是相同的(可能有一定的时间差，这主要看其数据同步的频率)。从而最大程度的降低因为华东区数据库的崩溃，给其下面各个门店带来的负面影响。

　　2、要能够满足兼并的需要。集团型的连锁酒店，有不少是通过兼并来扩展市场的。而很少像外婆家那样，通过直营方式来拓展市场份额。因为后者不仅拓展的速度慢，而且对于企业的资金有比较高的要求。通过兼并来扩展市场，就会碰到不同管理系统之间的整合问题。如集团A兼并了另外一个连锁型酒店B。此时连锁型酒店B往往有自己的管理系统。出于平滑过渡的需要，在短时间内是不会更换连锁型酒店B的管理系统的。这就要求数据库能够支持这种兼并的需要。通常情况下，一般是集团公司采用一些平台工具，将连锁型酒店B中的数据抽取出来，再放到他们自己的数据库中去，进行统一的分析，包括报表的集成。当然，这么操作有一个前期，即这个平台与对方所使用的数据库要能够整合。利用专业的术语来说，要有数据库的接口，如ODBC等等。否则的话，就很难抽取数据。

　　其实对于集团型的连锁型企业来说，数据库的选型还是比较简单的。这主要是因为其选择的范围比较窄。如只有Oracle、DB2等几个有限的数据库可供选择。再说集团型的连锁酒店，其资金并不是大问题。为此他们更多的是考虑性能、安全性与稳定性。所以选型相对来说，比起上面两种情况，会更加的简单。

        总结

　　最后笔者需要强调一点。随着云计算平台的普及，数据库及应用软件开始走向SaaS的模式。即作为企业一方，并不需要关注到底其实用的是什么数据库系统。因为数据库以及信息化管理系统被人已经搭建好，连锁型酒店只要看着合适直接租过来用即可。做一个形象的比喻。在云计算平台下，企业不用自己造房子、也不用装修房子，而是直接租房子。最多就只是买些家具就可以拿来使用了。简单的说，就是服务提供商已经搭建起了一个平台(数据库选型、配置和应用软件的部署等工作在这个平台上已经实现)。连锁型酒店只需要在这个平台上，进行一些简单的个性化配置即可。这也就是说，数据库的选型等工作将交给专业的团队来完成。不需要由企业去关心。