在MySQL中存儲「不規則」數據

如果已經提出了這個問題，可以提前道歉，但是我真的不知道如何搜索我的問題。在MySQL中存儲「不規則」數據

我正在開發一個酒店預訂和預訂管理系統，旨在與多個客戶合作，並且預計一些客戶會有不同的要求，其中包括預訂回覆表單中標準之外的其他字段姓名，地址，電子郵件，郵政編碼等等）。

要做到這一點，我已經創建了一個存儲這些附加字段和隨之而來的值作爲序列化數據的「選項」字段。但是，客戶希望這些字段是可搜索的。雖然這是可能的，但這顯然不是存儲需要搜索的數據的最佳方式。

此外，有問題的表是MySQL中的InnoDB格式。

關於我能想到的是移動這些附加字段到一個單獨的表中的唯一的事，但呈現給預訂的閱讀和寫作過程中有很多挑戰。

什麼是存儲此類不規則數據以進行搜索的最佳方式？

來源

2011-09-27 Wayne Smallman

「但呈現給預訂的閱讀和寫作過程中有很多挑戰。」？加入？這些「挑戰」是什麼？ –

重新編寫大量的代碼，並且具有行爲在所有客戶端保持一致，無論他們使用額外的字段或沒有。 –

如果「重新編寫大量的代碼」是你的問題的一部分，那麼你等了太久，要求設計建議。 –

您的問題並不是真正的數據庫問題，而是一個如何在單個程序中支持多個客戶端及其需求的問題。

你需要決定的第一件事是是否多個客戶端將你的程序的單個實例中得到支持，或者每個客戶端是否有自己的實例。

如果每個客戶都有自己的實例，那麼你可以單獨維護共同的代碼庫，並根據需要自定義每個客戶的實例。可能需要一些計劃來生成一個系統，其中對通用代碼庫所做的更改被定製版本正確地繼承，但最終每個客戶端將得到他們想要的正好。

如果您正在採取多租戶方式，那麼您需要提前決定每個客戶將能夠定製他們的系統的確切程度。然後在數據庫和應用程序結構中提供該定製。在最簡單的層面上，這允許每個客戶端將他們的標識信息和徽標存儲在某個表格的某個表格中（可能是他們自己的CSS鏈接，以便爲應用程序定製外觀）。

在「額外域」的情況下，這可以通過多種方式來處理。一個是簡單地放在桌子上10個多VARCHAR領域的問題，並讓每一個客戶「姓名」這些領域，因爲他們認爲合適的（可能與你的應用程序將使用如果需要的話要挾VARCHAR數據類型說明符）。然而，在用戶界面中適當的位置顯示了許多他們命名的列（使用正確的提示）。這種方法的好處是，一旦建立起來，你就不需要爲每個客戶做額外的工作。

另一種方法是，讓每一個客戶有一個額外的1比1個與表，用於存儲多餘的領域。在這種情況下，您可以正確命名和鍵入數據庫中的字段。缺點是，如果您允許客戶自由選擇這些字段，您必須修改用戶界面以「瞭解」每個客戶端。

來源

2011-09-27 11:17:46

「您需要決定的第一件事是在程序的單個實例中是否支持多個客戶端，或者每個客戶端是否都有自己的實例。」這是我與客戶討論過的情況，以防客戶（客戶）的需求超過應用程序明智的支持能力。 –

正確的版本控制確實可以幫助保持這些應用程序同步。選擇一個非常適合合併的SCM – Evert

一種選擇是使用鍵值表。分開存儲密鑰，例如：

CREATE TABLE keys (
    id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, 
    keyName VARCHAR(100) 
); 

CREATE TABLE values (
    key_id INT(11) UNSIGNED NOT NULL, 
    customer_id INT(11) UNSIGNED NOT NULL, 
    value VARCHAR(100) 
);

肯定仍然不是很好，但它是對您的問題的有效解決方案。

來源

2011-09-27 11:04:54 Evert

是的，我喜歡這個主意。我認爲這個想法有其優點。 –

我想它，如果它的東西，你不會總是需要讀取表時，即，你有沒有查詢該表，而不返回本場可能分離出它自己的表？

如果您確實選擇將其保留在同一個表中，則沒有理由不能在其上放置索引，但這會盡可能地加快搜索速度，而不會將數據拆分爲邏輯塊（您不能，如果它可以是「任何東西」）。要警告的是，添加索引會增加寫入次數，同時減少讀取次數（所以不要在系統中寫入次數多於讀取次數或寫入次數更多時間敏感）。

來源

2011-09-27 11:04:54 Thor84no

在MySQL中存儲「不規則」數據

回答

相關問題