Стандарты SQL92 и SQL99 определяют конструкции DDL . Не все базы данных поддерживают это или имеют другое имя (например, SQL Server имеет пользовательские типы ).CREATE DOMAIN

Это позволяет определить ограниченный тип данных, который будет использоваться в их базе данных, чтобы упростить и обеспечить соблюдение правил, касающихся разрешенных значений. Такой тип данных может использоваться в объявлениях столбцов, во входах и выходах хранимых процедур и функций и т. Д.

Я бы хотел знать:

• Люди фактически используют домены в своих проектах базы данных?
• Если да, то в какой степени?
• Насколько они полезны?
• С какими подводными камнями вы столкнулись?

Я пытаюсь оценить целесообразность их использования в будущем при разработке баз данных.

Как обычно...

По-разному

Есть ли у вас доменная сущность, используемая более чем в одном месте , для поддержки которой в противном случае потребовались бы значительные усилия и / или избыточные ограничения и поведение ?

Если это так, домен прочь. Если нет, не беспокойтесь.

Я считаю необходимым создать пользовательский тип в SQL Server ровно один раз, основываясь на вышеупомянутой эвристике. Я даже не помню, что это было больше - но это сэкономило больше работы, чем вызвало.

Как пользователь SQL Server и C #, я не использовал определяемые пользователем типы в базе данных, так как я довольно мощный в области приложений. После событий ORM, таких как LINQ to SQL и Entity Framework, мое использование возможностей сервера значительно сократилось.

Например, я использовал интеграцию CLR для загрузки некоторых функций преобразования DateTime в SQL Server, чтобы перевести григорианские даты и время в другие форматы, основанные на возможностях глобализации .NET. Но сейчас все по-другому, и я больше этим не занимаюсь. Я просто загружаю данные и выполняю преобразование прямо на уровне приложения.

Итак, после почти 4-х лет программирования и осмотра всех команд, о которых я могу думать, я не нашел образца использования пользовательских типов. Я также не видел это в действии во многих блогах .NET.

Хотя это не означает, что люди не используют домен базы данных , это, безусловно, означает, что, по крайней мере, использование домена базы данных не является распространенным явлением.

Уже есть подробный ответ по переполнению стека. Я в основном согласен с этим, но не с приведенным примером, я цитирую:

«Например, я определяю« GenderType »(char (1), не обнуляемый, с буквой« M »или« F »), который гарантирует, что в поле Gender разрешены только соответствующие данные».

Лично мне удобнее устанавливать char(1)тип и определять ограничение на столбец. Когда ограничение нарушается, я точно знаю, где искать, чтобы найти то, что я сделал неправильно. Он также более известен, чем определяемые пользователем типы, поэтому для начинающих будет проще понять базу данных, которая использует только ограничения.

Конечно, это просто личное мнение. Другие люди сказали бы, что in ('M', 'F')ограничение не является самодокументированным и может быть очень неясным для нового разработчика, который обнаруживает базу данных.

ИМО, используйте пользовательские типы для более сложных типов и ограничения для чего-то базового. Кроме того, когда вы не можете легко найти явное имя для типа, есть вероятность, что ограничение будет соответствовать лучше.

Я не использовал эту функцию сам, но я думаю, вам нужно убедиться, что:

1. Если ваша база данных используется одной системой, возможно, имеет смысл не использовать эту функцию и не добавлять логику проверки в бизнес-уровень или его эквивалент. Это даст вам больше гибкости в валидации (скажем, в использовании регулярных выражений) и позволит инкапсулировать всю логику валидации в одном месте. Если ваша база данных используется несколькими системами, вы можете использовать триггеры, которые хорошо подходят для этой задачи.

2. Я не уверен, позволяет ли UDT настраивать сообщения об ошибках, возвращаемые клиенту при обнаружении ошибки проверки.

3. UDT очень полезны, если одно и то же правило проверки применяется к нескольким столбцам. На мой взгляд, я не считаю это очень распространенным случаем в бизнес-приложениях с нормализованным дизайном базы данных.

Возможно, вас заинтересует проверка «Какой смысл пользовательских типов [SQL Server]?» статья в блоге.

Когда вы говорите «не все базы данных поддерживают это», я думаю, что лучший способ выразить это так:

Все основные базы данных поддерживают это, поскольку они поддерживают триггеры, функции и другие расширенные функции.

Это приводит нас к выводу, что это часть продвинутого SQL и имеет смысл в какой-то момент.

Do people actually use domains in their database designs?

Наименее возможный из-за необходимого широкого охвата (с учетом операторов, индексов и т. Д.)

If so to what extent?

Опять же, настолько ограниченно, насколько это возможно, если существующий тип в сочетании с небольшой дополнительной определенной логикой (например, проверки и т. Д.) Может добиться цели, зачем идти так далеко?

