卡的应用不外乎就是计费与身份识别之用。所谓“一卡通”就是同一张卡片，每一用户只需要一张卡，在多种不同功能管理中使用。这是用户对系统的基本要求，也是“一卡通”最主要的表现。一卡，并不是一种固定的卡，既可以是IC卡，也可以是ID卡；更不能指定某一家厂商的卡。一卡通系统可通过灵活的接口、统一的标准，很容易把各种类型的卡有机地结合起来，在同一系统中，可同时使用不同的卡（如：ID卡，Mifare-One卡同时使用）。功能方面，一卡可以用来停车、开门、考勤、巡更、身份识别等。
在“一卡通”系统数据库设计中，传统的设计方法是将“一卡通”系统所有数据集中在一起的模式下进行设计（即“一库一卡通”，特别是同一商家的“一卡通”系统产品）。虽然具有：数据容易共享、数据一致性容易保证、数据检索方便等优点。但也有其致命的缺点：第一、不便于进行系统的应用升级与扩充。事实上，“一卡通”系统是一个不断创新与升级的系统，根据市场需求和软硬件相关技术的发展，“一卡通”系统将会有新的应用加入和老的应用的升级。一般情况下，“一卡通”系统的数据库需要作相应的变动与升级，由此造成“一卡通”系统数据的兼容性、一致性、独立性等问题将是非常突出，特别是针对一个运行比较久且比较大型的“一卡通”系统（如：某一大学城的“一卡通”系统）,数据量将是非常庞大的，由此产生的升级与改动成本将是很高的。第二、各应用子系统不可能都是同一家公司研发的，软硬件各自不同，其后台数据库不可能都集成在“一卡通”系统数据库中。但他们都使用同一张卡作为身份识别与计费的媒介。因此它与“一卡通”系统数据库之间需要一定的信息交换(如：卡的开户、挂失、解挂、注销、补卡等信息)。这时需要增加相应的人力、设备、技术实现与“一卡通”系统数据库相关数据的同步。在没有相关标准的情况下，其成本是很高的。
事实上，“一卡通”就是利用同一张卡作为各种计费与身份识别系统的媒介，这是“一卡通”系统的共性。各种计费与身份识别系统都有其自身的特点与属性。比如，“一卡通”系统中的餐饮收费系统与上机收费系统，一个是以食物量的多少来计费，一个是以时间量的长短来计费，其都有不同的特点与属性,在其后台数据库设计上也是有所区别的。这是“一卡通”系统的差异性。有了以上的共性与差异性，本人认为,“一卡通”信息系统数据库设计比较行之有效的方法就是“一卡多库”---以卡信息数据库为中心库，为每一个应用系统或模块建立一个专门的相对独立的数据库！这样的好处是便于增加“一卡通”系统的灵活性与独立性，便于“一卡通”应用系统的扩充与改造升级。但也产生另一个问题:由于各应用系统数据库的相对独立，必然导致卡信息数据库中的卡的开户、挂失、解挂、补卡、信息调整、注销等信息与各应用系统数据库中的相关信息同步问题，这是“一卡通”信息系统数据库设计必须考虑的重大问题！针对以上问题，本人认为,我们可以采取以下办法：1、在一定的时间内，各应用系统从卡信息数据库上传或下载相关信息，双方进行必要的更新！2、利用大型数据库服务器自身的分布复制技术实现相关信息的同步！以上的两种办法都要在“一卡通”系统各数据库相关表的表结构及相关的处理机制上建立"接口"（即一种标准）为基础。这种标准，为数据库设计提供了新的课题,因为，它考虑的是属于不同逻辑整体中的数据库与数据库的联系，而不是在同一逻辑整体下的实体与实体的联系，是一种区别于分布式数据库技术的系统架构方法。以下是本人认为一种比较行之有效的方案：以卡信息数据库为中心库(卡信息数据库记载的主要信息为：_____________________)，各应用系统数据库设置一个或几个有以下信息的基本表(__________________________________）。作为上传、下载或实现分布式复制之用！这种设计方法类似于联系为1:n的数据库逻辑结构设计方法。这里的“1”方实体指卡信息数据库，"n"方实体指“一卡通”各应用系统或模块数据库。这里的“外部键”则为以上那些确定的基本表。
