假设我有这个 mysql db，数据库中的所有表都相互关联，主键、外键等都设置好了。 现在，是否可以仅从数据库设计中预测哪些查询将用于应用程序？ 由于数据库确实决定了应用程序的功能，因此从设计中，我们可以预测应用程序中将使用哪些查询，对吗？
如果可能，是否有一种策略或自动方法来生成可能的查询？
我写了一本关于使用SQL和Excel分析数据的书，并且花了多年时间使用数据库。
是的，从数据库结构中，您可以确定表将如何连接在一起。 你不会弄清楚用户需要的更难的 - 通常更相关的业务 - 的东西。 以下是一些示例：
您可以拥有一个数据库，其中的主表是电话呼叫，其中包含相关信息。 从此数据库中，您可能需要知道一次活动呼叫的最大数量。 或者您可能需要知道某人在一个月内给多少人打电话。
您可以拥有订阅者记录的数据库。 您可能需要计算某人在给定时间后停止的概率。
您可以拥有一个产品和购买的数据库。 您可能需要找出三种产品一起出现的最常见组合。
您可以拥有一个信用卡购买数据库。 您可能需要弄清楚谁在距离其账单地址 50 英里以上的餐厅花费超过 200 美元。
关键是。 数据库不代表"应用程序功能"。 数据库表示实体和它们之间的关系，大概在现实世界中。 认为您可以查看数据库并知道业务问题是什么，这是傲慢的。
相反，数据库的目的是支持数据，而数据又支持应用程序。 应用程序的需求将随着时间的推移而变化。 与许多其他数据存储技术不同，数据库的美妙之处在于，该技术随着数据的增加而扩展，支持对结构的更改，并允许将新的实体和关系添加到系统中，而无需完全重写它。
随着时间的推移，随着经验的积累，你可能会对什么是重要的事情产生直觉。 即使你这样做了，你也会不断对用户的各种需求感到惊讶。
我真诚地不想在这里变得聪明，但答案是 - 是和否。
是的，因为3NF设计通常很好地概述了它背后的业务规则，所以你可以在一定程度上告诉它背后的业务逻辑是什么，你可以从中创建对象或图形模型并获得一个好主意。可以根据连接/关系和可访问属性提出哪些类型的问题。
否，因为从组合上讲，您可能有来自图表的问题组合数量难以处理。因此，你无法真正判断一个人在合理的、非指数的时间内可能会问什么问题。
一般来说，如果设计很好，并且桌子的名字有意义，你可以很好地了解发生了什么。
理论上这是可能的，但由于 N 行与 X 列由 Z 表由 W 可能函数由 Q 在每列/行上的可能值的组合爆炸，这是一个惊人的大数字。
这里的问题是您还需要考虑数据。有些查询只有在有特定数据时才有意义，而其他查询则没有意义。所以你本质上是在考虑巨大的超立方体。
我使用多维数据库（非规范化多维数据集），这本质上是非规范化数据库。阅读一下OLAP理论，你就会明白为什么。
所以简而言之，不，因为这几乎是不可能的。
现在，是否可以仅从数据库设计中预测哪些查询将用于应用程序？
至少在原则上，您可以预测哪些查询可以得到有效回答。应用程序将实际尝试执行哪些查询是另一回事。
在理想情况下，数据库模型将考虑现在和将来所有应用程序的所有查询需求。我们还不生活在那个世界;)
如果可能，是否有一种策略或自动方法来生成可能的查询？
不，这需要人类理解模型的实际含义。不幸的是，没有好的方法可以教一个工具有这种程度的理解。
一个好的模型对于在数据库建模和正在建模的领域有经验的人将立即有意义。这样的人通常能够预测实际使用的查询的相当一部分，但很少预测所有查询，因此数据库模型本身旁边的文档是可取的。当然，并非所有模型都很好...