sql - SQL数据库验证

Question

我目前正在执行 SQL 作业，但某个任务提到我们需要对我们创建的数据库中的表进行验证和验证。

然而，我们没有学到任何关于这个主题的东西，在谷歌搜索了几个小时后，我只找到了你可以在 create table 语句中给出的检查约束。

请提及一些 SQL 表或数据库的验证和验证技术。

Answer 1

通常，您通过对数据运行某种测试来进行验证。

数据通过不同的层，并且有不同类型的测试。

如果您考虑以下系统层：

• 用户界面/客户层
• 应用层
• 数据库层

您可以在这些层中的任何一层进行数据验证，但有以下区别

• 最好在数据库层进行验证，因为您可以让不同的应用程序连接到同一个数据库，虽然这是一件好事，但这些应用程序中的验证不一定相同，因此在数据库层实现的验证在术语方面更好数据完整性
• 同时数据库层的验证应该是最快的，因为数据库层离数据最近（数据不需要经过其他层处理，本例验证）
• 例外情况是，如果验证规则是静态的并且不依赖于数据库中的其他数据（例如测试输入是否为偶正整数），则客户端可以在数据库之前验证数据并避免不必要地分配应用层任务和或数据库层。（同时您还想在数据库层实现验证，以防万一出现错误或其他应用程序将连接到数据库）。同样的原则也适用于应用层——如果应用层可以在不访问数据库服务器的情况下执行验证，它应该这样做，但在数据库层也应该这样做（保证）。

您可以将以下内容视为验证测试​​（验证类型）：

• 类型验证（示例：插入的数据是整数吗？）。这可以通过在列上声明正确的类型在数据库层进行检查。）
• 域验证（例如：数据是正整数吗？）。这可以使用 CHECK 约束在数据库层进行检查
• 关系验证（例如：对于您要添加的记录，另一个表中是否已有记录）。这可以通过正确使用外键在数据库层进行检查
• 业务规则验证（这些可能很复杂，例如'如果您尝试记录的值> 100，则确保您可以记录用户的IP，否则取消交易；如果没有，请不要打扰'。）这些的验证可以通过触发器和存储过程来完成。在现实世界中，业务规则验证通常在应用程序层实现（出于各种原因 - 从 PL/SQL 的相对不可维护性和不可移植性（通常是您必须编写触发器的语言）到实现复杂的触发器会降低性能并最终使系统变得非常复杂）。

Answer 2

您需要确保您创建的基于教师规范的模式确实可以完成工作。验证是您使用另一种方法测试某些东西的过程。所以...编写一个尝试插入错误数据的小型验证程序。做几个测试用例。一旦您的架构设计通过了验证，就可以说它是经过验证或验证的。

Answer 3

您需要区分validation和verification。假设我们遵循形式验证中的概念。

验证：“我们是否在努力做出正确的事情？”，即产品是否符合用户的实际需求

验证：“我们做了我们想要做的吗？”，即产品是否符合规格？

首先，我们需要在您的特定场景下对两者进行定义。例如，我们有一个表模式，它保存公司中的员工信息：

Employee

ID | Name | Age | Salary

比如说，每个员工都有一个唯一的 ID（永远不会为零）。然后我们可以定义一个带有ID=0无效记录的行。（根据用户需求）

在我们将所有记录插入表后，我们不应该有任何带有ID=0. 我们可以使用查询进行验证，该查询SELECT * from Employee WHERE ID=0不应返回任何行。（我们成功了吗？）