Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Проблема с ключами  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Вася1
Вася1,

Столбец типа varchar(max) может участвовать в ограничении FOREIGN KEY только при условии, что первичный ключ, на который он ссылается, также имеет тип данных varchar(max).

Ога, только "есть один нюанс":
— на столбце с типом varchar(max) / nvarchar(max) нельзя создать индекс (ну и первичный ключ, соответственно, тоже нельзя);
— FOREIGN KEY нельзя создать на временной таблице.
26 авг 13, 13:06    [14755378]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
iap
Member

Откуда: Москва
Сообщений: 47144
Вася1
Вася1,

Столбец типа varchar(max) может участвовать в ограничении FOREIGN KEY только при условии, что первичный ключ, на который он ссылается, также имеет тип данных varchar(max).
На поле типа varchar(max) создать индекс не получится.
26 авг 13, 13:08    [14755385]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Вася1
Guest
iap,

A column of type varchar(max) can participate in a FOREIGN KEY constraint only if the primary key it references is also defined as type varchar(max).

http://msdn.microsoft.com/ru-ru/library/ms189049.aspx

Вообщем сделал 2 ключа

T1 =CONSTRAINT [T1] PRIMARY KEY ([c1])
T2 = CONSTRAINT [T2] FOREIGN KEY (c1) REFERENCES [T1] (c1)
26 авг 13, 13:17    [14755420]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Вася1
iap,

A column of type varchar(max) can participate in a FOREIGN KEY constraint only if the primary key it references is also defined as type varchar(max).

http://msdn.microsoft.com/ru-ru/library/ms189049.aspx

Это ошибка в BOL.
На Коннекте, кстати, был заведён аналогичный баг про такую же ошибку в CREATE TABLE: varchar(max) in FK constraint? CREATE TABLE topic on BOL
Странно, конечно, что документалисты в MS так накосячили.
26 авг 13, 13:48    [14755549]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
iap
Member

Откуда: Москва
Сообщений: 47144
Вася1,

я проверил, прежде чем писать про varchar(max).
А у Вас, что, получается создать индекс?
26 авг 13, 13:54    [14755582]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость888
Guest
iap
Слово "всегда" имеет не так много значений.
И здесь тоже нужен. Никаких исключений!
Это как пристёгиваться в машине. Должен выработаться инстинкт.

Ну вы прям как Роршах "Никаких компромиссов!"

А как же случаи, когда:
а) мне не нужно обеспечивать уникальность строки
б) уникальность строки обеспечивается БЕЗ создания ПК ?
26 авг 13, 13:59    [14755609]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
Гость888,
Гость888
вы прям как Роршах "Никаких компромиссов!"

скорее вы не можете внять великому "всегда" от господина iap.

Пока на таблице нет кластеризованного индекса, она есть куча. А database engine'у управлять кучей не особо приятно. О ней нет никакой инфы, нет статистики, данные не структурированны и т.д. и т.п. Данный холивар уже подымался 10-ки раз на форуме. В общем случае на небольших временных таблицах разницы в перфомансе вы не заметите с индексом и без него. Однако если объеимы данных большие или плохо определяется кардинальность - тут вы и прогорите. Ввиду чего, добавляя кластеризованный всегда(!!!) вы не прогадаете( куча может быть полезна, только в однмо случае - если к ней нет никаких запросов, а есть только загрузка данных).
26 авг 13, 14:10    [14755653]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
кластерный индекс
Guest
Exproment
...кластеризованный всегда...

а какое отношение кластерный индекс имеет к PK?
26 авг 13, 14:13    [14755674]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Exproment,

Всё хорошо, только при чём здесь кучи и кластерные индексы, когда разговор шёл о первичном ключе? Или вы ставите знак равенства между первичным ключом и кластерным индексом?
Куча с первичным ключом — да легко может быть. Кластерный неуникальный индекс — да тоже легко.
26 авг 13, 14:14    [14755676]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
ааа... ну да)) чего-то подумалось, что разговор о кластеризованных индексах. Тогда мне тоже не понятна категоричность iap'а
26 авг 13, 14:24    [14755728]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость888
Guest
Пример почти из жизни, несколько урезанный.

CREATE TABLE ErrorLog
(
LogDate Datetime,
ProcName Sysname, 
ErrorText Varchar(1000), 
SysUserId Integer 
) 

CREATE CLUSTERED INDEX CIX_SysUserId_LogDate ON ErrorLog(SysUserId, LogDate) 


В каком месте здесь "необходим ПК" и зачем?
26 авг 13, 15:03    [14755941]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3754
Exproment
А database engine'у управлять кучей не особо приятно. О ней нет никакой инфы, нет статистики

а статистики-то почему нет??
и почему управлять не приятно? в information.shema больше места чтоли занимает?
26 авг 13, 15:04    [14755950]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
Гость888, Перманентная таблица без суррогатного ключа - зло! В чем была логика архитектора, когда он строил данный кластеризованный индекс ? Вы же понимаете, что на данной таблице у вас всегда будет избыточная фрагментация и каждый инсерт будет выполняться несколько дольше чем мог бы ? Причем в огромных масштабах. И я очень надеюсь, что у вас нет других некластеризованных индексов на ней и никогда не будет. И как вы уникально идентифицируете запись ? Судя по всему никак, а значит и приводить данную таблицу не стоило.

