问题标签 [relational-database]

Oracle中的视图和物化视图有什么区别？

自1995 年伊达和达尔文的《第三宣言》首次出版以来，已经过去了十多年。

关系学派在当今数据库世界中的位置是什么？是否有任何证据表明 Manifesto 的想法改变了主流软件开发和数据管理实践？他们是否催生了新的数据管理产品？这些产品在商业上是否成功？

我正在对现有数据库进行升级，该数据库的设计没有任何代码来实现正在考虑的设计。现在我在用代码实现数据库设计方面遇到了障碍。我确定这是否是数据库设计的问题，或者我只是没有看到关于如何做的正确解决方案。

基本逻辑规定如下：

1. 用户通过席位访问在线培训。用户可以拥有多个席位。
2. 席位由公司购买，并与产品具有多对多关系。
3. 产品与模块具有多对多关系。
4. 模块与课程具有多对多关系。
5. 课程是最终用户进行培训的访问权限。
6. 为了搅浑水，出于某种原因，一些用户有多个包含相同产品的席位。
7. 认证是基于每个产品进行的，而不是基于每个席位。
8. 用户与存储其当前状态或课程分数的课程具有多对多关系。
9. 用户在完成该产品的所有模块中的所有课程后，即可对产品进行认证。
10. 了解用户何时完成特定模块的所有课程也很重要。
11. 一些席位将用于重新认证，这意味着之前通过产品认证的用户可以注册并参加重新认证考试。
12. 由于规则 11，用户可以并且将会拥有多个认证记录。
13. 编辑：当用户完成课程（得分高于 80%）时，用户已（根据当前业务逻辑）完成了所有产品和包含课程的所有席位的课程。

正如我或多或少所描述的那样，我在当前设计和业务逻辑上一直遇到的问题是，我无法找到一种方法来有效地将用户是否已获得特定产品和席位的认证与他们何时获得认证没有。我一直在尝试确定哪些产品下的哪些座位已获得用户认证，哪些没有。部分问题是因为如果他们目前在不同席位下注册了多个相同产品，那么我只需要计算一次产品。

下面是所涉及的架构部分的副本。任何有关如何改进设计或在代码中绘制关联的建议将不胜感激。万一这很重要，这个网站是建立在 LAMPP 堆栈上的。

您可以在此处查看数据库架构的相关部分：http://lpsoftware.com/problem_db_structure.png

我正在对数据库进行一些研究，并且正在研究关系数据库的一些限制。

我知道大表的连接非常昂贵，但我不完全确定为什么。DBMS执行join操作需要做什么，瓶颈在哪里？
非规范化如何帮助克服这一开销？其他优化技术（例如索引）如何提供帮助？

欢迎亲身体验！如果您要发布资源链接，请避免使用 Wikipedia。我知道在哪里可以找到那个了。

与此相关，我想知道 BigTable 和 SimpleDB 等云服务数据库使用的非规范化方法。看到这个问题。

交叉连接对两组元组执行笛卡尔积。

哪些情况下使这样的 SQL 操作特别有用？

在课堂上，我们都在“学习”数据库，每个人都在使用 Access。对此感到厌烦，我正在尝试做其他班级正在做的事情，但使用 MySQL 的原始 SQL 命令而不是使用 Access。

我已经设法创建了数据库和表，但是现在我如何在两个表之间建立关系？

如果我有两个这样的表：

和

如何在两个表之间创建“关系”？我希望为每个帐户“分配”一个 customer_id（以指示谁拥有它）。

我一直在尝试查看是否可以使用基于文档的数据库（在本例中为 CouchDB）来满足某些要求。两个通用要求：

• 具有某些字段的实体的 CRUD，这些字段上具有唯一索引
• 像 eBay 这样的电子商务网络应用程序（这里有更好的描述）。

而且我开始认为基于文档的数据库不是满足这些要求的最佳选择。此外，我无法想象基于文档的数据库的用途（也许我的想象力太有限了）。

当我尝试使用面向文档的数据库来满足这些要求时，如果我向榆树问梨，你能向我解释一下吗？

我正在寻找一种可以在mysql中映射我的数据库中的关系的工具。我想要类似于在“显示图表窗格”中的 MS-SQL Server Management Studio 中生成的视图。这样的事情存在吗？

我负责数据库的设计及其使用 rails 的约定。我不会反对手动指定关系。

在我团队的一次相当热烈的讨论中，我被迫思考大多数人喜欢什么作为主键。我们有以下小组-

1. Int/ BigInt 哪个自动增量是足够好的主键。
2. 应该至少有 3 列构成主键。
3. Id、GUID 和人类可读的行标识符都应该区别对待。

PK的最佳方法是什么？如果你能证明你的观点是正确的，那就太棒了。有没有比上述更好的方法？

编辑：任何人都有一个简单的示例/算法来为可扩展的行生成人类可读的标识符？

假设我想做一个“优化的查询生成器”。基本上是一个 SQL 查询优化器，它比基于时间/空间限制的 SQL 服务器中的优化器要好得多。它将查询和数据库统计信息作为输入，并生成为目标系统量身定制的 SQL 查询，该查询将快速优化为几乎理想的计划。

需要支持多少 SQL？是否有一个 SQL 子集足够灵活，可以轻松描述最有用的查询，但又比完整的 SQL 小，值得将其缩减为？如果您不需要坚持“靠近机器”，还有更好的方法来描述查询吗？

我不是在考虑一个程序来处理现有的 SQL，而是一个用于创建新 SQL 的工具。只要输入语言能够描述查询的要求，实际上不需要将SQL 作为输入。

我想问题的另一种形式是：它们的 SQL 的任何部分是否仅用于性能并且从不提高可读性/可理解性？

正如有人指出的那样，这样做需要“大量特定于产品的知识”，并且（例如嵌套子查询与其他任何东西，应该使用什么样的索引，诸如此类）正是该工具旨在封装的内容这样用户就不需要学习这些知识。

注意：我对生成实际的查询计划不感兴趣，因为那是 DBMS 的工作，无论如何都不能从 SQL 中完成。我对一个系统感兴趣，该系统可以从不需要为该 DBMS 调整的输入中自动为给定 DBMS 生成良好的 SQL 的工作。