可以有不同的实现方法,每种方法都取决于应用程序的性质,例如为每个用户提供的功能,涉及的每个用户数据以及这些数据的关系,涉及的每个用户数据的数量等.
方法1:单一应用数据库; 根据应用程序的功能/结构,多个表,但表保存所有用户的数据.例如,comments,permissions,categories等.
优点:简单的架构,简单快捷的检索和插入
缺点:如果表的大小过大或涉及复杂的索引,数据库操作可能会变得昂贵
方法2:单一应用数据库; 根据应用程序的功能/结构的多个表; 每个用户都有自己的表集,可能由user_id标识.例如,对于USER_ID = 1,表可能是comments_1,permissions_1,categories_1等.
专业人士:再简单的架构; 易于识别要查询特定用户的表; 因为表只包含特定用户的数据,所以至少有一个WHERE子句(其中user_id = xx); 较小的表格,因此检索速度更快; 繁忙时段锁定冲突的可能性更小
缺点:需要更多维护; 添加需要添加新列或表的更新功能,需要对所有用户表集进行架构更改;
方法3:每个用户多个应用程序数据库
专业人士:用户之间100%的数据隔离; 如果每个用户都需要定制功能,那么很容易调整数据库架构; 易于跨多个服务器拆分数据库以实现负载平衡;
缺点:复杂的架构; 需要更多的维护; 更难以存储公共或共享数据 - 可以将数据复制到每个用户数据库,也可以维护公共数据库.
我认为如果架构有效设计,以便在更快的SELECT/INSERT和每个表的数据量之间保持平衡,第一种方法应该适用于100-10000个用户.但是,它需要很多数据库调优和智能索引.
方法2和方法3都很好,但从我的角度来看,方法3更好,因为它给你更多的灵活性.实施可能需要一些时间,但并不难
此外,SQLite似乎不适合这样的实现.我会建议一个像MySQL这样的关系数据库.
希望上面提供一些实现的见解,并帮助您决定什么最适合您的应用程序.
| 归档时间： |
|
| 查看次数： |
414 次 |
| 最近记录： |