问题标签 [relational-database]

通常，当我需要存储管理信息、版本等系统属性时，我会使用平面文件（database.properties、init.properties 等）。这在我每天看到和使用的其他程序中似乎很常见。

有时，出于多种原因，平面文件并不理想。将 Web 应用程序部署到众多客户端通常会遇到一些限制。在这些情况下，我使用数据库表来保存信息。例如，假设我有一些想要保存的管理数据，也许还有一些关于我的环境的细节。我可能会做这样的事情：

property_entry_table

我意识到这会破坏 SQL 的输入，并允许我将各种类型存储为字符串。这是一个好的做法还是我一直在做错误的事情？

如果没有，我应该以什么方式存储此类信息？

我徒劳地试图学习如何使用对象数据库。在数据库教科书中，传统似乎是使用跟踪学生、课程和班级的例子，因为它是如此熟悉和适用。这个示例作为对象数据库会是什么样子？关系数据库看起来像

您是否会将 StudentClasses 保留在 Classes 中，而 Classes 又保留在 Course 中，然后将 Student 保留为顶级实体？

有人建议我研究键/值对数据系统来替换我一直在使用的关系数据库。

我不太了解的是这如何提高查询效率。据我了解，您将丢弃大量有助于提高查询效率的信息，只需将您的结构数据库变成一个长长的键和值列表？

我完全错过了重点吗？

我将很快开始设计一个 Web 应用程序，虽然我在 SQL 领域有很多经验，但我不知道这样做需要考虑什么，以便在不久的将来迁移到 GAE未来。

或者，我可以从一开始就为 GAE 设计应用程序，那么在这种情况下，我需要考虑哪些差异？换句话说，为 GAE 编写应用程序的 DOs 和 DONTs 是什么，来自过去的关系数据库。

假设我在数据库上有两个表 T ₁₀和 T ₁₁，分别有 10 和 11 列，其中 10 列在两者上完全相同。

我违反了什么（如果有）规范化规则？

我在开发项目中使用 SVN 的经验很少，而我在关系数据库方面的经验也很少。我知道表和 SQL 语句等基本概念，但我远非专家。

我想知道的是是否有任何通用的版本控制类型系统，如 SVN，但它适用于数据库而不是文件。我想要与 SVN 相同的功能，例如创建分支、创建标签和合并分支的能力。与其将修订号与文件存储库的版本相关联，不如将其与数据库的版本相关联。

他们是否有任何通用的解决方案可以添加这种独立于实际数据库模式的功能？我会对与 MySQL 或 MS SQL Server 一起使用的解决方案感兴趣。

我还应该澄清我正在尝试对数据而不是模式进行版本控制。我希望架构保持不变。所以真的，我似乎想要一种方法来创建所有 INSERT、UPDATE 和 DELETE 请求的日志，这些请求在每个数据版本之间发送到数据库。这样，任何版本都可以通过重新发送已保存到所需版本的所有 SQL 语句来重新创建。

是否可以收听关系数据库更新？例如，我的网络应用程序想通过 Comet 技术向客户端发送数据更新。我可以让程序定期轮询数据库，但这不会是高性能和可扩展的。

如果应用程序可以隐藏到数据库的“事件处理程序”，那么应用程序可以在每次给定数据库表数据更新时收到通知。这听起来更有希望，但我没有找到任何具体的例子。这是侦听器模式。

常见的关系数据库是否支持这样的功能？

我有一个包含两个表的数据库——我们称它们为 Foo 和 Bar。每个 foo 可能与任意数量的 bar 相关，并且每个 bar 可能与任意数量的 foo 相关。我希望能够通过一个查询来检索与某个 bar 关联的 foo，以及与某个 foo 关联的 bar。

我的问题是，记录这些关系的最佳方式是什么？我应该有一个单独的表来记录每个关系（例如两列，foo 和 bar）吗？foo 表是否应该有一个栏列表的列，反之亦然？还有另一个我忽略的选择吗？

我目前正在使用以下 PHP 代码：

基本上，我得到了一个用户列表，这些用户是给定 supervisor_id 的下属（每个用户条目都有一个 supervisor_id 字段），然后抓取属于这些用户中的任何一个的条目。

我不禁想到有一种更优雅的方式来做到这一点，比如SELECT FROM tablename where user->supervisor_id=2222

PHP/MySQL 有类似的东西吗？
可能应该在某个时候正确地学习关系数据库。:(

编辑：这是相关的架构

一个submission有很多submittedentries，目前我正在使用时间戳来引用它。如果有人可以提出更有效的方法，我非常愿意改变这一点。（是的，我省略了更多字段）

假设您有两组概念实体：

• 具有多个ForwardPriceEntries的MarketPriceDataSet
• 具有多个PoolPriceForecastEntry的PoolPriceForecastDataSet

两个不同的子对象具有几乎相同的字段：

ForwardPriceEntry 有

• 开始日期
• 结束日期
• 模拟项 ID
• 远期价格
• MarketPriceDataSetId（父表的外键）

PoolPriceForecastEntry 有

• 开始日期
• 结束日期
• 模拟项 ID
• 预测池价格
• PoolPriceForecastDataSetId（父表的外键）

如果我将它们建模为单独的表，唯一的区别就是外键和价格字段的名称。

关于是否应将两个几乎相同的表合并为一个的问题一直存在争议。

我想到的建模选项是：

• 只需将它们保留为两个独立的单独表格
• 将两个集合放在一个表中，并带有一个附加的“类型”字段，并且parent_id等于任一父表的外键。这将牺牲参照完整性检查。
• 将这两个集合放在一个带有附加“类型”字段的表中，并创建一个复杂的连接表序列以保持引用完整性。

你认为我应该怎么做，为什么？

其他可能相关或不相关的信息：

• 这两组数据是松散相关的：每组将加载到内存中进行批处理，偶尔会通过从 ForwardPriceEntries 复制生成一组PoolPriceForecastEntries。

• MarketPriceDataSet和PoolPriceForecastDataSet确实有不同的字段。可以将它们合并到一个表中，但是您将在一半条目中拥有无意义的字段。