问题标签 [database-design]

我试图找出是否应该在数据库内部的触发器或约束中使用业务关键逻辑。
到目前为止，我已经在触发器中添加了逻辑，因为它让我可以控制接下来发生的事情，这意味着我可以提供自定义用户消息，而不是可能会混淆用户的错误。

在触发器上使用约束是否有任何显着的性能提升，以及确定使用哪个的最佳实践是什么。

我正在开发一个 SaaS 应用程序，其中每个客户将根据他们购买的版本、他们购买的附加功能等具有不同的配置。例如，客户可能有 3 个自定义报告的限制。

显然我想将此配置存储在数据库中，但我不确定最好的方法。我们希望将来能够在不需要更改数据库架构的情况下添加其他功能，因此每个配置选项具有一列的单个表是不明智的。

可能的选项是一个表，每个客户一个条目，一个 XML 字段包含该客户的整个配置，但是当 XML 模式更改以添加其他功能时，这会增加复杂性。

我们可以使用带有键值对的表，并将所有配置设置存储为字符串，然后解析为正确的数据类型，但这似乎有点混乱，就像为字符串配置选项、整数配置选项提供单独的表一样，等等

人们正在使用的这种场景是否有一个好的模式？

我正在构建一个数据仓库，其中包含餐厅的送货信息。数据存储在 SQL Server 2005 中，然后放入 SQL Server Analysis Services 2005 多维数据集。

交付信息由下表组成：

事实交付

• 分支键
• 交货日期密钥
• 产品密钥
• InvoiceNumber（DD：退化维度）
• 数量
• 单位成本
• 线路成本

笔记：

• FactDeliveres 的粒度是发票上的每一行
• 产品维度包括供应商信息

问题是：事实表没有主键。主键应该是唯一标识每个交付加上 ProductKey 的东西。但是我没有办法唯一标识一个交付。

在源 OLTP 数据库中，有一个 DeliveryID，对于每个交付都是唯一的，但这是一个对用户没有意义的内部 ID。InvoiceNumber 是供应商的发票编号——这是手动输入的，所以我们得到了重复。

在多维数据集中，我仅基于 FactDeliveres 中的 InvoiceNumber 字段创建了一个维度。这确实意味着，当您按 InvoiceNumber 分组时，您可能会合并 2 个交付，只是因为它们（错误地）具有相同的 InvoiceNumber。

我觉得我需要包含 DeliveryID（称为 DeliveryKey），但我不确定如何。

我也是：

1. 将其用作 InvoiceNumber 维度的基础键？
2. 创建一个每次有新交付时都会增长的 DimDelivery？这可能意味着某些属性来自 FactDeliveries 并进入 DimDelivery，例如 DeliveryDate、Supplier、InvoiceNumber。

毕竟，我只能问你：当我的源数据库中有以下信息时，我如何创建一个 Deliveries 多维数据集

DeliveryHeaders

• DeliveryID (PK)
• 交货日期
• 供应商 ID (FK)
• 发票号码（手动输入）

交货详情

• DeliveryID (PK)
• 产品 ID (PK)
• 数量
• 单位成本

大约一年前，我阅读了 Scott Ambler 的重构数据库：进化数据库设计。我被这样的想法所说服，就像您可以使用 TDD 开发代码一样，您可能应该（至少）使用单元测试覆盖您的数据库，甚至在更改架构之前编写数据库测试，以便您进行数据库工作也是 TDD 风格。

我真的很喜欢这个想法，并且我一直在手动执行此操作（好吧，有时我会执行此操作）一段时间，只是编写规则的单元测试，这些测试恰好连接到数据库并根据给定的模式文件检查其结构。但是我还没有找到任何可以帮助自动化这个过程的好的数据库变更管理工具包。有人知道吗？

我希望在数据库中存储 900x100 元素的二维数组。阵列的有效召回和比较很重要。我可以使用具有 [A, x, y, A(x,y)] 之类的架构的表，这样单个数组就会破坏 90,000 条记录。这似乎是一个存储数组的~ok~表设计，并且可以有效地调用单个元素，但调用整个数组的效率很低，并且会导致非常低效的数组比较。

我应该以这种方式离开表格设计并在代码中构建和比较我的数组吗？或者有没有更好的方法来构造表，以便我可以使用仅数据库操作获得有效的数组比较？

谢谢

我正在编写一个包含以下表格的应用程序：（1）employee_type，（2）employee 和（3）employee_action。

Employee_action 对员工来说是外键的，它包含对发生的事情和事件日期的描述，正如您所期望的那样。

但是，员工可以随着时间的推移改变他们的类型（晋升、降职、调动等）。如果我的模式就这么简单，那么您可能会生成一份历史报告，说明 John 在 10 年前外出送披萨时是公司的 CEO。

对我来说，最好的方法是保存员工在执行某项操作时具有某些特征的事实，而这些特征不一定是他们目前的特征？

我在这里简单地陈述我的问题。我的桌子比 3 多得多，而且员工职位并不是我担心的唯一特征。我不能只对所有内容进行非规范化并制作一个包含每个可能的员工字段的历史表。

谢谢，我希望这很清楚。

我有基于 Flex 的消费者网站，我想在其中根据随机和其他标准更改各种外观和感觉类型设置，然后跟踪这些以产生最多销售。

例如，我可能会完全关闭主页，根据人们来自哪里显示不同的内容。我可能会显示或隐藏某些功能，或更改某些文本。我可能会改变的事情尚未定义，并且可能会变得相当复杂。

我想设计最灵活的数据库模式，但它必须高效且易于搜索。目前，我有一个“SiteVisit”表，其中包含有关每个不同访问者的信息。

我想在包含每个设置的列的单个表和仅包含键值对的表之间找到正确的平衡。

有什么建议么？

我目前正在设计一个全新的数据库。在学校里，我们总是学会在每个表中放置一个主键。

我读了很多文章/讨论/新闻组帖子说最好使用唯一约束（也就是某些数据库的唯一索引）而不是 PK。

你的观点是什么？

I inherited a database built with the idea that composite keys are much more ideal than using a unique object ID field and that when building a database, a single unique ID should never be used as a primary key. Because I was building a Rails front-end for this database, I ran into difficulties getting it to conform to the Rails conventions (though it was possible using custom views and a few additional gems to handle composite keys).

The reasoning behind this specific schema design from the person who wrote it had to do with how the database handles ID fields in a non-efficient manner and when it's building indexes, tree sorts are flawed. This explanation lacked any depth and I'm still trying to wrap my head around the concept (I'm familiar with using composite keys, but not 100% of the time).

Can anyone offer opinions or add any greater depth to this topic?

请记住，我将在纬度/经度对上执行计算，哪种数据类型最适合与 MySQL 数据库一起使用？