我们是一家 SaaS 公司，从他们选择的存储解决方案中提取客户客户数据，并在我们的服务器上处理数据，让客户登录以查看具有我们增值功能的客户数据。
多个客户
当我们通过各种 API 和源进行拉取时，我们将数据的本地副本存储在我们的 MySQL 服务器上。我们当前（公认有缺陷）的架构是将检索到的数据存储在各个客户端表中，这些表除了名称之外的所有内容都相同。这是 a) 意外增长的结果，b) 最初尝试完全隔离客户数据，以便一个客户从共享客户表中看到另一个客户的数据的可能性正好为 0%（我们的客户通常是竞争对手）。所以我们有：
table client_ABC
- field A
- field B
- ...
- field N
table client_XYZ
- field A
- field B
- ...
- field N
随着我们的扩展，上面的内容可以预见地落在了它的脸上——我们正在添加几十个相同的客户端表，对模式的任何更改都是一场噩梦。我倾向于将数据组合到一个表中并添加一个“客户”列，但这个问题的第二部分可能会使事情复杂化......
不一致/唯一的客户数据
我们的第二个问题是，我们提取的数据在客户端之间几乎没有共同点。每个客户的数据都有一些共同的元素（姓名、电子邮件），但其余的数据是不同的，因为一些客户的数据有关联的地址信息，一些有详细的购买记录等。
我们当前的解决方案是让我们的客户表在每个上方都包含许多通用的“元”字段，然后我们逐个客户映射这些字段，这样当我们的业务逻辑显示客户 ABC 的客户时，我们就有：
customer ABC
- name -> name
- email -> email
- street -> meta_1
- city -> meta_2
对于客户 XYZ，我们可能有：
customer XYZ
- name -> name
- email -> email
- last purchase -> meta_1
当我们添加客户时，我们发现那些客户数据不完整（即完整的销售记录），上述解决方案失败了，因为我们现在需要添加自定义的二级客户表来存储额外的数据。
请记住，所有这些都通过共享代码/业务逻辑向所有客户端公开。
一种想法是将单个客户数据存储在一个二级结构中，比如 JSON，在一个通用的“数据列”中，这样我们就有了类似的东西：
table client
- name = "Bill Smith"
- email = "bsmith@example.com"
- data = { "street": "123 Fake St", "city": "Big City"}
这里的问题是我们如何进行全文搜索、索引等。
任何有关如何开始解决这两个相关问题的建议表示赞赏！