SQL數據庫設計問題

我正在創建用於監視應用程序功能狀態的數據庫。該邏輯如下：SQL數據庫設計問題

每個應用程序都有我正在監控功能的它自己的，具體名單。每個功能只屬於一個應用程序。還有的是，有外鍵的應用

每個應用程序都在一個或多個機器上運行的功能表。每臺機器可以運行一個或多個應用程序。這是MTM連接，所以ApplicationInstance表連接應用程序與機器。

實際監測是有關查詢ApplicationInstance。如果出現問題，關於它的信息將發送到AppInstanceError表，該表保存ApplicationInstance的外鍵。如果查詢成功，我們會得到每個功能的狀態列表。所以我們有一個帶有外鍵的FunctionalityStatus表，用於ApplicationInstance &功能。

我覺得這是一種糟糕的設計 - 爲什麼我們有多個參考應用程序？什麼保證都將指向相同的應用程序？或者有什麼方法可以確保這一點？

所以我修復的主張是FunctionalityStatus與外鍵機&功能連接。但是在這種情況下，他們定義了ApplicationInstance，那麼對於每對來說ApplicationInstance是什麼保證？他們不應該以某種方式連接嗎？在現實世界中，連接存在並且是顯而易見的，那麼它可以不在數據庫中嗎？

是否有解決這個問題，或者，確保從數據設計隱形連接的「propper方式」？

爲了讓我準備DB的設計，我現在有更清楚： DB design http://img6.imageshack.us/img6/7479/dbexample.png

是唯一缺少的是FunctionalityStatus到機器的連接。我看到兩個流的方式進行這樣的連接：

添加外鍵ApplicationInstance - 然後我的疑惑是：
- 如何確保從的applicationID功能是從ApplicationInstance同一個？
- 是否真的需要這種數據重複？
添加外鍵機 - 和疑慮：
- 會有每一個FunctionalityStatus記錄一個propper ApplicationInstance記錄？
- 如果ApplicationInstance和FunctionalityStatus（第一個疑問中提到）之間存在明顯的連接，我們無法在數據庫中看到它嗎？
- becouse所有ApplicationInstance記錄同樣的數據冗餘的（或應該）在FunctionalityStatus表

可見或者，也許整個設計是搞砸了，我應該弄清楚一些完全別的嗎？

來源

2010-02-22 ssobczak

是對functionalityStatus與應用相關的或特定的應用程序的每個實例？因此，如果一個應用程序實例處於關閉狀態，您是否會認爲整個應用程序已關閉或只是某個特定實例？你還可以解釋功能表中將包含什麼？有些數據可能有助於瞭解它是如何使用的 –

你的設計對我來說似乎很好。我會選擇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) 
    );

來源

2010-02-23 05:25:34 markusk

你可能有最大的問題是，它總是能夠具有相同的實例ID在同一臺機器上同一應用程序的兩個不同的實例。不能同時使用，實例ID會隨着時間的推移而重複使用，並且您的應用有可能再次獲得相同的ID。

當我做這種事情，我分配給每個應用程序中的GUID當它開始，使得它不可能有兩個應用程序使用相同的GUID，然後我使用GUID的關係。您甚至不需要在關係中擁有機器信息，因爲每臺機器永遠不會與其他任何機器製作相同的GUID。

我回答這個問題，我真的不回答你的真正的問題後實現的。如果您正在查看某些功能是否以某種方式工作，最好將其與機器和應用程序相關聯，但功能不符合您的要求，或者您無法找到哪個功能正常工作，哪些功能無法正常工作一個錯誤。

有三個表一個機器，一個應用程序和一個功能將是最好的數據庫設計。根據你在做什麼，軟件可以更容易，更快速地複製你正在使用的每組功能的所有應用程序和機器信息，特別是如果有關機器和應用程序的信息只是一個字段。如果您可以提供幫助，您確實不希望減慢記錄此信息的功能，所以您希望快速完成此操作。

來源

2010-02-22 17:22:57

感謝您的幫助，但我認爲您誤解了我的問題。我發佈了包含更多細節的圖片，也許會讓問題更加清晰。 – ssobczak

如果是我，這是我會怎麼做：

創建5個表，機械，應用，功能， ApplicationPool和日誌。
將FK列放入功能中，即功能所存在的應用程序的ID 。
ApplicationPool將有一臺機器 ID列，應用ID列，主鍵要麼是一個GUID或接種的標識， ApplicationInstance ID這將是你的應用程序名稱+ PK。如果你能這樣做，我會用它來爲你的應用程序命名你的機器。
最後，我會製作日誌表，並給出一個FK列參考 ApplicationPool的PK。然後每次登錄時都可以將其添加到日誌表中，並且關於該應用程序的所有信息都將單獨存儲。

如果無法接近，讓我知道，因爲我可能誤解了你在找什麼。

來源

2010-02-22 19:33:47

這是解決方案的一部分，但您錯過了關於兩個日誌表的部分。我張貼了一張圖片，也許它會比文字更具描述性。 – ssobczak

SQL數據庫設計問題

回答

相關問題