Немного поздно, но .. мои 2 кар.
Пользовательские типы выполняют роль домена в концептуальных и логических моделях, поэтому, если вы хотите реализовать свою логическую модель данных в физической базе данных, использование пользовательских типов будет самым близким приближением. Это обеспечит такие преимущества, как использование графической модели, которую можно автоматически перенести в реализацию, лучше, чем это можно сделать без использования UDT.
Использование доменов позволяет обнаруживать попытки сохранить почтовый код в поле SSN и обнаружить их в базе данных во время выполнения (или даже во время компиляции). Это позволит вам применять корпоративные бизнес-правила там, где они должны применяться: в тот момент, когда данные попадают в хранилище. В любом другом месте это вежливость к пользователю, но именно здесь они абсолютно ДОЛЖНЫ быть обеспечены, чтобы никто не обошел их.
Кроме того, UDT, определенные в ANSI SQL: 1999, инкапсулируют методы и могут иметь подтипы. Это означает, что определенные изменения в бизнес-правилах, которые имеют дело с ограничениями, могут быть изменены в базе данных, даже не затрагивая реализацию.
Однако ... поскольку реализованные в настоящее время UDT оставляют желать лучшего. Я даже не уверен, что SQL Server реализует стандарт, как описано, и даже менее уверен в Oracle. И даже если они это сделают, недостатки использования UDT станут очевидными сразу после использования инструментов BI, ETL или других довольно простых инструментов: они обычно не понимают UDT, и даже если они это сделают, они не будут возможность использовать их, потому что большинство основывается на базовых типах (int, char и date / time).
Что касается инструментов отчетности, давайте рассмотрим UDT, который имеет комбинацию полей. Теперь, как независимый от базы данных ETL-инструмент сможет понять тип? Он должен быть в состоянии понять структуру, чтобы отобразить ее или использовать для расчетов. И это для каждой поддерживаемой базы данных - сложная задача. И поскольку никто не использует UDT, они этого не сделают. Это замкнутый круг, но мы все еще должны с ним жить.
Кроме того, поддержка UDT в большинстве баз данных также не так уж и актуальна. Смена типов может быть довольно сложной. Хотя синтаксис должен быть везде одинаковым, их администрирование в SQL: 1999 не определено и поэтому везде различно. Попробуйте сменить владельца UDT на сервере sql для примера. Раньше это было довольно сложно - не уверен насчет SQL Server 2016, но, учитывая, что UDT не выглядят как фокус, я не ожидаю серьезных улучшений в этой области.
Наконец, если вы добавляете действительно сложный код в UDT, вы сталкиваетесь со старой проблемой, которую вы программируете в среде, в которой отсутствуют хорошие параметры отладки. Это тоже не поможет.
Итак: если у вас есть полный контроль над вашей базой данных, и все взаимодействие происходит через ваше программное обеспечение, UDT могут быть чрезвычайно полезны. Если нет, они могут быть огромной боли в шее. То, что имеет место в вашем сценарии, это только то, что вы можете сказать.