问题标签 [schema-design]

这是一个关于 Django 项目模式设计的相当快速的问题。

基本上，我们有一系列来自不同部门的月度报告，这些报告汇总成一个带有一些漂亮图表的报告（我们可能会为此使用 Google Visualization API，但如果您有什么想法，我愿意接受其他建议否则与 Django 很好地集成）。

每个部门都有责任为报告的部分提交自己的数据。我们可能会使用 Django 管理员来输入这些数字，因为它不必很漂亮，只是每个月都会得到一些数字。

我假设这里更好的方法是有一个抽象的报告模型，为每个部门继承这个模型，每个部门都有一个单独的模型，覆盖任何特定的字段，然后每个都有一个 DateField 。

将一个月作为父对象，并从中减少报告 - 这是一种愚蠢的方法，对吗？

此外，执行它的最佳方法是什么，以便他们只能提交一次数据？我可以有一个单独的月份和年份字段，我猜并在该字段上强制执行唯一性，但我希望使用内置的 DateField，但是强制执行月份和年份唯一性的最佳方法是什么？我应该为此使用新的模型验证功能吗？

干杯，维克多

我需要创建一个描述 Java 对象的 XML 模式定义 (XSD)。

我想知道当相关对象继承自带有类型参数的公共基类时如何执行此操作。

（哪里XTime和Location是在别处定义的自定义类）

我将如何构建一个 XSD，以便我可以拥有代表每个子类的 XML 节点Rule<T>- 而不是每个子类的 XSD 都重复它们的共同内容？

谢谢！

我们正在为基于 Oracle 11gR1 的新系统设计数据库模式。我们已经确定了一个主模式，它将有近 100 个表，这些表将从前端 Java 应用程序访问。

我们需要审核在近 50 个表中更改的值，这必须在每一行中完成。

这意味着，对于其中的单行，表中MYSYS.T1可能有 50（或更多甚至更少，但最少 1）行MYSYS_AUDIT.T1_AUD。我们可能有每个列条目的旧值和可用的新值T1。

DBA 给出了一个意见，建议不要使用这种方法，因为他说，单独的模式意味着每个操作都有额外的 I/O。基本上 AUDIT 模式仅用于进行一些分析和输入值（因此SELECT和INSERT）。

“单独的模式意味着额外的 I/O”是真的吗？我找不到理由。

对我来说这似乎是合乎逻辑的，因为不应篡改 AUDIT 数据，因此是一个单独的模式。

此外，我们设计了一个单独的模式来归档来自MYSYS. 可能会从MYSYS_ARC表中备份到磁带中或在足够的时间后删除。

很少的统计数据：
模式 中很少有表（接近 20、30 个）MYSYS可以增长到大约 50M 行。
我们要求总磁盘空间为 4 TB。
MYSYS_AUDIT架构可能有 10 倍，MYSYS但我们不会将它们保存超过 3 个月。
MYSYS 中的少数表将具有以下事务/分钟。

• 100表示插入表INSERT的次数相同。MYSYSMYSYS_AUDIT
• UPDATE表中的1000MYSYS表示表中插入的数量相同MYSYS_ADIT。

问题：
鉴于所有这些，您能建议我做些改进吗？

1. 单独的架构会影响磁盘 I/O？（每个模式都有一个额外的 I/O 吗？）
2. 有什么一般性的建议吗？

数字：

除此之外，我们还有两个只有只读权限的模式，但主要是出于临时目的，我们不介意它们的性能。

建议：
有几个建议。我们就以下内容达成一致。

1. 逻辑分离的模式。
2. TRIGGER用于将数据插入 AUDIT 表。
3. 表名没有_AUD后缀。:)
4. 填充ARCHIVE模式表的过程。
5. 基于间隔的分区。

我们正在分析...

1. 工作区管理器选项。

在接受 APC 或 dpbradely 的解决方案之前，该问题仍有待进一步建议。

一对一的关系通常可以存储在同一个表中。是否有理由不将它们存储在同一张表中？

我有这种情况，我不确定它应该如何在数据库中建模。我试图建模的对象是：球队、球员、球队球员成员资格，以及给定球队中每个球员的应付费用清单。因此，费用取决于球队和球员。

所以，我目前的方法如下：

模式布局 ERD

在此模式中，team_players是 和 的联结teams表players。并且该表team_player_fees具有属于联结表的记录的记录。

