有关(overcomplex？)架构的SQL架构建议
我目前正处于开发我们产品新部分的数据库设计阶段.为此,我需要进行"健全性检查"或一些建议,因为我对设置的某些部分并不过分自信.
一点背景信息
我们正在开发的产品是所谓的"营销ROI最大化系统".它处理大数据和处理/增强/丰富大量信息,然后将其发送到不同的营销渠道.简而言之,这基本上就是它的作用.
问题域
该系统目前尚未完全具备良好的数据验证功能,并且每天都被"营销"人员和我们称之为"自助服务"的客户"滥用".考虑到我们的首席执行官的新谷歌产品列表广告网络,我的任务是提出一个很好的解决方案,如何处理在谷歌的购物渠道中使用的{信息/数据}(称之为PLA;产品列表)广告).
这就是问题所在:
我们的产品不提供任何形式的验证(阅读:遵守网络特定要求),PLA基本上完全围绕数据完整性通过项目分类(每个类别定义了必需/可选字段)每个字段可以或应该采用特定的格式(甚至可能取决于链接的类别;我还不知道:P).
你猜它,我们对当前的设置有点紧张.只是不可能强制执行这些"严格"的产品供稿.让我们的营销人员和自助服务客户创建并向PLA发送数据将意味着在99%的时间内解决问题/解决问题.而且由于它只是一家小公司,我宁愿看看真正的问题.那意味着; 试图创建一个可用于PLA营销活动的真实验证系统.
需要做什么
我一直在与营销人员和客户交谈,了解用例是什么以及需求是什么.这些可以在以下列表项中总结:
- 输入Feed中的每个项目都需要"分类"映射到google PLA类别(请参阅"链接"部分以查看可以映射到哪些类别.
- 每个"类别"的每个字段需要设置验证
- 每个项目的每个字段需要分配/映射到所选类别中定义的字段.
附加信息
现在,我不想担心"如何将"项目"链接到"类别"或"字段"到"类别字段定义"或类似的东西.这些"动态的东西"将由一个ECA规则系统,它将在其他时间开发.(为什么你问？系统是按计划处理/处理数据,因此需要定义和存储每个操作以供以后使用),不要担心实现细节目前.
此外,具体的具体实现通常通过使用动态属性来实现(例如,由数据类型定义的字段上的属性等).EAV系统现在也不是我的主要关注点.(如果你看看数据库设计,上面给出的用例会更有意义).
我目前的设计
首先,让我使用主要实体解释我的SQL结构:
schemas; 一种定义"类别"的抽象方式,可以考虑PLA类别fields; 字段定义(在a中schema)datatypes; 一袋类型.(主要用于给上面的字段一些数据完整性)valueConstraints; 一袋约束定义(不是实现!).
现在.到目前为止,这一切都很好,花花公子.这是我有点担心的事情:
valueConstraints通过N:M表(datatype_valueConstraints)绑定到数据类型,但几乎每个用户生成的数据类型只由可用值约束的子集组成,具有可以具有的"Price"数据类型没有意义一个"电子邮件"约束..然而,有一个"最小"和"最大"约束看到价格总是一个数字是有道理的.为清楚起见:每个数据类型datatype_valueConstraints保持"可能" valueConstraints.
primitiveType - > constraintValue关系也会出现同样的问题.基本上,数据类型必须包含"primitiveType"(在我的例子中是基本类型表的外键).基元类型管理valueConstraints要选择的.primitiveTypes并且valueConstraints不被视为用户生成,因此它现在是夹具数据.
不明白吗？以下是"PLA /服装"模式的示例工作流程((部分)设置):
- 添加数据类型"image",将{primitive type设置为TEXT}
- 选择以下
ValueConstraints使用(特定于TEXT)- "URL"(确保它是http | https或类似的东西,不知道)
- "MinLength"(确保它在那里)
- "正则表达式"(允许某些图片扩展..或类似的东西)
- 选择以下
- 添加字段定义"imageURL",将{datatype设置为"image"}
- 数据类型特定配置,即填充约束断言数据(与EAV模式相关)."MinLength"= 14,"Regex"="*(gif | jpg | png)"等.
因为数据类型是原始的"TEXT",所以用户可以仅选择"TEXT" - 关注(并且由于树状数据类型系统而继承)valueConstraints.
正确设置数据类型后,我们可以将数据类型"image"用于模式中的多个字段(如果我们需要).例如; "PLA/CLOTHING"架构可能需要"附加图像"字段.现在可以通过重复使用"image"数据类型和不同的约束配置来实现这一点.
显示关系的可视化SQL表格布局(关于文本上方墙的脑波):
我的数据库架构:(点击放大)
TLDR;
请参阅"我当前的设计"并给出您的意见.我认为它可能过于复杂/没有深思熟虑并寻求改进.注意:我不是DBA,只是开发人员.(另外,如果您还没有阅读"问题域"部分,我不确定架构设计是否有意义:P)
链接
我真的很期待看到你们的想法.提前致谢!
只是个人喜好的问题：如果不是真的有必要的话，我不太喜欢表内的父关系。我在模式表中看到了它们，但在这种情况下，我觉得基元类型可以从更严格的模式中受益，删除 BASIC 类型并向每个基元添加长度的基本约束（就空间而言，没有这样的壮举）和速度）。如果您确实需要创建额外的原始类型级别：请执行此操作，但仅为一个父级别添加一个父表，并使所有内容都符合此要求。
当然：它缺乏灵活性，但根据我的经验，添加符合此模式的数据更容易，并且不需要更改代码来检索条件（并且代码将是一个简单的查询），而不是允许无限级别的嵌套基元不会使用或更糟：你会滥用:)