Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Задание уникальности, есть разница?  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
Здравствуйте уважаемые!
Есть ли какая-то разница при задании уникальности так:
CREATE TABLE TransactionHistory2
 (
   TransactionID int NOT NULL UNIQUE 
   )


и вот так:
CREATE TABLE TransactionHistory
 (
   TransactionID int NOT NULL, 
   CONSTRAINT AK_TransactionID UNIQUE(TransactionID) 
)


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

Например:
CREATE TABLE [dbo].[tblMeasure] (
		iMeasure	int			IDENTITY	PRIMARY	KEY
,		strShortName	nvarchar(10)	NOT	NULL	           UNIQUE
,		strFullName	nvarchar(64)		NULL
)

Насколько я знаю кластерный индекс по умолчанию создается на первичном ключе.
Имеет ли смысл переопределять кластерный индекс на естественный первичный ключ (в данном примере strShortName) если таблица не большая? Пара десятков строк всего. Если не имеет, то с какого количества записей это может иметь смысл?
Спасибо.
10 янв 14, 21:48    [15399571]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Изерлонер,

автор
Есть ли какая-то разница


Есть! В имени созданного объекта - ограничения.

автор
Насколько я знаю кластерный индекс по умолчанию создается на первичном ключе.


Если только явно не указать обратного.

автор
Имеет ли смысл переопределять


Подумайте, что надо будет предпринять, если Вы переопределите PK на естественный ключ, в таблице, ссылающейся на нее по FK будет много записей и Вам надо будет изменить strShortName. Уж про длину PK до 20 байт и говорить не хочется.
10 янв 14, 21:57    [15399597]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
Студия Бразерс
Guest
Если нужен именно кластерный ключ - то лучше суррогатный. Так как при обновлении ключевых полей кластерного индекса, изменяются все некластерные индексы. При твоем объеме наплевать какой ключ будет кластерный или нет. таблица в одну страницу индекс тоже.
10 янв 14, 21:58    [15399605]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
нет PK так и остается на поле iMeasure inc Identity, вопрос был только про кластерный индекс, который возможно имеет смысл определить по более "говорящему самому за себя" полю, так как первое просто порядковый номер, которым удобно пользоваться, но и не более того.
Ну и аналогичные таблицы есть в несколько десятков тысяч записей. ... В сотни тысяч вроде нет.
10 янв 14, 22:06    [15399652]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Изерлонер
возможно имеет смысл...


Не имеет.
10 янв 14, 22:09    [15399670]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
pkarklin
Есть! В имени созданного объекта - ограничения.


Только лишь? Ну это можно пережить :))
А вообще меня несколько сбило с толку появление перевернутого ключика на поле в отображении в Management Studio, при отсутствии ограничения в списке "Ограничения". Впрочем отсутствует оно и при явном задании ограничения с именем и ключик там же на месте.
10 янв 14, 22:14    [15399688]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
Изерлонер
Member

Откуда: СФО
Сообщений: 1269
pkarklin,

спасибо.
10 янв 14, 22:15    [15399691]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
o-o
Guest
Изерлонер
вопрос был только про кластерный индекс, который возможно имеет смысл определить по более "говорящему самому за себя" полю, так как первое просто порядковый номер, которым удобно пользоваться, но и не более того.


у Вас какой-то неправильный "тайный смысл" вкладывается в слово "кластерный".
"кластерный" не имеет ничего общего с понятием "говорящий", он должен быть удобен серверу,
а не кому-то одушевленному. кластерный ключ будет входить во все некластерные,
поэтому он должен быть по возможности:
an ever-increasing, unique, static and as narrow as possible. ideally, non-nullable and fixed-width.
(искать в интернете на Kimberly Tripp)

Ваш вопрос надо задать с точностью до наоборот:
вот если у меня есть отвечающий всем критериям идеальности кластерный ключ,
но мне захотелось сделать кластерным некий естественный, сам за себя говорящий.
начиная с какого объема эта моя хотелка начнет отрицательно сказываться на производительности?

сделали кластерные identity -- отлично. оставьте как есть
11 янв 14, 00:12    [15400298]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
Ну, про все остальное вам уже сказали, так что скажу про именование служебных объектов типа ограничений, индексов, дефолтов и проч.

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

Ну или можно написать скрипт по единообразному переименованию, я такой всегда использую, когда ко мне какая-либо чужая БД попадает.
11 янв 14, 06:25    [15400855]     Ответить | Цитировать Сообщить модератору
 Re: Задание уникальности, есть разница?  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 5975
Ennor Tiegael
Ну, про все остальное вам уже сказали, так что скажу про именование служебных объектов типа ограничений, индексов, дефолтов и проч.

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

Ну или можно написать скрипт по единообразному переименованию, я такой всегда использую, когда ко мне какая-либо чужая БД попадает.

Ну, и в случае именованных unique/primary key по ним создаются одноименные индексы. При необходимости прохинтовать запрос всегда удобнее писать with(index(uq_somename)), чем with(index(UQ__mytable__3BD019920CD8196F)).
11 янв 14, 06:47    [15400862]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить