2012-02-09 5 views
2

Я создаю приложение для отслеживания конфигураций машин в сети. «Конфигурация» в целом определяет продукты/службы/ОС/приложения, установленные в системе. Изменение в любом из них приводит к изменению конфигурации. Информация получена с помощью сканеров. Данные уже разобраны. Мне нужно выяснить способ эффективного хранения данных.Схема схемы для отношения (многие из многих)

Основная идея

  1. Каждый IP будет иметь идентификатор конфигурации вместе с метками времени и флагами, которые идентифицируют данные как текущие или исторические
  2. Каждая конфигурация в очереди состоит из записей разных типов. Поэтому для каждого идентификатора конфигурации у нас есть не более трех типов записей (1-OS, 2-Service, 3 Applications)
  3. Каждый тип записи может иметь несколько записей. Например, тип 1 (то есть - ОС) может иметь несколько записей типа a) Microsoft Windows XP b) Microsoft Windows 7 и т. Д.

Я застрял в определении набора подходящих таблиц, который помогает мне выполнить следующие цели

  1. Узнают информацию OS/Service.Application для каждого IP
  2. Признать изменения/без изменений/возвращаясь в конфигурации с 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-адреса или конфигурации) в идеале должна поддерживаться отдельно, поскольку именно так ожидает отдельная часть программы.

ответ

1

Я не могу сказать, что я все здесь понимаю, поэтому этот пример может дать вам некоторые идеи.

Начать с ConfigurationType, это может быть 1- OS; 2- Service ...

Configuration таблица содержит все возможные (допустимые) конфигурации. ConfigurationTypeNo является целым числом (1,2,3 ...) для каждого ConfigurationTypeID - поэтому существует ОС (1,2,3 ...); обслуживание (1,2,3 ...) и т. д.

SystemConfiguration фиксирует историю конфигураций для каждой системы. Если TimeChanged является частью ПК, возможно повторить такую ​​же конфигурацию.

IP_Allocation отслеживает историю IP-присвоений.

enter image description here

+0

Это хороший вариант. Но я пытался избежать составных первичных ключей (Django не поддерживает их полностью). Я думал, что это - ip_config может иметь config_id, а затем мы создаем новую конфигурацию таблицы только с полем id. Другая таблица config_type_map описывает отношение «многие ко многим» между config_id и type_id, а его собственный идентификатор используется в качестве внешнего ключа в таблице, описывающей записи. – RedBaron

+0

. Один из способов избежать составных клавиш (поскольку ORM дает вам проблемы) заключается в использовании автоматического -increment-integers для PK, а затем просто добавлять уникальные ограничения к таблицам DB - например, вы можете добавить 'SystemConfigurationID' как PK в' SystemConfigurationTable', а затем добавить уникальное ограничение на '(SystemID, ConfigurationTypeID, ConfigurationTypeNo, TimeChanged)' , Это создает дополнительный индекс, но позволяет использовать преимущества выбранной ORM. –

Смежные вопросы