一卡通系统
一卡通的核心意义是子系统数据库的统一和发卡中心的统一，其突出特点表现为：一卡、一库、一网。
· 一卡：用同一张卡实现不同功能的智能管理，一张卡上通行很多功能不同的设备,同一张卡可用于门禁、考勤、消费、巡更、停车、电梯控制、通道门控制、图书借阅、医疗保健、会议签到等。；
· 一库：同一个软件、同一个数据库内实现卡的发放、卡的取消、卡的挂失、卡的资料查询、黑名单报警等统一管理；
· 一网：一个统一的网络。基于现存已综合布线的局域网络或基于TCP/IP的Internet网，系统将多种不同的设备接入同一个管理（发卡）中心, 集中授权，统一管理。
非一卡通系统带来的麻烦：
许多用户在实施一卡通系统时，可能采取分阶段实施的方式，例如先上考勤系统，过了一段时间又上门禁系统，再过一段时间又上食堂消费系统，在这过程中会发生很多情况，例如原来的厂家提供的产品种类不齐全，被迫从另外的厂家购买另外的产品，或者原来的厂家已经不存在了，等等原因造成了用户选择了多个不同的供应商的情况。而这些不同厂家的系统无法兼容，一般来说需要统一更换成同一家的产品，造成客户原来的购买的设备无法用，导致损失。
如果多个系统混用，可能会产生以下的后果：
多次发卡：由于多个软件、多个平台存在，就有多个发卡系统。为实现一卡通行，则必须要在每个厂家提供的系统中发一次卡。由于环节太多，一旦人员人员发生，将很容易造成错误或遗漏。在对卡进行挂失、更换、取消等作业时也会造成麻烦。
数据隔离：例如要查询考勤，就要到考勤机厂家提供的软件系统中查询，要查询消费记录，又要到消费机厂家提供的软件系统中查询，不仅仅是麻烦的问题，这会造成很多的错误。
维护困难，成本高：在系统出问题时经常会有供应商之间互相推诿的现象，这种情况发生的可能性高达90%以上，可以说，只要出了问题，几乎可以肯定的是，这种情况避免不了！而且很多问题不是单个供应商能解决的问题。
一卡通系统的优势：
一卡通系统可以解决不同厂家不同设备之间的衔接问题，这也是很多用户形成的历史问题。
一卡通系统已经得到了很大的扩展，发展出了许多细分市场，例如学校一卡通，医院一卡通，城市（地铁公交车）一卡通，企业一卡通等等，这些应用都在很多细节方面有所不同，而一卡通系统的优势在于企业、校园一卡通市场，凭借对企业校园管理的高度理解，一卡通系统也很好地解决了企业校园复杂的要求。
一卡通系统用大型的数据库系统作支撑，性能得到保证。市场上多数用卡的系统多数是小型数据库，例如sql server ，access等，支持大型数据库oralce的则不多，对于企业人数5000人以上的企业，每天产生的数据量非常庞大，如果数据库的性能不高，难以有效地管理，另外，也很难和企业的各种大型应用系统如ERP、CRM、人力资源管理系统、OA系统等进行整合。
一卡通系统能够很好使一卡通相关管理人员和员工之间很好地进行互动，软件一般是采用B/S架构开发，对于信息化管理程度比较高的企业，采用一卡通系统更加适合。例如如果企业本身需要OA、ERP或人力资源管理系统等和一卡通系统进行整合，那么一卡通系统是最好的选择。
一卡通系统的常见应用：
考勤系统
门禁系统
图书馆借阅系统
人力资源管理系统
食堂消费系统
控水消费系统
机房上机收费系统
银行圈存转帐系统
个人不同见解:
由于“一卡通”各应用子系统之间的联系是弱联系，之间除了用同一张卡作为计费或身份识别之外基本上没什么联系.。所以本人对"一卡通"系统数据库设计上的“一库”原则不敢苟同，对此本人有以下想法:
“一卡通”信息系统数据库设计初步探讨
概要：卡的应用不外乎就是计费与身份识别之用。所谓“一卡通”就是同一张卡片，每一用户只需要一张卡，在多种不同功能管理中使用。这是用户对系统的基本要求，也是“一卡通”最主要的表现。一卡，并不是一种固定的卡，既可以是IC卡，也可以是ID卡；更不能指定某一家厂商的卡。一卡通系统可通过灵活的接口、统一的标准，很容易把各种类型的卡有机地结合起来，在同一系统中，可同时使用不同的卡（如：ID卡，Mifare-One卡同时使用）。功能方面，一卡可以用来停车、开门、考勤、巡更、身份识别等。
在“一卡通”系统数据库设计中，传统的设计方法是将“一卡通”系统所有数据集中在一起的模式下进行设计（即“一库一卡通”，特别是同一商家的“一卡通”系统产品）。虽然具有：数据容易共享、数据一致性容易保证、数据检索方便等优点。但也有其致命的缺点：第一、不便于进行系统的应用升级与扩充。事实上，“一卡通”系统是一个不断创新与升级的系统，根据市场需求和软硬件相关技术的发展，“一卡通”系统将会有新的应用加入和老的应用的升级。一般情况下，“一卡通”系统的数据库需要作相应的变动与升级，由此造成“一卡通”系统数据的兼容性、一致性、独立性等问题将是非常突出，特别是针对一个运行比较久且比较大型的“一卡通”系统（如：某一大学城的“一卡通”系统）,数据量将是非常庞大的，由此产生的升级与改动成本将是很高的。第二、各应用子系统不可能都是同一家公司研发的，软硬件各自不同，其后台数据库不可能都集成在“一卡通”系统数据库中。但他们都使用同一张卡作为身份识别与计费的媒介。因此它与“一卡通”系统数据库之间需要一定的信息交换(如：卡的开户、挂失、解挂、注销、补卡等信息)。这时需要增加相应的人力、设备、技术实现与“一卡通”系统数据库相关数据的同步。在没有相关标准的情况下，其成本是很高的。
事实上，“一卡通”就是利用同一张卡作为各种计费与身份识别系统的媒介，这是“一卡通”系统的共性。各种计费与身份识别系统都有其自身的特点与属性。比如，“一卡通”系统中的餐饮收费系统与上机收费系统，一个是以食物量的多少来计费，一个是以时间量的长短来计费，其都有不同的特点与属性,在其后台数据库设计上也是有所区别的。这是“一卡通”系统的差异性。有了以上的共性与差异性，本人认为,“一卡通”信息系统数据库设计比较行之有效的方法就是“一卡多库”---以卡信息数据库为中心库，为每一个应用系统或模块建立一个专门的相对独立的数据库！这样的好处是便于增加“一卡通”系统的灵活性与独立性，便于“一卡通”应用系统的扩充与改造升级。但也产生另一个问题:由于各应用系统数据库的相对独立，必然导致卡信息数据库中的卡的开户、挂失、解挂、补卡、信息调整、注销等信息与各应用系统数据库中的相关信息同步问题，这是“一卡通”信息系统数据库设计必须考虑的重大问题！针对以上问题，本人认为,我们可以采取以下办法：1、在一定的时间内，各应用系统从卡信息数据库上传或下载相关信息，双方进行必要的更新！2、利用大型数据库服务器自身的分布复制技术实现相关信息的同步！以上的两种办法都要在“一卡通”系统各数据库相关表的表结构及相关的处理机制上建立"接口"（即一种标准）为基础。这种标准，为数据库设计提供了新的课题,因为，它考虑的是属于不同逻辑整体(“一卡通”各应用子系统之间的联系本来就是弱联系，之间除了用同一张卡作为计费或身份识别之外基本上没什么联系)中的数据库与数据库的联系，而不是在同一逻辑整体下的实体与实体的联系，是一种区别于分布式数据库技术的系统架构方法。以下是本人认为一种比较行之有效的方案：以卡信息数据库为中心库(卡信息数据库记载的主要信息为：_____________________)，各应用系统数据库设置一个或几个有以下信息的基本表(__________________________________）。作为上传、下载或实现分布式复制之用！这种设计方法类似于联系为1:n的数据库逻辑结构设计方法。这里的“1”方实体指卡信息数据库，"n"方实体指“一卡通”各应用系统或模块数据库。这里的“外部键”则为以上那些确定的基本表。
[url=http://www.laisoft.com/card/485.htm]
