关于我的SaaS（多租户）自定义字段数据库设计的反馈

Question

我知道这个话题可能会碰到几次，但必须再次提出来，而其他解决方案似乎并不理想或过于复杂，以致于全栈开发人员组成的小型团队无法设计和创建...

SaaS工具的想法是拥有带有动态自定义字段和不同类型值的动态表，我们曾考虑使用“ force.com/salesforce.com”示例，但看起来太复杂了，无法保持向前发展，还编写了一些具有很大抽象级别的报告，因此我们想到了一个简单的主意，但必须确保这是一种好方法。

这是我们今天拥有的架构（分几个步骤）。

1. 每个租户在集群上都有自己的独立数据库（Postgres 12）。
2. TABLE表，用于保留所有这些表作为参考，此实体与META表具有ManyToOne关系，与DATA表具有OneToMany关系。
3. [META表用于元数据配置，与FIELDS具有OneToMany关系（具有字段名称以及字段类型，例如TEXT/INTEGER/BOOLEAN/DATETIME等，属性值-作为字符串，仅作为参考）。
4. DATA表与TABLES和50 character varying列具有ManyToOne关系，其名称类似于：attribute1...50，它们可以为NULL。

今天的示例流程：

1. [当用户想要打开表格数据时，例如“ CARS”，我们使用所有FIELDS加载META表（以获取此查询的字段）。用户指定了他要针对的查询：Brand, Class, Year, Price列。
2. 我们正在通过逻辑检查，并在META> FIELDS表中查看品牌，类别，年份和价格的引用，因此我们知道Brand = attribute2, Class = attribute 5, Year = attribute6 and Price = attribute7。
3. [我们将他的请求解析为一个查询，例如：SELECT [attr...2,5,6,7] FROM DATA，然后如果用户决定根据此数据（例如， Year > 2017 AND Class = 'A'我们使用CAST()的SQL功能，例如SELECT CAST(attribute6 AS int) AND attribute5 FROM DATA WHERE CAST(attribute6 AS int) > 2017 AND attribute5 = 'A';，因此我们实际上可以支持大多数SQL原则。

但是向前迈步，我们有点害怕：

• 为更多租户管理这样的环境，同时我们将拥有更多表(e.g. 50 per customer, with roughly 1-5 mil per TABLE (，允许的最大值为500万，对于更大的数据，我们有BigQuery ) which is giving us 50-250 mil rows in single table DATA_X)，这可能会影响查询的性能，尤其是当我们给使用某些抽象语言管理简单的WHERE语句（较少，相等，空等）开发的GET CARS [BRAND,CLASS,PRICE...] FILTER [EQ(CLASS,A),MT(YEAR,2017)]与JQL（Jira查询语言）相似。
• 交易锁定，因为我们允许将CSV批量上传到DATA_X，因此一旦他们想要加载，例如1GB的数据，它会锁定该表，以供其他系统访问DATA表。
• 保留多个可能会影响空间的NULL列（目前，我们并不像创建TABLE时那样害怕，客户可以决定他想要多少列，因此，我们将这个TABLE分配给一个硬编码实体[C0 ]，其中数字对应于属性列的限制，并且那些实体是不同的，如果它们决定从5个属性切换到10个属性，我们也支持迁移选项，等等。

我们正处于超级早期阶段，因此我们可以/应该在扩展之前进行开发，因为我们知道这不是最佳方法，但是我们保留了它来为小客户运行该项目，现在工作正常。我们也在考虑JSONB对象，但这不是选项，因为我们想让获取数据保持简单。

您对此解决方案有何看法（fyi DATA在2个表中有PRIMARY键-（ID，TABLEID）并内置于CreatedAt列中，该列用于大多数查询，因此将最多有3个索引）]

如果看起来很糟，根据我分享的详细信息（基本上是无模式的RDBMS），您会推荐什么作为该解决方案的替代方案？

感谢您的任何建议或反馈！

我知道这个话题可能会碰到几次，但是必须再次提出来，而其他解决方案似乎并不理想或过于复杂，以至于整个堆叠的小型团队都无法设计和创建...

Answer 1

恕我直言，我预料到您想要连接表并使用强制转换等问题。