字符串分類策略

Question

我是初出茅廬的軍事歷史網站上的單人開發團隊。該網站的一個方面是約1,200個個人戰鬥的目錄，其中包括參與其中的國家&編隊（團，部隊等）。

地形信息（以及其他戰鬥信息）是由一個由10人志願者團隊從一系列書籍中手動導入的。編隊以不同的格式和縮寫模式列出。當我設置數據收集表單時，我無法想到處理這些數據的好方法......並選擇將其全部存儲爲MySQL數據庫中的字符串，並在稍後將其整理出來。

那麼，「以後」 - 因爲它往往會發生 - 已經到來。 :-)

每場戰鬥在數據庫中有2個記錄 - 每個參與國家都有一個記錄。每個記錄都有一個編隊文本字符串，列出志願者選擇添加它們時存在的編隊。

一些真實的例子：

• 39擲彈Rgmt，第26屆國民擲彈兵師
• 第二空軍場部，第246步兵師
• 第247步兵師，第255坦克旅
• 第二空軍場部， SS騎兵師
• 第28坦克旅第158步槍師第135步槍師第81坦克旅第242坦克旅
• 第78步兵師
• 第三吳特別海軍登陸部隊，圖拉吉水上飛機基地人員
• 第1營第505步兵團

的最終目標是爲每個單獨的力量有一個ID，以便其參加可以追蹤整個戰鬥數據庫。地層層次結構，如上面的最後一項1st Battalion (of the) 505th Infantry Regiment也需要保留。在這種情況下，1st Battalion和505th Infantry Regiment將被拆分，但1st Battalion將被標記爲屬於505th.

在數據庫方面，我想我想拉形成場走出目前的戰鬥信息表，並創建三個新表格：

FORMATION 
[id] [name] 

FORMATION_HIERARCHY 
[id] [parent] [child] 

FORMATION_BATTLE 
[f_id] [battle_id] 

這很容易解釋，但很難制定。

我從SO社區尋找的東西只是關於如何最好地解決這個問題的一些提示。理想情況下，有一些方法可以解決這個問題，我不知道。然而，作爲最後的手段，我總是可以編寫一個分類框架，並叫我回來的志願者通過2,500+記錄進行排序...

Answer 1

您已經標記爲PHP相關的問題 - 但事實並非如此。

您正在提議使用代理鍵（id）替換真實標識符，但真正的標識符本質上是唯一的 - 所以您只是讓數據結構比需要的更復雜。話雖如此，層次結構的葉子部分可能只在父節點的範圍內是唯一的。

你需要解決的最重要的問題是編隊樹是否總是兩層。我懷疑有時它可能是一個，有時它可能超過2個。你提出的結構對於不同深度的樹木不會很好地工作。

這可能會幫助：

http://articles.sitepoint.com/article/hierarchical-data-database

C.