Понимание пользовательских типов данных в SQL - PullRequest
Новая
       1

Понимание пользовательских типов данных в SQL

0 голосов
/ 06 марта 2012

Я пытаюсь понять архитектуру образца базы данных PUBS от Microsoft. Там я смотрю на au_id Столбец, у которого есть определенный пользователем тип данных id: varchar (11) .

Итак, если я правильно понимаю, varchar (11) означает, что он позволяет вводить 11 символов в ячейку.Но если я введу

  • 11 буквенно-цифровых символов, он выдаст ошибку .
  • 11 числовых символов, выдаст ошибку
  • Но если я введу символы в формате номера телефона в США, например, 123-54-2345, , это сработает
  • Опять же, если я введу тире (дефисы) в каком-то другом порядке, т.е.1234-5-4544, снова показывает ошибку

Почему это происходит?У них есть какой-то метод для проверки этой записи.Я могу найти только определенный пользователем тип данных с именем id в User-Defined Data Type Folder

Заранее спасибо.

1 Ответ

4 голосов
/ 06 марта 2012

Хорошо, только что нашел скрипт, который создаст базу данных pubs.

Столбец au_id по авторам определяется как: 

CREATE TABLE authors
(
   au_id          id
     CHECK (au_id like '[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]')
     CONSTRAINT UPKCL_auidind PRIMARY KEY CLUSTERED,
  /* More columns */

Это ограничение CHECK отклоняет ваши недопустимые значения, а не что-либо связанное с пользовательским типом. Если вы изучите сообщения об ошибках, вероятно, упомянет , что это ограничение CHECK, которое не выполняется.

(Кстати - я предположил, что это был формат SSN, а не номера телефонов - кто-нибудь подтвердит?)

Пользовательские типы в SQL Server (кроме табличных) не представляют особой ценности - все, что они на самом деле делают, - это ассоциированное сокращенное имя для встроенного типа со всеми фиксированными параметрами масштаба / точности / длины.

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

...