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

Question

Я создаю базу данных для мониторинга состояния функциональности приложений. Логика следующая:

Каждое приложение имеет свой определенный список функций, которые я отслеживаю. Каждый функционал принадлежит только одному приложению. Существует таблица Функциональности, которая имеет внешний ключ для Приложения

Каждое приложение работает на одном или нескольких компьютерах. На каждой машине может работать одно или несколько приложений. Это соединение MTM, поэтому есть соединение таблицы ApplicationInstance Приложения с машинами.

Фактический мониторинг касается запросов ApplicationInstance. В случае возникновения проблемы информация о ней поступает в таблицу AppInstanceError, которая содержит внешний ключ для ApplicationInstance. Если запрос выполнен успешно, мы получаем список статусов каждой функции. Итак, у нас есть таблица FunctionalityStatus с внешними ключами для ApplicationInstance & Functionality.

Я думаю, что это плохой дизайн - почему у нас есть несколько ссылок на приложение? Что гарантирует, что оба будут указывать на одно и то же приложение? Или есть ли способ это обеспечить?

Таким образом, мое предложение исправить это соединить FunctionalityStatus с внешними ключами для Machines & Functionality. Но в этом случае они определяют ApplicationInstance, так какова гарантия наличия ApplicationInstance для каждой пары? Разве они не должны быть связаны как-то? В реальном мире связь существует и очевидна, так что нормально, если ее нет в базе данных?

Существует ли «более эффективный» способ решения этой проблемы или обеспечения невидимых соединений при проектировании данных?

Чтобы было понятнее, я подготовил дизайн БД, который у меня сейчас:

Единственное, чего не хватает, так это соединения между FunctionalityStatus и Machine. Я вижу два способа сделать такое соединение:

1. Добавить внешний ключ в ApplicationInstance - тогда мои сомнения:
   • Как убедиться, что ApplicationId из Functionality такой же, как и из ApplicationInstance?
   • Разве это дублирование данных действительно необходимо?
2. Добавить внешний ключ к машине - и сомневается:
   • Будет ли для каждой записи FunctionalityStatus соответствующая запись ApplicationInstance?
   • Если существует очевидная связь между ApplicationInstance и FunctionalityStatus (упомянутое в первом сомнении), почему мы не можем увидеть его в базе данных?
   • Опять избыточность данных, поскольку все записи ApplicationInstance (или должны быть) видны в таблице FunctionalityStatus

Или, может быть, весь дизайн облажался, и я должен выяснить что-то еще?

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

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

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

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

Answer 3

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

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

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

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