我正在製作一些軟件，我不確定採用哪種方法。我擁有永遠不會改變的數據，並且具有層次關係，並將用於填充顯示。這些數據有相當數量。靜態數據應該存儲在數據庫還是應用程序中
我有以下選擇：
1.A組枚舉/對象 2.An XML文件 3.嵌入式SQLite數據庫
在這種特殊情況下，我認爲，該枚舉是最正確的方法，但我從代碼中嵌入的數據中獲得了一種氣味。另外我需要用於層次結構目的的數據，並且使用枚舉看起來有點麻煩。
數據庫應該提供較少的性能影響並且易於使用，但對於靜態數據似乎過分。
這是正確的設計路徑嗎？
儘管這裏的格式，這不是一個「答案」;在選擇如何表示這些數據時，您需要自己回答一系列問題。
在我（多年以來）的經驗中，「永不改變的靜態數據」幾乎從來都不是靜態的。這可能會導致將數據存儲在不需要更改源代碼的表單中，從而排除枚舉。
實施例：
我開發了一個系統，用於確定到切開動物屍體 最好的方式，基於可用的殼， 的重量和品種和傳入訂單流。該決定 過程的關鍵輸入之一是對動物解剖結構的描述，識別 哪些肉塊來源於哪些肌肉羣，並且因此一旦你取出特定切口就留下哪些部分。 這些信息本質上是分層的。
你會認爲這個信息是相當靜態的;經過 全部，動物的解剖結構沒有改變。但事實上，我們 發現我們需要增加大約每6個月一次的數據， 增加了新的削減方式的描述。
因爲我認爲數據是靜態的，所以我在一個XML文件 中描述了它，並在程序開始時讀取它。但編輯 中的數據很麻煩，而且容易出錯。如果我讓它結束，我肯定會選擇不同的存儲格式。
考慮如果靜態數據發生變化，您需要對程序執行什麼操作。您是否需要添加新的決策邏輯和新類型，還是僅僅是現有對象之間關係發生變化的問題？你將如何調試數據？你會維護源代碼管理中的數據嗎？
我也會考慮你想要訪問這些數據的方式。搜索它需要的靈活性越高，對某種數據庫的爭論就越好。 @ rbaghbanli的觀點也很好，您的決定可能基於代碼運行的平臺。
我做了一個desicion。當應用程序啓動時，我會將默認數據存儲到數據庫並鎖定其主鍵。 –
這取決於您正在構建的應用程序的類型。如果是企業系統或應用程序，則最好將其存儲在企業數據庫中。如果它是輕量級用戶應用程序或移動應用程序，則最好將其存儲爲嵌入式JSON字符串。 XML有點太冗長。
我不得不尊重這個票，因爲在我看來，我認爲更重要的是要考慮如何使用數據和更重要的是什麼類型的該應用程序在確定適當的數據存儲時。 「這是一個企業系統，所以你應該使用企業數據庫」的邏輯不適合我。但是，我會授予您平臺相關的考慮因素，比如移動設備，因爲它們對可用內存有嚴格的限制，因此非常重要。 – Chase
雖然在企業系統中還有其他考慮因素。什麼是關於備份，安全性，保留，披露等的企業政策？這些都不是嚴格技術性的，但他們都可能參與這個決定。 –
你能提供一個你的數據看起來像什麼樣的小片段嗎？ – Chase
從未改變的測驗類型，我有4種類型的測驗。問題類型也很少發生變化，某些問題具有文本答案，有些答案不止一個，等等。 –
你能提供一個有多少數據的估計嗎？ – Chase