How useful are they?

Много. Давайте на секунду рассмотрим не очень хорошую СУБД, такую ​​как MySQL, которую я выбрал для этого примера по одной причине: ей не хватает хорошей поддержки для типа inet (IP-адрес).

Теперь вы хотите написать приложение, которое в основном ориентировано на данные IP, такие как диапазоны и все такое, и вы застряли с типом по умолчанию и его ограниченной функциональностью, вы либо напишите дополнительные функции и операторы (например, те, которые изначально поддерживаются в postgreSQL для пример) или напишите гораздо более сложные запросы для каждой функциональности, которая вам нужна.

Это тот случай, когда вы легко сможете оправдать время, потраченное на определение ваших собственных функций (inet >> inet в PostgreSQL: диапазон, содержащийся в операторе range).

К этому моменту вы уже оправдали расширение поддержки типов данных, есть только один шаг к определению нового типа данных.

Теперь вернемся к PostgreSQL, который имеет действительно хорошую поддержку типов, но не имеет беззнакового типа int, который вам нужен, потому что вы действительно заботитесь о хранилище / производительности (кто знает ...), так что вам нужно добавить его, а также операторы - хотя, конечно, это в основном вывод существующих операторов int.

What pitfalls have you encountered?

Я не балуюсь этим, так как до сих пор у меня не было проекта, который требовал и оправдывал время, необходимое для этого.

Самая большая проблема, с которой я могу столкнуться, это переизобретение колеса, внесение ошибок в «безопасный» слой (db), поддержка неполного типа, которую вы поймете только через несколько месяцев, когда ваш CONCAT (cast * AS varchar) завершится неудачно, потому что вы не определили приведение (newtype как varchar) и т. д.

Есть ответы, говорящие о «необычном» и т. Д. Определенно, они есть и должны быть необычными (в противном случае это означает, что в dbms отсутствует много важных типов), но с другой стороны, следует помнить, что (хороший) db совместим с ACID ( в отличие от приложения) и что все, что связано с согласованностью, лучше хранить там.

Во многих случаях бизнес-логика обрабатывается на программном уровне, и это может быть сделано в SQL, где это безопаснее. Разработчики приложений, как правило, чувствуют себя более комфортно на уровне приложений и часто избегают лучших решений, реализованных в SQL, это не должно рассматриваться как хорошая практика.

UDT могут быть хорошим решением для оптимизации, хороший пример приведен в другом ответе о типе m / f с использованием char (1). Если бы это был UDT, он мог бы быть логическим (если мы не хотим предлагать третий и четвертый варианты). Конечно, мы все знаем, что это не совсем оптимизация из-за накладных расходов столбца, но такая возможность есть.

На бумаге UDT - отличная концепция. Они позволяют вам по-настоящему нормализовать вашу БД (например, когда у вас есть два столбца, которые зависят друг от друга), а также инкапсулировать любую логику, связанную с вашим новым типом.

На практике цена, которую вы платите (сегодня) слишком высока. Очевидно, что это накладные расходы на разработку, но помимо этого вы теряете поддержку со стороны различных ORM и инструментов отчетности и значительно увеличиваете общую сложность решения. Существует не так уж много разработчиков, которые хорошо знакомы с UDT, и я никогда не видел, чтобы управляемые UDT использовались за пределами примеров.

Один из лучших примеров типа, который лучше всего сделать как UDT (если он еще не существует), должен быть hierarchyid( ссылка MSDN ). Чтобы оставаться эффективным, он сохраняет свое значение в двоичном формате (в отличие от обычных пользовательских реализаций varchar), которые было бы громоздко поддерживать без функций типа. 10 или около того методов, которые предоставляет тип, также лучше всего предоставлять как часть типа, в отличие от внешних функций. Я хотел бы рассмотреть возможность использования пользовательского управляемого UDT в таких случаях, как этот, где есть значительный выигрыш, если обеспечить эффективную и аккуратную реализацию в виде отдельного типа.

Более практичный вопрос / ответ. Ваша компания позволяет использовать это?

Ваша компания работает с несколькими брендами DBSQL, которые работают с разными DDL?

Каждая марка базы данных может предлагать хорошие дополнительные функции, такие как пользовательские типы, но, если ваша компания использует несколько БД, у вас могут возникнуть проблемы с нестандартными функциями.

Если компания принадлежит только вам, или вы можете решить, какие базы данных и функции вы собираетесь использовать, то вы можете использовать DDL

У меня есть работа с несколькими проектами, где пользовательский тип может быть полезен, но я должен придерживаться более стандартных функций, так как нам приходилось иметь дело с несколькими БД. (С).