這是一個高效的MySQL數據庫設計嗎？

我正在研究一個項目，其中我有一組關鍵字[abc，xyz，klm]`。我也有一堆文本文件的內容[1.txt，2.txt，3.txt]。這是一個高效的MySQL數據庫設計嗎？

我正在做的是將關鍵字與文本文件相撞以找到關鍵字所在的行，並且可以多次執行此操作。所以我想爲每個事件存儲ID (text file name without .txt), Extracted_Data, Line_Number, Spwaned_Across (keyword may be spread across 2 lines)。

我決定爲每個關鍵字創建一個表來存儲這些數據。

表：ABC，XYZ，KLM

表ABC樣本數據：

ID Extracted_Data       Line_Number Spawned_Across 
12 MySQL is wonderful. What is 'abc'  34   1

所以我結束了對每個關鍵字的表。在我的項目中，有大約150個關鍵字，它可以增長。所以有150張桌子。

爲什麼我選擇這樣做？

現在我需要找到關鍵字是否存在於一個文件中，我相信在將來我會被要求顯示它在文件中出現的位置或方式。我計劃爲每個新關鍵字自動創建一個表，這樣我就不必手動創建每個關鍵字或一個有100列的巨大表格。

我做出了正確的決定嗎？您的意見非常感謝。

來源

2011-08-02 ThinkCode

不要這樣做。沒有數據庫庫針對動態表名稱進行了優化，並且每次要訪問表時都必須從頭開始創建查詢。另外，您如何回答「我在文件12的第34行找到什麼數據」等問題？

你會想要三張表。在PostgreSQL語法[*]，那會是：

CREATE TABLE source (sourceid SERIAL, filename VARCHAR NOT NULL); 
CREATE TABLE keyword (keywordid SERIAL, keyword VARCHAR NOT NULL); 
CREATE TABLE location (locationid SERIAL, 
    sourceid INTEGER NOT NULL REFERENCES source(sourceid), 
    keyword INTEGER NOT NULL REFERENCES keyword(keywordid), 
    data VARCHAR NOT NULL, 
    line INTEGER NOT NULL, 
    span INTEGER NOT NULL);

當你開始處理新的文本文件，創建一個新的source元組，並記住它的SourceID。當您遇到關鍵字時，請爲其插入新記錄並記住其關鍵字id或查找舊記錄。然後將該sourceid，keywordid和其他相關數據插入location。

要回答我剛纔提出的問題：

SELECT * FROM 
    location JOIN source ON location.sourceid = source.sourceid 
    JOIN keyword ON location.keywordid = keyword.keywordid 
WHERE 
    source.filename = 'foo.txt' AND 
    location.line = 34;

是的，它更多的工作在前面做了「正確」的方式，但你會在性能償還一萬次，易於維護和易於使用的結果。

[*] MySQL的語法類似，但我不記得它在我頭頂，你可以很容易地找出差異。

來源

2011-08-02 15:21:52

這絕對是一個很糟糕的決定。

數百萬行比數百萬個表更好。

用合適的外鍵創建2個表，你會沒事的。

我會被要求顯示它在文件中發生的位置或方式。

這仍然可以在2個表

來源

2011-08-02 14:57:43

做我不明白爲什麼你不能只是沿着存儲數據的關鍵詞在一個表中。

ID Keyword Extracted_Data Line_Number Spawned_Across 
12 abc  Abc or xyz?.. 31337  1 
12 xyz  Abc or xyz?.. 31337  1 
12 xyz  just xyz here 66666  1 
13 xyz  xyz travels! 123   1

因此，您必須通過關鍵字或文件或兩者都查詢所有數據存在。要進一步標準化，您可以將關鍵字分別存儲在「關鍵字」表中，並僅將外鍵保留在「發生」表中。

此外它不是非常受歡迎的名稱「ID」除主鍵以外的任何東西。

來源

2011-08-02 15:02:36

我不認爲這是有效的。我甚至不確定關係數據庫是否適合這項工作。

新的關鍵字將意味着更多的表格。這不可擴展。

關鍵字和文件讓我想起索引和非結構化搜索。我會在關係數據庫之前考慮Lucene。

來源

2011-08-02 15:03:33 duffymo

我嘗試了整個solr/Lucene大約一週，但無法調整架構以適應我的情況。如果索引所有文檔，你認爲solr可以吐出關鍵字，爲每個文件提取匹配的行（多次）？我開始探索，發現它是一隻野獸，需要很多時間來馴服它！ – ThinkCode

我認爲它會比你的關係解決方案效果更好。 – duffymo

這是一個高效的MySQL數據庫設計嗎？

回答

相關問題