Много ли пользователя DataTypes SQL много используются? [закрыто

Question

Мой DBA сказал мне использовать пользовательский DataType SQL для представления адресов, а затем использовать один столбец этого нового типа в нашей таблице пользователей вместо нескольких столбцов адресов. Я никогда не делал этого раньше и задавался вопросом, является ли это общим подходом.

Кроме того, какое место лучше всего получить информацию об этом - это специфично для продукта?

Answer 1

Есть ряд других вопросов о ТАК о том, как представлять адреса в базе данных. Afaicr, ни один из них не предлагает пользовательский тип для этой цели. Я бы не стал рассматривать это как общий подход; Это не значит, что это не разумный подход. Основные трудности заключаются в принятии решения о том, какие методы предоставить для манипулирования адресными данными - те, которые используются для форматирования данных, чтобы появиться на конверте, или в конкретных местах в печатной форме или для обновления полей, беспокоясь о многих последствиях международных адресов , и так далее.

Определение пользовательских типов очень специфично. Способности вы делаете это в Informix, отличаются от того, как это делается в DB2 и Oracle, например.

Answer 2

Насколько я могу судить, по крайней мере, в мире SQL Server, UDT не используется.

Проблема с UDT заключается в том, что вы не можете легко обновить их. После создания и использования в базах данных они почти как набор в камне.

Не существует команды «Создать или изменить (udt)» :-( Так что чтобы что -то изменить, вам нужно много перетасовать - возможно, копирование существующих данных, а затем отбрасывая множество столбцов из других таблиц, а затем сбрасывая UDT, re -Создание его с помощью новой структуры и повторное применение данных и всего.

Это слишком много хлопот - и вы знаете: там будут Будьте изменены!

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

Марк

Answer 3

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

Вместо этого, если вы используете какой -либо объект -ориентированный язык, создайте композиционное отношение для определения адресов для сотрудника (например) и хранить адреса в отдельной таблице.

Например. Таблица сотрудников и таблица работников_адресс. Один сотрудник может иметь несколько адресов.

Answer 4

Пользовательский DataType SQL для представления адресов

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

Другие посты здесь критиковали UDT, но я думаю, что у них есть удивительное применение. PostgreSQL имел полный текстовый поиск в качестве плагина на основе UDTS в течение долгого времени, прежде чем полнотекстовый поиск был фактически интегрирован в основной продукт. Прямо сейчас Postgis - очень успешный продукт ГИС, который является полностью плагином, основанным на UDT (у него есть лицензия GPL, поэтому никогда не будет интегрирована в ядро).