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

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

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

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

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