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