2011-01-27 65 views
2

我們正在設計一個管理聯繫人信息的應用程序。允許用戶即時將數據列添加到其數據庫的最佳方式是什麼?

客戶的要求之一是允許他們的高級用戶或管理員工通過用戶界面向數據庫添加列。客戶無法直接訪問數據庫(即無法使用SSMS打開並進行更改)。

我看到的控件有:1)輸入字段的名稱,2)輸入數據類型,3)選擇要添加字段的表。一旦用戶點擊一個按鈕,數據庫將更新爲新的字段。我需要檢查適當的權限,該字段是否已經存在等。我們還需要將表單字段連接到這個新字段,例如報表設計器界面。

  1. 我在哪裏可以找到一個示例顯示我想要做什麼?
  2. 這樣做有什麼缺點?除了這麼做的開發者看起來是一份體面的工作。
  3. 你會推薦這樣做嗎?如果不是,什麼是更好的解決方案?

編輯 - 我們需要使用SQL Server。不可議價。

+0

你使用`sql server`鎖定了嗎?也許像`mongodb`這樣的無模式數據庫更適合您的問題。 – Chris 2011-01-27 22:46:04

+0

*最好的辦法*做到這一點? **不!** – 2011-01-28 05:48:32

回答

11

這是絕對的要求,他們添加列到表,或只是他們能夠指定額外的領域來存儲?我強烈建議你考慮像Entity-Attribute-Value之類的東西,而不是讓最終用戶(管理員作爲最終用戶)來進行模式更改。

對於這樣的事情,您需要一個表來定義您的自定義字段,然後是多對多關聯表,以允許用戶爲聯繫人的自定義字段指定一個值。例如:

Contact 
    --------- 
-> ContactId 
| FirstName 
| LastName 
| etc. 
| 
|      ContactField 
|      -------------- 
|      ContactFieldId <--- 
|      FieldName   | 
|           | 
| ContactFieldValue      | 
| -------------------      | 
-- ContactId        | 
    ContactFieldId ------------------------- 
    Value 

實現的細節顯然是由你(例如,是否使用ContactId + ContactFieldIdContactFieldValue複合主鍵),但這應該傳達出的總體思路。

2

參考此鏈接的解決方案:C# Dynamically Add Columns to table in Database

老實說,我認爲,讓用戶控制添加列可能是不這樣做,因爲它是被濫用的最好的事情。而用戶在技術上可能並不瞭解數據庫結構。而且表之間的多對多關係會發生什麼。

希望這會有所幫助。

1

處理這種情況的簡單方法是預先定義6個(或其他)「備用」列,並且有一個額外的表,該表可以從您給列的名稱映射到名稱你向用戶展示。如果它爲空(例如),則不會在窗體上顯示該字段,但如果它非空,則顯示具有該名稱的字段。這樣他們可以自定義,但不會改變表格本身(可能是相當於在大表格中緩慢)。

0

您必須確保用戶不超過最大記錄大小。不確定2008年如何響應DDL,這會導致行超過行的最大字節數。 http://msdn.microsoft.com/en-us/library/ms143432.aspx - 如果你還不知道,可以測試一下。

我不會推薦這個。但是,國際金融機構都這樣做,我會做的UI交互性和簡單化向下:

  What kind of field do you want to add? 
       Date-time 
       number without a decimal point 
       number with a decimal point 
       little text note 
       large text note 
       image 
       yes/no 
       etc etc 
0

有趣的命題 - 讓他們進行更改的數據庫,但不允許他們使用設計的工具目的?

我建議給他們兩個數據類型,一個nvarchar最大長度和一個數字(如果可以,則爲整數,如果他們需要,則爲十進制)並查看得到它們的距離。

但是,如果您嘗試構建太多限制條件,我希望您會有一個永無止境的過程來確定在不損害自己或其他人的情況下做好自己的工作。 (太多了,他們會自我傷害 :)即使是專業人員也會傷害自己。)

4

我強烈推回要求,讓他們知道這是一個非常糟糕的主意。是的,你可以爲這些表添加一個EAV表,但是你有問題,查詢它既不簡單也不表現。或者,您可以像@Jerry Coffin所建議的那樣,使用六張備用欄目的表格,但他會導致報告困難,並且在他們全部使用它們時會發生什麼情況。所有這些都導致開發人員進行大量額外的工作,以支持一年內可能不會導致3次數據庫更改的要求。您冒着數據完整性,數據庫性能和報告準確性的風險(我敢打賭,這些新字段不會有PK/FK關係或默認值,或者甚至是正確的數據類型,因此日期是變化的,因此數據將被添加到數據庫中的會費日期是ASAP,不適用於報告),以及所有不知道他們在做什麼的人都可以假裝進行數據庫更改,這些數據庫更改效率低下,思路不清。

我已經與許多COTS產品合作過,當人們實際添加列時(實際上很少有人足夠勇敢地這樣做)。他們沒有按照他們需要的形式出現,他們也不會自動添加到報告中,他們通常無法搜索,並且在每種情況下,他們最終花費更多的錢去解決他們製作的數據混亂問題讓專業人員進行設計更改會有成本。

大多數時候,當我看到這樣的要求時,高級管理人員認爲靈活性很酷,而不是任何高級用戶實際需要甚至想要這樣做。他們需要意識到他們所要求的成本。

花費更多的時間和額外的幾天與高級用戶談論他們需要的東西並獲得設計開始的權利,而不是走下這條路。

這是真正需要長時間嚴肅討論的要求之一,它不僅需要開發時間花費多少,而且數據完整性和性能以及可維護性幾乎沒有增益。我會做一個正式的成本效益分析,以向他們展示這個想法到底有多糟糕。然後,一旦他們完全沉浸於他們所要求的完全愚蠢的行爲,如果他們仍然需要它,繼續建設並開始尋找新的工作,因爲你不想成爲一個必須維護的人這個。

相關問題