Дизайн базы данных для мониторинга состояния функциональных возможностей приложений

Ваш дизайн кажется мне хорошим. Я бы выбрал вариант 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)
    );

Самая большая проблема, с которой вы можете столкнуться, заключается в том, что всегда можно иметь одинаковые идентификаторы экземпляров для двух разных экземпляров одного и того же приложения на одном компьютере. Не может быть одновременно, идентификаторы экземпляров со временем используются повторно, и есть небольшой шанс, что ваше приложение снова получит тот же самый.

Когда я делаю такие вещи, я присваиваю каждому приложению идентификатор GUID при его запуске, что делает невозможным наличие двух приложений с одним и тем же идентификатором GUID, и затем я использую этот идентификатор GUID для отношений. Вам даже не нужно иметь информацию о машине в отношении, поскольку каждая машина никогда не будет иметь тот же GUID, что и любая другая машина.

После ответа на это я понял, что действительно не ответил на ваш настоящий вопрос. Если вы хотите увидеть, работает ли определенная функциональность определенным образом, лучше всего связать ее с машиной и приложением, где функциональность работает не так, как вы хотите, или у вас возникли проблемы с поиском, какая из них работает правильно, а какая одна ошибка.

Наличие трех таблиц: одной для машин, одной для приложений и одной для функциональных возможностей было бы лучшим дизайном базы данных. В зависимости от того, что вы делаете, программному обеспечению может быть проще и быстрее дублировать всю информацию о приложении и машине для каждого набора функций, с которыми вы работаете, особенно если информация о машине и приложении — это всего лишь одно поле. Вы действительно не хотите замедлять функциональность для регистрации этой информации, если можете помочь, поэтому вы хотите, чтобы это было сделано быстро.

Если бы это был я, я бы сделал так:

1. Создайте 5 таблиц: Machine, Application, Functionality, ApplicationPool и Log.
2. Поместите столбец FK в Функциональность, который является идентификатором Приложения, для которого существует Функциональность.
3. ApplicationPool будет иметь столбец идентификатора машины, столбец идентификатора приложения, первичный ключ, который является либо GUID, либо начальным идентификатором, идентификатор ApplicationInstance, который будет вашим ApplicationName + PK. Если вы можете, я бы использовал это, чтобы назвать ваши приложения вашими машинами.
4. Наконец, я бы сделал таблицу журнала и дал столбец FK, который ссылается на PK ApplicationPool. Затем каждый раз, когда вы что-то записывали, вы могли добавлять это в таблицу Log, и вся ваша информация о приложении будет храниться отдельно.

Если это не близко, дайте мне знать, потому что я мог неправильно понять, что вы ищете.