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