我有一個數據庫類，教授希望我們爲每種類型創建域，即使這些類最終只是其他類型的別名。例如，取代使用默認的DATE類型，我們可以根據它是哪一天創建自己的類型（例如，OrderDate）。爲每個「邏輯」域創建域
我想知道這是常見還是最佳做法。
我可以想到這種方法的一些優點和缺點。一個專業人士可以清楚地知道該域名的用途，通常我們只會比較字段，如果他們有相同的域名，並且任何其他比較值得注意（因爲它可能會比較蘋果和橙子）。但是作爲一個con，這也使得它更容易處理這些類型，因爲我們不得不引用域聲明來找出列的真實類型（而不是我們經常需要這樣做） 。
這不是特別常見的做法。例如，多年來我一直在處理很多數據庫，而且我從來沒有使用過這種基本類型的替換。
在您的示例中，例如，訂單日期可能是訂單日期。但是，我可能想知道過去多久 - 這需要「混合」類型，因爲當前日期（sysdate？now()？getdate()？CURRENT_TIMESTAMP？）不是OrderDate。或者我可能想知道在第一次投訴或第一次投訴的訂單後多久。即使轉換是不可見和自動的，爲什麼引入不兼容的類型呢？
另一個問題是不同的數據庫在支持用戶定義的數據類型方面有所不同。因此，使用用戶定義類型的代碼可能會使代碼更難以移植到不同的數據庫。爲什麼限制未來的選擇
用戶定義類型有一些偶爾的用法做有一個地方可能需要特定的新類型 - 複數和點也許。在某些數據庫中甚至可能會出現這樣的情況：用戶定義的基本類型類型非常有用 - 例如，始終如一地表示電話號碼。用它們自由地替代內置類型？這似乎是過度殺傷，使代碼複雜化，妨礙了一些重要的查詢，並限制未來的可移植性選項。