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

Вони дозволяють визначити обмежений тип даних, який буде використовуватись у їхній базі даних, щоб спростити та застосувати правила, що стосуються дозволених значень. Такий тип даних може бути використаний у деклараціях стовпців, у входах та виведеннях для збережених процедур та функцій тощо ...

Я хотів би знати:

• Чи реально люди використовують домени у своїх проектах баз даних?
• Якщо так, то в якій мірі?
• Наскільки вони корисні?
• З якими підводними каменями ви стикалися?

Я намагаюся оцінити життєздатність їх використання в майбутньому розвитку бази даних.

Як завжди...

Це залежить

Чи є у вас доменне об'єднання, яке використовується в більш ніж одному місці, що підтримка в основному вимагає значних зусиль та / або зайвих обмежень та поведінки ?

Якщо так, вилучіть домен. Якщо ні, не турбуйте.

Я вважав за необхідне створити визначений користувачем тип в SQL Server рівно один раз, виходячи з вищевказаного евристичного. Навіть не пам’ятаю, що це було більше - але це врятувало більше роботи, ніж спричинило.

Як користувач SQL Server та C #, я не використовував визначені користувачем типи в базі даних, оскільки я досить потужніший у застосуванні. Подія після таких ORM, як LINQ для SQL та Entity Framework, моє використання серверних можливостей значно скоротилося.

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

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

Хоча це не означає, що люди не використовують Домен бази даних , це, безумовно, означає, що принаймні використання Домену бази даних не є такою поширеною.

Детальна відповідь про переповнення стека вже є . Я в основному погоджуюся з цим, але не з наведеним прикладом, цитую:

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

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

Звичайно, просто лише особиста думка. Інші люди сказали б, щоin ('M', 'F') обмеження не є самодокументуванням і може бути дуже незрозумілим для нового розробника, який відкриє базу даних.

IMO, використовуйте визначені користувачем типи для більш складних типів та обмежень для чогось базового. Крім того, коли ви не можете легко знайти явне ім’я для типу, є ймовірність, що обмеження підійде краще.

Я сам не використовував цю функцію, але, мабуть, вам потрібно переконатися, що:

1. Якщо ваша база даних використовується однією системою, можливо, не має сенсу використовувати цю функцію та додавати логіку перевірки у вашому бізнес-рівні або його еквіваленті. Це дасть вам більшу гнучкість у валідації (скажімо, у використанні регулярних виразів) і дасть можливість інкапсулювати всю логіку перевірки в одному місці. Якщо ваша база даних поділяється декількома системами, ви можете замість цього використовувати тригери, які добре підходять для цього завдання.

2. Я не впевнений, чи дозволяє UDT налаштовувати повідомлення про помилки, повернені клієнту, коли виникає помилка перевірки.

3. УДТ дуже корисні, якщо одне і те ж правило перевірки застосовується до кількох стовпців. На мою думку, я не вважаю це дуже поширеним випадком у бізнес-застосуванні з нормалізованим дизайном баз даних.

Можливо, вам буде цікаво перевірити "Який сенс визначених користувачем типів [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: діапазон, що міститься в операторі діапазону).

У той момент, ви вже виправдали розширення підтримки типу даних, є ще один крок до визначення нового типу даних.

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

What pitfalls have you encountered?

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

Найбільші проблеми, які я можу побачити з цим, - це винахід колеса, введення помилок у "безпечний" шар (db), неповна підтримка типу, яку ви зрозумієте лише через місяці, коли ваш CONCAT (cast * AS varchar) вийде з ладу, тому що ви не визначив акторський склад (новий тип як varchar) тощо.

Є відповіді, які говорять про "нечасто" тощо. Безумовно, це є і мають бути рідкісними (інакше це означає, що dbms не має великої кількості важливих типів), але з іншого боку, слід пам'ятати, що (хороший) db сумісний із кислотою ( на відміну від програми) і що все, що стосується консистенції, краще зберігати там.

Є багато випадків, коли бізнес-логіка обробляється на програмному рівні, і це можна зробити в SQL, де це безпечніше. Розробники додатків, як правило, відчувають себе комфортніше в межах додаткового шару і часто уникають кращих рішень, реалізованих у SQL, це не слід розглядати як добру практику.

UDT можуть бути хорошим рішенням для оптимізації, хороший приклад наведено в іншій відповіді про тип m / f за допомогою char (1). Якби це був UDT, він міг би бути булевим (якщо тільки ми не хочемо запропонувати третій та четвертий варіанти). Звичайно, всі ми знаємо, що це насправді не оптимізація через накладні стовпців, але можливість є.

На папері УДТ - чудова концепція. Вони дозволяють по-справжньому нормалізувати свою БД (наприклад, коли у вас є два стовпчики, які залежать один від одного), а також інкапсулювати будь-яку логіку, пов’язану з вашим новим типом.

На практиці ціна, яку ви платите (сьогодні), зависока. Очевидно, що є надмірні розробки, але окрім цього, ви втрачаєте підтримку різноманітних інструментів ORM та звітності та значно збільшуєте загальну складність рішення. Там не надто багато розробників, які добре знайомі з UDT, і я ніколи не бачив керованих UDT, використовуваних поза прикладами.

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

Більш практичне питання / відповідь. Чи дозволяє ваша компанія ним користуватися?

Ваша компанія працює з кількома брендами DBSQL, які обробляють різні DDL (и)?

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

Якщо компанія є лише ви, або ви можете вирішити, які Бази даних та функції ви будете використовувати, тоді ви можете використовувати DDL

Я працюю з кількома проектами, де тип, визначений користувачем, може бути корисним, але я повинен дотримуватися більш стандартних функцій, оскільки нам довелося мати справу з декількома БД. (и).