Типы данных псевдонимов SQL - PullRequest
Новая
       21

Типы данных псевдонимов SQL

2 голосов
/ 06 августа 2009

Я начинаю новый проект и рассматриваю возможность использования псевдонимов данных в моей базе данных SQL Server 2005 для общих столбцов таблицы. Например, Я бы определил псевдоним типа данных для хранения имени объекта следующим образом:

CREATE TYPE adt_Name FROM varchar (100) не ноль

Затем используйте его для определения столбцов таблицы, чтобы все мои столбцы имели одинаковое определение (длина, обнуляемость, точность и т. Д.).

  1. В чем преимущества использования псевдонимов типов данных?
  2. Каковы недостатки использования псевдонимов типов данных?
  3. Какие соглашения об именах вы бы порекомендовали? Я думал, adt_Xxx (adt = псевдоним типа данных).
  4. Почему SQL Server 2005 Management Studio не позволяет мне работать с псевдонимами типов данных из графического интерфейса. Я могу использовать их только через сценарии SQL. Графический интерфейс не отображает их ни в одном из выпадающих списков - это расстраивает.
  5. Как использование типов данных псевдонимов повлияет на мою модель Linq to SQL?

Ответы [ 4 ]

6 голосов
/ 11 августа 2009

Преимущества:

  • Многоразовые и разделяемые, ADT можно многократно использовать в базе данных, в которой он создан, если вы хотите использовать ее во всех ваших БД, создайте ее в базе данных модели

  • Внедрение, ADT будет обеспечивать характеристики, длину и обнуляемость своего базового типа и может использоваться для обеспечения соблюдения стандартов разработки

  • Запрещает неявные преобразования, ADT не могут быть CAST или CONVERTed

  • Простота, как и в других языках, ADT обеспечивают простоту разработки и обслуживания

  • Сокрытие данных

Недостатки:

  • Не изменяется, ADT не могут быть изменены напрямую, вы должны УДАЛИТЬ и СОЗДАТЬ их. Обратите внимание, что вы все еще можете ИЗМЕНИТЬ таблицы, в которых они находятся, на другой базовый тип или ADT, затем УДАЛИТЬ и СОЗДАТЬ их заново, затем ИЗМЕНИТЬ таблицы назад (или просто СОЗДАТЬ новую, чтобы изменить их).

  • Нет инструментов, ADT должны создаваться с помощью прямого запроса с использованием оператора CREATE (sp_addtype устарел и не должен использоваться).

  • Переменные таблицы не поддерживаются

Соглашения об именах:

  • 'adt_' похоже, что он будет работать нормально

Linq to SQL:

  • Рассматривайте эти типы как базовый тип в запросах или создайте соответствующий тип для использования
6 голосов
/ 14 августа 2009

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

В частности, вы не можете использовать их в таблицах #temp, если не определили их также в TempDB. И поскольку TempDB сбрасывается каждый раз при перезапуске SQL Server, это означает, что вам также придется переопределять их при каждом перезапуске SQL Server. Но это означает, что процедура запуска должна быть в Master и иметь определенные привилегии. А поскольку определения псевдонимов (на самом деле UDT в терминологии Ms) могут измениться, это означает, что администратор БД должен предоставить кому-то еще права на редактирование этой процедуры, что может быть проблемой безопасности.

О, и чтобы я не забыл, что если вам нужно обновить, перенести или переустановить сервер, вам потребуется внешняя копия этого процесса для повторного добавления в Master, и вы должны помнить, чтобы сделать это.

И еще есть ограничения: по моему опыту, разработчики хотят использовать эти «псевдонимы», потому что они думают, что это даст им гибкость, чтобы изменить определение позже, если им это необходимо. Не будет Постоянные данные НЕ похожи на постоянный код, они не обладают такой гибкостью, и SQL Server здесь вам мало чем поможет. После того, как вы попытаетесь сделать это один раз, вы быстро придете к выводу, что вам никогда не следовало использовать проклятые вещи.

1 голос
/ 14 августа 2009

ИМО с использованием встроенных типов - это огромная боль в шее. Другие уже привели достаточно причин, почему. Я использую макросы в стиле C Например, в моем коде SQL 2000 у меня была следующая строка в отдельном файле macros.h 

#define WIDEST_CHAR VARCHAR(8000)

Я бы использовал его следующим образом: 

#include "macros.h"

(snip)

CREATE TABLE dbo.Comments(CommentID INT NOT NULL,
Comment WIDEST_CHAR,
...

и макрос WIDEST_CHAR будет заменен на VARCHAR (8000) препроцессором. Когда я перенес свою систему в 2005, я просто заменил определение макроса на 

#define WIDEST_CHAR VARCHAR(MAX)

и все было готово.

1 голос
/ 06 августа 2009

Типы в целом хорошие, но наш проект использует их ограниченно, поэтому я могу ответить на # 2 Проблема в «изменении». Мы разработали тип TUrl как varchar (255), но через некоторое время мы попытались перейти на varchar (800). Для работающей базы данных это невозможно.

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

...