2012-02-09 34 views
2

我正在創建一個跟蹤網絡上計算機配置的應用程序。 「配置」廣泛地定義了系統上安裝的產品/服務/操作系統/應用程序。任何一個變化都會導致配置發生變化。 使用掃描儀獲取信息。數據已被解析。我需要找出一種有效存儲數據的方法。(疑似)多對多關係的架構設計

的基本思想是

  1. 每個IP將有一個配置標識符具有時間戳信息和標識該數據作爲當前或歷史
  2. 在打開各配置由多種類型的條目的標誌位。因此,對於每個配置標識符,我們最多有三種類型的條目(1-OS,2-Service,3-應用程序)
  3. 每種類型的條目可以有多個條目。例如類型1(即-OS)可以具有多種類型的條目a)Microsoft Windows XP b)Microsoft Windows 7等

我被困在定義一組合適的表格,可以幫助我履行以下目標

  1. 去了解每個IP
  2. 識別更改的OS/Service.Application信息/沒有改變/在IP

的數據,我得到的配置恢復爲IP和SE 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: 
+--+---+----+ 
|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 - 所以有OS(1,2,3 ..);服務(1,2,3 ...)等。

SystemConfiguration捕獲每個系統的配置設置的歷史記錄。由於TimeChanged是PK的一部分,因此可以重複相同的配置。

IP_Allocation跟蹤IP分配的歷史記錄。

enter image description here

+0

這是一個不錯的選擇。但我試圖避免複合主鍵(Django不完全支持它們)。所以我認爲這 - ip_config可以有一個config_id,然後我們創建一個新的表配置只有id字段。另一個表config_type_map描述config_id和type_id之間的多對多關係,並且它自己的id被用作描述條目的表的外鍵 – RedBaron 2012-02-10 05:56:16

+0

避免複合鍵的一種方法(因爲ORM給你帶來麻煩)是使用auto -Increment-integers,然後簡單地爲數據庫表添加唯一約束 - 例如,您可以將'SystemConfigurationID'作爲PK添加到'SystemConfigurationTable'中,然後在'(SystemID,ConfigurationTypeID,ConfigurationTypeNo,TimeChanged) 。這會創建一個額外的索引,但允許選定的ORM的好處。 – 2012-02-10 13:03:33