我正在爲我們的設計團隊選擇使用「Field1」..「Field10」作爲通用,未來目的列的公司工作。我向他們詢問了原因,並被告知他們在那裏以防將來需要他們。在數據庫中使用通用列 - 爲什麼?
有沒有人聽說過這種做法?當我看到類似這樣的事情時,我的下巴掉到地板上是不對的?
我正在爲我們的設計團隊選擇使用「Field1」..「Field10」作爲通用,未來目的列的公司工作。我向他們詢問了原因,並被告知他們在那裏以防將來需要他們。在數據庫中使用通用列 - 爲什麼?
有沒有人聽說過這種做法?當我看到類似這樣的事情時,我的下巴掉到地板上是不對的?
你根本沒有錯。不知道在編寫ADD COLUMN
更改腳本時遇到什麼困難。
如果這些列沒有被應用程序引用(並且根本無法使用),那麼這是最糟糕的一種YAGNI濫用。
但是,如果這是一個產品將在人們不是在你的公司保持着進行部署,這是有道理的把這樣的佔位符(假定應用程序「知道」如何訪問和使用它們)對未來無法預料的擴張。
在實踐中?那麼,有一小套叫做「Oracle電子商務」的應用程序,其中有大量名爲ATTRIBUTEn的列,其中n從1到20或更多。最重要的應用程序配置給他們帶來了商業上的意義,但這就是表格下面的樣子。
在另一方面,某些應用程序在運行中創建自定義的數據庫表 - 這需要一些代碼更復雜,但少人(和,恕我直言,更少的配置愚蠢)。只是很高興你沒有某種形式的瘋狂,所有的自定義字段存儲在一個單一的關鍵型值表 - 我已經看到過了,它只是錯誤。
是不是Oracle爲我們帶來了Oracle Forms? 'Nuff said ...--( – 2010-05-20 14:45:29
)謝謝,這可能是我們爲什麼這樣做的結果,這些專欄的結果最終以報紙形式出現,所以很可能與這種情況類似,也許他們害怕添加列 – Sprague 2010-05-20 14:47:45
@Pontus Gagge:我不認爲這是最好的解決辦法,但它可以工作 @Sprague:。創建機制,根據用戶的自定義添加列,是不平凡的那是複雜的部分 - 很好,那並能夠讓前端應用程序跟蹤這些更改,它需要應用程序生成大量元數據,其中「通用列」解決方案需要用戶(或顧問)配置,並且編碼起來更容易 – 2010-05-20 14:52:31
遇到過,是的,即使在所謂的商業產品。一般來說,當人們不真正瞭解關係數據庫,並且不關心未來的維護成本時就會發生這種情況。
當然,關係型數據庫是不是在處理未來的打樣真的很棒。您通常需要演進模式併爲升級提供數據遷移路徑。這看起來似乎更復雜和昂貴,但與沒有任何數據完整性檢查的匿名列相比......呻吟!
如果需要額外的列,修改表格會出現什麼問題? – 2010-05-20 14:42:01
我認爲這是處理稀缺資源的一種非常合理的方式。如果新鮮的表格列的供應用完了怎麼辦?您會收到您的最大客戶的緊急請求,將這些新列添加到表中,並且辦公室供應商店中沒有列,Oracle會通知您他們可以在6到8周內發送一些內容......這不會是災難性的?事實上,你應該保存一些空表,以防萬一:-P對不起,我無法抗拒... – 2010-05-20 14:51:34
@彼得 - 感謝在我生命中最長的一小時裏給我一個很好的笑聲! – Shaded 2010-05-20 15:48:50