我正在創建一個跟蹤網絡上計算機配置的應用程序。 「配置」廣泛地定義了系統上安裝的產品/服務/操作系統/應用程序。任何一個變化都會導致配置發生變化。 使用掃描儀獲取信息。數據已被解析。我需要找出一種有效存儲數據的方法。(疑似)多對多關係的架構設計
的基本思想是
- 每個IP將有一個配置標識符具有時間戳信息和標識該數據作爲當前或歷史
- 在打開各配置由多種類型的條目的標誌位。因此,對於每個配置標識符,我們最多有三種類型的條目(1-OS,2-Service,3-應用程序)
- 每種類型的條目可以有多個條目。例如類型1(即-OS)可以具有多種類型的條目a)Microsoft Windows XP b)Microsoft Windows 7等
我被困在定義一組合適的表格,可以幫助我履行以下目標
- 去了解每個IP
- 識別更改的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或配置)理想情況下應單獨維護,因爲這是程序的一個單獨部分預期它的方式。
這是一個不錯的選擇。但我試圖避免複合主鍵(Django不完全支持它們)。所以我認爲這 - ip_config可以有一個config_id,然後我們創建一個新的表配置只有id字段。另一個表config_type_map描述config_id和type_id之間的多對多關係,並且它自己的id被用作描述條目的表的外鍵 – RedBaron 2012-02-10 05:56:16
避免複合鍵的一種方法(因爲ORM給你帶來麻煩)是使用auto -Increment-integers,然後簡單地爲數據庫表添加唯一約束 - 例如,您可以將'SystemConfigurationID'作爲PK添加到'SystemConfigurationTable'中,然後在'(SystemID,ConfigurationTypeID,ConfigurationTypeNo,TimeChanged) 。這會創建一個額外的索引,但允許選定的ORM的好處。 – 2012-02-10 13:03:33