需要關於用戶提供的服務的數據庫結構建議

我的項目需要類似於黃頁的內容：存儲用戶服務並按服務提供查詢。需要關於用戶提供的服務的數據庫結構建議

我目前的解決方案是非常剛性和繁瑣 - 我有3個預置列表：工業，貿易，專業。用戶從頂層開始並定義他的服務。我還創建了一個「就地搜索」選項，其中提供字符串在「行業 - 貿易 - 專業」字符串中執行查找。

我注意到Google，LinkedIn和黃頁提供了一個更簡單的解決方案，用戶可以放入自由文本，即使搜索詞是CPA，系統也會爲註冊會計師提供結果。

任何關於更智能，更高效和簡單的用戶解決方案的想法？我不是在尋找確切的數據庫結構，一般的算法就足夠了。

謝謝。

來源

2013-01-23 Yaniv

您是否考慮過標籤結構？這允許多個地方的條目，標籤層次結構，標記「重新映射」（標準化標籤名稱）。

基本上，你沒有一個層次結構 - 條目是平的，但有標籤附加，可以形成層次結構。這是您需要的靈活性 - 公司可能提供多種服務，您也可能希望標籤標準化。

簡單地說：

一個表（或更多 - 我把它一般）針對這些項目
一個表標籤，育兒本身（形成樹）
的EntryTAble標籤。

標籤表必須允許交聯（替代標籤，狀態等）。

來源

2013-01-23 13:37:56 TomTom

我想我明白你的意思，但我錯過了一些東西 - 第一個表：id，entry |第二個表：標識，標籤，子標識|第三個表：first_table.id，second_table.id - 我想我創建了第二個表來控制層次結構，並允許用戶將條目添加到第一個表，但我的問題是用什麼邏輯將第一個和第二個表連接到第三個表中？我應該手動執行此操作嗎？非常感謝您的想法和跟進。 – Yaniv

還有別的嗎？我的意思是，這需要智慧，至少有一點痕跡。我不是說這種侮辱，但除非你找到了一種從公司名稱/地址到它所做的業務的神奇方式，這是一個手動過程。它可以編寫腳本（我現在導入4000個服務A），但它是一個用戶，必須從邏輯上決定將條目連接到哪裏。 – TomTom

需要關於用戶提供的服務的數據庫結構建議

回答

相關問題