有关(过度复杂？)模式的SQL体系结构建议

我目前正处于数据库设计阶段，正在开发产品的新部分。为此，我需要进行“健全性检查”或提供一些建议，因为我对设置的某些部分并不感到过分自信。

一点背景信息

我们正在开发的产品是所谓的“营销ROI最大化系统”。它处理大数据并处理/增强/丰富大量信息，然后再将其发送到不同的营销 channel 。简而言之，这就是它的作用。

问题域

该系统目前还没有完全具备对数据进行良好验证的功能，并且每天都在被“营销”人员和我们所谓的“自助”客户“滥用”。考虑到我们CEO的新google产品列表广告网络，我的任务是为如何处理在Google购物 channel (称为PLA；产品列表)中使用的{information/data}提供一个好的解决方案广告)。

这是问题:
我们的产品不提供任何形式的验证(阅读:遵守网络的特定要求)，PLA基本上通过项目分类(每个类别都定义了必填/可选字段)完全围绕数据完整性。应该采用特定格式(甚至可能取决于链接的类别；我尚不知道:P)。

您猜对了，我们对当前设置有些困惑。强制执行此类“严格”产品Feed根本是不可能的。通过让我们的营销人员和自助服务客户创建并发送数据到PLA，将意味着在99％的时间内解决错误/发现问题。由于这只是一家小公司，所以我宁愿看看真正的问题。那意味着；试图创建一个可用于PLA营销事件的真实验证系统。

需要做什么

我一直在与我们的营销人员和客户交谈，以了解用例是什么以及需求是什么。这些可以总结在以下列表项中:

输入提要中的每个项目都需要“分类”到google PLA类别(请参阅“链接”部分以查看可以映射到哪些类别。)

需要为每个“类别”的每个字段设置验证

每个项目的每个字段都需要分配/映射到所选类别中定义的字段。

附加说明

现在，我不想担心诸如“我们如何将“项目”链接到“类别”或“字段”与“类别字段定义”之类的事情之类的事情。这些“动态的事情”将由一个ECA规则系统，该系统将在其他时间开发(为什么问？该系统正在按计划处理/处理数据，因此需要定义和存储每个操作以供以后使用)，不必担心实现细节目前。

而且，具体的特定实现通常是通过使用动态属性(例如，由数据类型定义的字段上的属性等)来实现的。目前，EAV系统也不是我的主要重点。 (如果您看一下数据库设计，上面给出的用例将更有意义)。

我目前的设计

首先，让我使用主要实体来说明我的SQL结构:

schemas;定义“类别”的抽象方法，请考虑PLA类别

fields;字段定义(在schema中)

datatypes;一袋类型。 (主要用于为上述字段提供一些数据完整性)

valueConstraints;一袋约束定义(不是实现!)。

现在。到目前为止，一切都很好。这是我有点担心的事情:
valueConstraints通过N:M表(datatype_valueConstraints)绑定(bind)到数据类型，但是几乎每个用户生成的数据类型仅由可用valueconstraints的子集组成，“Price”数据类型没有意义可以有一个“电子邮件”约束。.但是，有一个“最小”和“最大”约束确实有意义，因为价格始终是一个数字。为了清楚起见:datatype_valueConstraints保留每种数据类型的“可能” valueConstraints。

原始类型->约束值关系也会发生相同的问题。基本上，数据类型必须包含“primitiveType”(在我的情况下，是原始类型表的外键)。基本类型管理要选择的valueConstraints。 primitiveTypes和valueConstraints不被认为是用户生成的，因此暂时是夹具数据。

不明白吗这是一个示例工作流程(“PLA/服装”模式的(部分)设置):

添加数据类型“图像”，将{原始类型设置为TEXT}

选择以下要使用的ValueConstraints(特定于TEXT)

“URL”(确保它是http | https或类似的名称，不知道)

“MinLength”(确保它在那里)

“Regex”(允许某些图像扩展名..或类似的东西)

添加字段定义“imageURL”，将{数据类型设置为“image”}

数据类型特定的配置，即，填写约束声明数据(与EAV模式相关)。 “MinLength” = 14，“Regex” =“*(gif | jpg | png)”等。

因为数据类型是原始的“TEXT”，所以用户只能从valueConstraints中选择(并且由于树(如数据类型系统而继承))。

正确设置数据类型后，我们可以对模式中的多个字段使用数据类型“image”(如果需要的话)。例如; “PLA/服装”模式可能需要“其他图像”字段。现在，通过使用可能具有不同约束配置的“图像”数据类型重用，这是完全可能的。

可视化的SQL表布局，显示关系(关于文本墙的头脑 Storm ):

我的数据库模式:(单击放大)



TLDR；

请参阅“我当前的设计”，并给我您的意见。我认为这可能过于复杂/没有经过深思熟虑并寻求改进。注意:我不是DBA，而是开发人员。 (此外，如果您没有阅读“问题域”部分，则不确定该架构设计是否有意义:P)

链接

Product Listing Ads

Summary of attribute requirements

我真的很期待看到你们的想法。提前致谢!

最佳答案

只是个人喜好问题:如果不是必须的话，我不太喜欢表内的父级关系。我在模式表中看到了它们，但是在这种情况下，我觉得基本类型可以从更严格的模式中受益，删除BASIC类型并为每个基本类型增加长度的基本约束(就空间而言，没有这样的壮举)和速度)。如果您确实需要额外的
基本类型:执行此操作，但是只为一个父级添加一个父表，并使所有内容符合该表。

当然:它缺乏灵活性，但是根据我的经验，与允许无限级别的嵌套基元相比，添加符合此架构的数据更容易，并且不需要更改代码以检索条件(该代码将是简单的查询)。不会使用或更糟的是:您会滥用:)