6

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

一点背景资料

我们正在开发的产品是所谓的“营销投资回报率最大化系统”。它处理大数据并处理/增强/丰富大量信息,然后将其发送到不同的营销渠道。简而言之,这基本上就是它的作用。

问题域

该系统目前不具备良好的数据验证功能,并且每天都被“营销”人员和我们所谓的“自助服务”客户“滥用”。我们的 CEO 想到了新的谷歌产品详情广告网络,我的任务是想出一个很好的解决方案来处理如何在谷歌的购物渠道中使用{信息/数据}(称之为 PLA;产品列表广告)。

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

你猜对了,我们对当前的设置有点搞砸了。只是不可能强制执行这些“严格”的产品提要。通过让我们的营销人员和自助服务客户创建数据并将其发送到 PLA,将意味着 99% 的时间都在寻找错误/解决问题。而且由于它只是一家小公司,我宁愿看看真正的问题。这意味着;试图创建一个可用于 PLA 营销活动的真实验证系统。

需要做什么

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

  • 输入提要中的每个项目都需要“分类”映射到 google PLA 类别(请参阅“链接”部分以查看可以映射到哪些类别。
  • 需要为每个“类别”的每个字段设置验证
  • 每个项目的每个字段都需要分配/映射到所选类别中定义的字段。

附加信息

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

此外,具体的具体实现通常通过使用动态属性(例如,由数据类型定义的字段上的属性等)来实现。EAV 系统也不是我现在的主要关注点。(如果您看一下数据库设计,上面给出的用例会更有意义)。

我现在的设计

首先,让我使用主要实体来解释我的 SQL 结构:

  • schemas; 定义“类别”的抽象方式,想想 PLA 类别
  • fields; 字段定义(在 a 中schema
  • datatypes; 一袋类型。(主要用于给上述字段一些数据完整性)
  • valueConstraints; 一袋约束定义(不是实现!)。

现在。到目前为止,一切都很好。这是我有点担心的事情:

valueConstraints通过 N:M 表datatype_valueConstraints( “电子邮件”约束.. 然而,有一个“最小”和“最大”约束看到价格总是一个数字是有意义的。为清楚起见:持有每种数据类型datatype_valueConstraints的“可能” 。valueConstraints

PrimitiveType -> constraintValue 关系也会出现同样的问题。基本上一个数据类型必须包含一个“primitiveType”(在我的例子中是一个原始类型表的外键)。原始类型管理valueConstraints从中进行选择。primitiveTypes并且valueConstraints不被认为是用户生成的,所以它现在是夹具数据。

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

  • 添加数据类型“图像”,设置 {primitive type to TEXT}
    • 选择以下ValueConstraints使用(特定于文本)
      • “URL”(确保它是 http|https 或类似的东西,不知道)
      • “MinLength”(确保它在那里)
      • “正则表达式”(允许某些图像扩展名..或类似的东西)
  • 添加字段定义“imageURL”,设置{datatype为“image”}
    • 数据类型特定配置,即填写约束断言数据(EAV 模式相关)。"MinLength" = 14,"正则表达式" = "*(gif|jpg|png)" 等等。

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

一旦正确设置了数据类型,我们就可以对模式中的多个字段使用数据类型“图像”(如果我们愿意的话)。例如; “PLA/CLOTHING”模式可能需要“附加图像”字段。这现在完全可以通过重用具有不同约束配置的“图像”数据类型来实现。

显示关系的可视化 SQL 表布局(关于文字上方的脑电波):

我的数据库架构:(点击放大)

TLDR;

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

链接

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

4

1 回答 1

1

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

当然:它缺乏灵活性,但根据我的经验,添加符合此模式的数据并且不需要更改代码来检索条件(并且代码将是一个普通查询)比允许无限级别的嵌套原语更容易不会使用或更糟:你会滥用:)

于 2013-06-05T11:15:06.640 回答