我正在开发一种(可能)大规模的跟踪软件,用于跟踪客户数据以及为与所述客户相关的任务创建的票证。本系统完全用PHP编写,数据库为MySQL。
系统当前支持多个“位置”(例如商店),每个位置都有自己的客户数据表(在同一数据库中,每个数据库可以托管到完全不同的企业安装)。例如:
store1_customers
customer_id | customer_firstname | customer_lastname
----------------------------------------------------
1 | John | Doe
2 | Bill | Bob
store2_customers
customer_id | customer_firstname | customer_lastname
----------------------------------------------------
1 | Jill | Smith
2 | Jimmy | Person
这非常适合将不同的地点分开以满足不同的业务需求。但是,我们遇到了这样的需要:为可以从任何位置访问的其他实例提供“全局”客户,同时将其他客户分开。
我能想到的两个选项是创建一个新的“global_customers”表,然后可以单独提取该表,或者将所有数据合并到一个大表中。
我对这两种方法都有顾虑。第一个要求在每个表中都有一个新列来引用客户以确定要从哪个客户表中提取数据。例如,store1_tickets
必须知道是从 store1_customers
还是从 global_customers
提取 1
的客户 ID。这似乎有点脏,我认为尝试执行多个 JOIN
查询会出现问题。
制作一张巨型表格的第二种方法让我在两个方面感到担忧:第一个是表格的大小(到目前为止,每个表格可能有超过 20k 条记录,并且“软件”的一个特定安装有 7 个位置”)。我知道由于 MySQL 的工作方式和处理方式,这一点可能没有实际意义。第二个问题是合并现有数据。我认为这是一场噩梦,因为每个表都有 1-20k 个客户 ID,我必须有某种方法来更改其他表中成千上万条现有记录,以匹配该表的新编号。
是否有更好的方法或更合适的方法来实现这一目标?如果这个问题看起来确实很主观,我很抱歉,但它确实归结为数据库问题以及如何以合理的方式处理数据。
最佳答案
将所有数据合并到一张大表中。这就是数据库的设计用途。
对于数据迁移,您最终将获得新的 key ,这是没有办法解决的。但是,您可以添加一个新列来存储“旧”ID。这只是与数据库规范化相关的一些痛苦。现在就接受痛苦,而不是坚持次优的数据库设计。
客户类型将是客户表中的另一列,可能(但取决于您的要求)这将是 CustomerType
表的 FK。
关于php - 多个客户数据库加上全局客户,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18643706/