Ivan Durak
а статистики-то почему нет??

покажите мне "гистрограмму индекса", если нет индекса 0_о Или я вас неправильно понял ? Насчет остального - слишком избитая тема, чтобы снова её поднимать.
26 авг 13, 15:30    [14756116]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
iap
Member

Откуда: Москва
Сообщений: 47144
Господа-товарищи!
Теория реляционных баз данных говорит нам, что у сущностей всегда должен быть PK.
Неужели трудно просто придерживаться этого принципа?
Необходимость идентифицировать конкретный кортеж может появиться в любой момент.

Я имел в виду только это.
26 авг 13, 15:37    [14756161]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Exproment
покажите мне "гистрограмму индекса", если нет индекса

Первое, надеюсь, насчёт "гистрограммы" была просто опечатка.
Второе, гистограмма — это сущность, относящаяся к статистике, а не к индексу.
Третье, загляните в BOL в тему sys.stats:
BOL -> sys.stats
Every index will have a corresponding statistics row with the same name and ID (index_id = stats_id), but not every statistics row has a corresponding index.

Вы сами можете в этом убедиться, выполнив запрос
select * from sys.stats
и разобравшись, что из себя представляют записи со значением поля name вида _WA_Sys_00000013_5535A963.
Четвёртое, посмотрите команду CREATE STATISTICS.

Тогда вы сможете сами легко показать "гистограмму без индекса" в различных вариациях.
26 авг 13, 15:48    [14756250]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2415
Вася1, сейчас почитает споры, уважаемых донов, и сменит профессию, пока не поздно ))
26 авг 13, 15:52    [14756278]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31984
Гость888
Всегда чтобы зачем?
CREATE TABLE  #MY_TEMP_BUFFER_TABLE (string_field  NVARCHAR(MAX))  

Тоже нужен?
Скажем так, ПК не нужен намного реже, чем нужен некластерный ПК.
26 авг 13, 16:04    [14756374]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
Гость333
Второе, гистограмма — это сущность, относящаяся к статистике, а не к индексу.

Гость333, ну вы просто говорите о том, что статистика не обязательно должна быть привязана к индексу. Что собственно понятно. А я говорю, что на куче по дефолту не будет никакой статистики(по крайней мере адекватной, хотя конкретно данный вопрос не изучал ибо не имеет смысла) + данные не будут структурированы + долгое получение оригинальных данных за счет единстенно возможного IAM сканирования всей таблицы. Причем это только самые-самые азы почему куча зло. Например еще можно намекнуть на невозможность повторного использования дискового пространства.
26 авг 13, 16:22    [14756506]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
iap
Господа-товарищи!
Теория реляционных баз данных говорит нам, что у сущностей всегда должен быть PK.
Неужели трудно просто придерживаться этого принципа?
Необходимость идентифицировать конкретный кортеж может появиться в любой момент.

Я так понимаю, что вы рассуждали о PK как о суррогатном ключе. Т.е. так-же как и я посчитал, в то время как споры начались из-за понимания PK чисто как ограничения :) Т.е. это лишь вопрос понимания терминологии :)
26 авг 13, 16:27    [14756553]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Exproment
А я говорю, что на куче по дефолту не будет никакой статистики(по крайней мере адекватной, хотя конкретно данный вопрос не изучал ибо не имеет смысла)

Ну, изучите, что ли. Смысл в этом таки есть.
Кстати, что такое для вас "адекватная" и "неадекватная" статистика?
26 авг 13, 16:28    [14756557]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
Гость333, адекватная - кардинальность определяется так, что у меня нет проблем В то время как кучи, (даже если на них на самом деле строится статистика) мне часто портили запросы. Да и не понимаю я, по каким тогда полям будет строится гистограмма ? По всем, к которым есть обращения ? Но вы меня заинтриговали и вопрос обязательно изучу. Спасибо
26 авг 13, 16:39    [14756642]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость888
Guest
iap
Господа-товарищи!
Теория реляционных баз данных говорит нам, что у сущностей всегда должен быть PK.
Неужели трудно просто придерживаться этого принципа?
Необходимость идентифицировать конкретный кортеж может появиться в любой момент.
Я имел в виду только это.

Зачем тратить системные ресурсы там, где это можно не делать?
26 авг 13, 16:47    [14756691]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Exproment
Member

Откуда:
Сообщений: 416
Гость888, действительно, зачем соблюдать реляционные концепции, если их можно не соблюдать
26 авг 13, 16:58    [14756776]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
третья нормальная форма
Guest
Exproment
Гость888, действительно, зачем соблюдать реляционные концепции, если их можно не соблюдать

вы, наверно, везде жёстко третью нормальную форму соблюдаете, во имя идеалов.
26 авг 13, 17:01    [14756798]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с ключами  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Exproment
Да и не понимаю я, по каким тогда полям будет строится гистограмма ? По всем, к которым есть обращения ?

По всем, которые могут повлиять на cardinality (естественно, если рассматривать базу с включённой опцией AUTO_CREATE_STATISTICS (включена по умолчанию)).
BOL -> Setting Database Options
AUTO_CREATE_STATISTICS

When set to ON, statistics are automatically created on columns used in a predicate.
When set to OFF, statistics are not automatically created; instead, statistics can be manually created.
26 авг 13, 17:12    [14756869]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить