我们是一家 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"}
这里的问题是我们如何进行全文搜索、索引等。
如有任何关于如何着手解决这两个相关问题的建议，我们将不胜感激!
最佳答案
根据 jsoft 的建议，我们将使用 Mongo - 满足我们可变的客户端架构要求的完美解决方案。
使用 Mongo 的一些原因包括:
关于mysql - 客户端数据存储的可能架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14417836/