用于监控应用程序状态的数据库设计功能

Question

我正在创建数据库来监视应用程序功能的状态。逻辑如下：

每个应用程序都有自己正在监视的特定功能列表。每一项功能仅属于一个应用程序。有一个功能表，其中包含应用程序的外键

每个应用程序都在一台或多台计算机上运行。每台机器可以运行一个或多个应用程序。这是MTM连接，因此存在ApplicationInstance表连接Applications与Machines。

实际的监控是查询ApplicationInstance。如果出现问题，有关该问题的信息将转到 AppInstanceError 表，该表保存 ApplicationInstance 的外键。如果查询成功，我们将获得每个功能的状态列表。因此，我们有一个FunctionalityStatus 表，其中包含ApplicationInstance 和ApplicationInstance 的外键。功能性。

我认为这是一种糟糕的设计 - 为什么我们对应用程序有多个引用？什么保证两者都指向同一个应用程序？或者有什么办法可以保证这一点吗？

所以我的修复建议是将功能状态与外键连接到机器和机器。功能性。但在这种情况下，他们定义了 ApplicationInstance，那么每对都有 ApplicationInstance 的保证是什么？他们不应该以某种方式联系起来吗？在现实世界中，连接是存在的并且是显而易见的，那么数据库中不存在它可以吗？

是否有“正确的方法”来解决这个问题，或者确保连接在数据设计中不可见？

为了更清楚地说明，我准备了我现在拥有的数据库设计：

唯一缺少的是从FunctionalityStatus 到Machine 的连接。我看到两种建立这种连接的方法：

1. 将外键添加到 ApplicationInstance - 那么我的疑问是：
   • 如何确保功能中的 ApplicationId 与 ApplicationInstance 中的相同？
   • 真的需要这种数据复制吗？
2. 将外键添加到机器 - 和疑问：
   • 每个FunctionalityStatus 记录都会有一个适当的ApplicationInstance 记录吗？
   • 如果ApplicationInstance和FunctionalityStatus之间存在明显的联系（在第一个疑问中提到），我们在数据库中看不到它吗？
   • 再次出现数据冗余，因为所有 ApplicationInstance 记录在（或应该）在 FunctionityStatus 表中可见

或者也许整个设计搞砸了，我应该找出完全不同的东西？

Answer 1

你的设计对我来说似乎不错。我会选择选项 1，将外键从 FunctionalStatus 添加到 ApplicationInstance。

如果您想确保 FunctionalStatus 和 ApplicationStatus 引用同一个应用程序，您可以添加一个新列 FunctionalStatus.ApplicationId，并将外部从 FunctionalStatus 到 ApplicationStatus 的键包含 ApplicationId。对于从 FunctionalStatus 到 Functionality 的外键也是如此。

换句话说，就像

CREATE TABLE application
    ( application_id          INT PRIMARY KEY
    /* Other columns omitted */
    );
CREATE TABLE application_instance
    ( application_instance_id INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    , machine_id              INT REFERENCES machine(machine_id)
    /* Other columns omitted */
    );
CREATE TABLE functionality
    ( functionality_id        INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    /* Other columns omitted */
    );
CREATE TABLE functionality_status
    ( functionality_status_id INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    , functionality_id        INT /* Part of composite foreign key, see below */
    , application_instance_id INT /* Part of composite foreign key, see below */
    /* Other columns omitted */
    FOREIGN KEY (functionality_id, application_id) 
      REFERENCES functionality(functionality_id, application_id)
    FOREIGN KEY (application_instance_id, application_id) 
      REFERENCES application_instance(application_instance_id, application_id)
    );

Answer 2

您可能遇到的最大问题是，同一台计算机上同一应用程序的两个不同实例始终可能具有相同的实例 ID。它们不能同时出现，随着时间的推移，实例 ID 会被重复使用，并且您的应用程序极有可能再次获得相同的 ID。

当我做这种事情时，我会在每个应用程序启动时为其分配一个 GUID，这使得两个应用程序不可能具有相同的 GUID，然后我使用该 GUID 来建立关系。您甚至不需要在关系中包含机器信息，因为每台机器永远不会与任何其他机器创建相同的 GUID。

回答完这个问题我才发现我真的没有回答你真正的问题。如果您想查看某些功能是否以某种方式工作，最好将其与机器和应用程序相关联，其中该功能未按您想要的方式运行，或者您很难找到哪个功能正常工作，哪个功能正常工作一错。

拥有三个表，一张用于机器，一张用于应用程序，一张用于功能将是最好的数据库设计。根据您正在执行的操作，软件可能会更轻松、更快速地复制您正在使用的每组功能的所有应用程序和机器信息，特别是如果有关机器和应用程序的信息只是一个字段的话。如果可以的话，您确实不想减慢记录此信息的功能，因此您希望快速完成它。

Answer 3

如果是我，我会这样做：

1. 创建 5 个表，机器，
   应用、功能、
   应用程序池和日志。
2. 在功能中放置 FK 列，
   这是应用程序的 ID
   该功能存在的目的。
3. ApplicationPool 将有一台机器
   ID 列、应用程序 ID 列、
   主键可以是 GUID 或
   种子身份，
   ApplicationInstance ID 这将
   是您的应用程序名称 + PK。如果可以的话，我会用它来命名您的应用程序和机器。
4. 最后，我将制作日志表
   并给出一个 FK 列
   参考PK
   应用程序池。然后，每次您记录某些内容时，您都可以将其添加到日志表中，并且有关应用程序的所有信息都将单独存储。

如果这还不够，请告诉我，因为我可能误解了您要寻找的内容。