我们在很多情况下,可能都是某种组织的会员,如健身、游泳馆、超市、美容店等其他连锁店,这些针对会员的管理和消费管理,从而提供给会员更多的优惠,一般通过积分的方式实现。本文主要从一个开发者的角度,对会员系统进行的设计开发进行剖析,希望能与大家一起探讨,实现更多的思想碰撞。
如果系统是在一个店铺使用的,那么使用单机版本的操作模式即可,如可以使用Winform + SQLite/Access方式,实现数据的访问,并且方便软件复制和备份工作,如果需要性能好一点或者数据更加安全一点,可以采用独立的数据库方式,如采用一个独立的机器部署SqlServer数据库或者Mysql数据库,Oracle数据库就没太大必要了。
如果系统是在一系列连锁店中使用的,那么可以采用Winform+WCF服务方式,实现数据的分布式访问方式,这样数据就不会保存在本地,和B/S通过浏览器的方式很类似,但是Winform客户端能提供更丰富的界面体验效果。当然,我们每一家的连锁店就需要能够上网,随时进行数据的交换处理。
还有一种方式,是离线式的服务,就是弥补第二种方式在断开网络的时候不能工作的缺点,这种方式即使在网络断开,也能照常运营,网络通畅的时候,通过手工进行数据的提交就可以了。由于现在网络一般比较方便,所以这种方式一般采用的不多,只在特殊情况下采用。
我们知道,会员管理的主要目的就是以会员为中心,实现相关数据的管理。会员管理包括有会员本身的信息管理、会员收费管理、积分管理(积分增减、积分兑换、积分转账)、挂失管理、换卡管理、余额转账、商品管理、消费管理等等,围绕着会员管理展开,通过多个职能操作,实现相关数据的录入和管理。
数据库的设计,也主要是围绕着会员信息进行的,会员信息是作为所有会员相关记录的外键引用。为了避免数据库表的阅读困难,会员管理的相关表,使用“MS_”前缀声明。
除了以下的表外,还包括了会员的打折设置信息,积分奖励设置,以及用于会员消费的商品信息,及会员消费的记录信息(包括消费主表和明细表记录)。
为了篇幅的介绍,我主要列出会员的主表信息作为讨论参考。
表主要使用字符型的ID作为表的主键,保存的时候,ID自动使用GUID作为数据存储,由于考虑了可能多个连锁店的情况,因此,我们需要增加一个Creator, CreateTime, Editor,EditTime, Dept_ID, Company_ID的通用字段,方便存储用户的相关表记录信息,这样我们在数据过滤以及报表查询的时候,会方便很多。
当然会员的信息还可以扩展更多,我们一般是以一个通用的会员管理来实现这个模块,从而可以在整个大系统中进行整合和使用。而一般我们都有自己的平台模块积累,在业务层只需要整合现有的一些底层模块作为支持,业务系统我们独立开发即可,大概的构造如下所示。
当然,我们随着系统的开发,我们可能需要整合两个以上的系统(或者底层业务模块)到一个大系统里面,这种要求就需要我们所有的系统模块,都可以通过松耦合、插件化整合的方式实现使用的。
本文主要介绍一个会员系统开发的整体思路和设计,随着开发的深入,可能会继续分享一些相关的开发心得。