Я создаю приложение для отслеживания конфигураций машин в сети. «Конфигурация» в целом определяет продукты/службы/ОС/приложения, установленные в системе. Изменение в любом из них приводит к изменению конфигурации. Информация получена с помощью сканеров. Данные уже разобраны. Мне нужно выяснить способ эффективного хранения данных.Схема схемы для отношения (многие из многих)
Основная идея
- Каждый IP будет иметь идентификатор конфигурации вместе с метками времени и флагами, которые идентифицируют данные как текущие или исторические
- Каждая конфигурация в очереди состоит из записей разных типов. Поэтому для каждого идентификатора конфигурации у нас есть не более трех типов записей (1-OS, 2-Service, 3 Applications)
- Каждый тип записи может иметь несколько записей. Например, тип 1 (то есть - ОС) может иметь несколько записей типа a) Microsoft Windows XP b) Microsoft Windows 7 и т. Д.
Я застрял в определении набора подходящих таблиц, который помогает мне выполнить следующие цели
- Узнают информацию OS/Service.Application для каждого IP
- Признать изменения/без изменений/возвращаясь в конфигурации с IP
данные я не является IP и се t записей и их идентификатор типа. Например.
IP - x.y.z.w :
Entries - Microsoft Windows XP :1(Type-OS),
Apache HTTP 2.3 :2(Type-Service),
Mozilla Firefox :3(Type - Application)
Раньше, когда я не беспокоил о конфигурации и просто должен был хранить записи, которые я имел следующую схему
Table ip_map : id int, ip char #Table that keeps track of IPs
Table ip_ref: id int , ip_id references ip_map(id), t_stamp timestamp, archived bool, type smallint #Table that keeps IPs and type
Table current_network: id int, ip_ref_id references ip_ref(id), port int, vendor, product,version #Table that stores actual entries
т.е. - я идентифицировал запись с помощью IP и введите информацию.
Если мне нужно реализовать конфигурацию, схема должна быть несколько, как
ip_map:
+--+-------+
|id|ip |
+--+-------+
|1 |x.y.z.w|
+--+-------+
ip_config:
+--+------+----------+--------+----------+
|id|ip_id |t_stamp |archived|config_num|
+--+------+----------+--------+----------+
|1 |1 |1212231313| 1 | 1 |
|2 |1 |1212299999| 0 | 2 |
+--+------+----------+--------+----------+
Я застрял на этапе после этого. В идеале config_num - это внешний ключ, который указывает на первичный ключ таблицы config. Но поскольку конфигурация состоит из разных типов, это не представляется возможным. Это то, что я имею в виду.
config:
+--+---+----+
|id|num|type|
+--+---+----+
|1 | 1 | 1 |
|2 | 1 | 2 |
|3 | 2 | 1 |
|4 | 2 | 2 |
+--+---+----+
entry:
+--+---------+----+-------------+-------------+-------------+
|id|config_id|port|vendor | product | version |
+--+---------+----+-------------+-------------+-------------+
|1 | 1 | 0 | Microsoft | Windows | XP |
|2 | 1 | 0 | Microsoft | Windows | 7 Home |
|3 | 2 | 80 | Apache | HTTP Server | 2.3.19 |
|4 | 3 | 0 | Linux | Linux | 2.6 |
|5 | 3 | 0 | Linux | Linux | 2.4 |
|6 | 4 | 22 | OpenSSH | SSHD | 4.3p1 |
+--+---------+----+-------------+-------------+-------------+
Но это нарушает согласованность (из-за отсутствия внешнего ключа между ip_config и конфигурационной таблицей). IP-адреса могут быть удалены, но конфигурации будут продолжать задерживаться. Как можно изменить дизайн, чтобы соответствовать моим требованиям?
Примечание: информация о типе (для каждого IP-адреса или конфигурации) в идеале должна поддерживаться отдельно, поскольку именно так ожидает отдельная часть программы.
Это хороший вариант. Но я пытался избежать составных первичных ключей (Django не поддерживает их полностью). Я думал, что это - ip_config может иметь config_id, а затем мы создаем новую конфигурацию таблицы только с полем id. Другая таблица config_type_map описывает отношение «многие ко многим» между config_id и type_id, а его собственный идентификатор используется в качестве внешнего ключа в таблице, описывающей записи. – RedBaron
. Один из способов избежать составных клавиш (поскольку ORM дает вам проблемы) заключается в использовании автоматического -increment-integers для PK, а затем просто добавлять уникальные ограничения к таблицам DB - например, вы можете добавить 'SystemConfigurationID' как PK в' SystemConfigurationTable', а затем добавить уникальное ограничение на '(SystemID, ConfigurationTypeID, ConfigurationTypeNo, TimeChanged)' , Это создает дополнительный индекс, но позволяет использовать преимущества выбранной ORM. –