例如，球员 A 在球队 A 中，并且在 8 月和 2 月到期的费用为 10 美元和 20 美元。球员 A 也在球队 B 中，并且在 5 月和 6 月到期的费用为 25 美元和 25 美元。每个球员/球队组合可以有一组不同的费用。

问题：

• 有没有更好的方法来处理这种情况？
• 这种关系有术语吗？（所以我可以用谷歌搜索）或者知道任何具有类似结构的参考资料？

我正在启动一个项目，我认为由于它提供的速度和可扩展性，它特别适合 MongoDB。

我目前感兴趣的模块与实时聊天有关。如果我要在传统的 RDBMS 中执行此操作，我会将其拆分为：

• 频道（一个频道有很多用户）
• 用户（一个用户有一个频道但有很多消息）
• 消息（一条消息有一个用户）

这个用例的目的，我想假设一次通常有 5 个通道处于活动状态，每个通道每秒最多处理 5 条消息。

需要快速的特定查询：

• 获取新消息（可能基于书签、时间戳或递​​增计数器？）
• 向频道发布消息
• 验证用户是否可以在频道中发帖

记住 MongoDB 的文档限制为 4mb，您将如何设计架构？你的会是什么样子？有什么我应该注意的问题吗？

之前没感觉过这个规律，但是好像是二叉树或者任意树（每个节点可以有很多子节点但子节点不能指向任何父节点），那么这个数据结构可以表示为数据库中的一张表，每一行都有一个自己的 ID 和一个parentID指向父节点的 ID。

这实际上是经典的员工 - 经理图：一个老板可以在他手下有很多人......每个人都可以n在他下面有人，等等。这是一个树形结构，在数据库书籍中作为一个常见示例表示为单表Employee。

这个问题试图为这个问题找到一个实际的解决方案。

我的 SQL 数据库需要一个半模式少的设计。但是，我可以限制将其硬塞到整个 SQL 范式中的灵活性。迁移到无模式数据库可能是未来的一种选择，但现在，我坚持使用 SQL。

我在 SQL 数据库中有一个表（我们称之为Foo）。当添加一行时，它需要能够存储任意数量的“元”字段。一个例子是能够附加任意元数据，如标签、合作者等。所有字段都是可选的，但问题是它们属于不同的类型。有些可能是数字，有些可能是文本等。

一个简单的设计链接Foo到带有 , , , 等字段的表格似乎很直接OptionalValues，尽管它下降到 Alex 在最后一个答案中提到的整个EAV模型中，而且看起来很浪费。另外，我想当它增长时，查询会很慢。不过，我不希望按此表中的任何内容进行搜索或排序。我所需要的是，当我从 中取出一行时，这些额外的属性也应该是可以获得的。namevalue_typevalue_stringvalue_intvalue_dateFoo

在 SQL 数据库中实现这种设置是否有任何最佳实践，或者我只是错误地看待整个事情？

I want a JSON schema that enforces an empty JSON object, e.g. {}

Is this a good idea and possible?

I tried the following but it allows me to enter anything in the JSON body:

假设我们有一个名为 Widget 的对象，我们可以为它构造一个数据库表。

现在，假设我们有两组额外的细节来描述小部件。每组数据在不同的时间可用。所以，假设我们的小部件的生命周期分为三个阶段......

在阶段 1中，我们只是有一个带有名称和描述的小部件。

在阶段 2中，我们的小部件获得了高度和重量。

在阶段 3中，我们的小部件获得目的地和运输成本。

上述模式（用于“阶段 3”）意味着在阶段 1 或阶段 2 中的小部件的数据库记录将具有空值。

或者，我们可以构造一个永远不会有空值的模式（但父记录可能有零个、一个或两个子记录，具体取决于小部件生命周期的当前阶段）：

这些替代方案之一总是正确的吗？每个人都有合理的利弊吗？如果答案取决于更多变量，它们是什么？在什么条件下，一种替代方案会成为明显的首选？

接受的答案将引用该主题的现代权威来源。

编辑：我觉得这很容易引起争论，但它也是一个应该有正当利弊的话题，因此是一个权威的答案。这个问题只是困扰我的一个问题，因为我已经看到它在没有正当理由或考虑替代方案的情况下以两种方式完成。根据当前引领潮流的 DBA 类型，我只想知道哪个是正确的。