Sergej_SP.S. Только не через TYPE, а VARTYPE конечно.
А какая разница?! Только в ковычках (для TYPE) или без ковычек (для VARTYPE) переменная.
С уважением, Алексей.
А если серьезно, то использование типа данных UNIQUEIDENTIFIER в качестве Primary Key для таблицы имеет не только положительные моменты (о них уже ВладимирМ сказал), но и отрицательные:
1. Длина. Integer - 4 - байта, а UNIQUEIDENTIFIER - 16 байт. В 4 !!! раза больше. На больших таблицах вы получите огромный проигрыш в размерах таблицы (и тем более в размере ВСЕХ некластерных индексов, если по UNIQUEIDENTIFIER построен кластерный индекс) и в конечном итоге, в скорости запросов. Если при этом вам не требуется уникальность "в пределах вселенной", а достаточно обеспечить уникальность в пределах таблицы, то тип данных UNIQUEIDENTIFIER явно избыточен.
2. При построении суррогатного PK (Primary Key - первичный ключ) на основание свойства поля IDENTITY вы получаете монотонно возврастающую (или убывающую) последовательность. Если при этом вы строите по этому полю кластерный индекс (это не всегда верно, но для некоторых таблиц - хорошее решение), то вы получаете минимум физических перестроений таблицы при ее изменений. Для индекса по UNIQUEIDENTIFIER это не верно.
С уважением, Алексей.

PaulWist
По подробнее пожалуйста, почему кластерный PK на IDENTITY в основном решение не правильное.
А я не сказал, что "в основном решение не правильное"!
Я сказал "это не всегда верно, но для некоторых таблиц - хорошее решение".
Если есть сомнения и в этом утверждении, то могу изложить свои соображение, подкрепленные примерами. Хотя, это скорее вопрос другой конференции (SQL Server), а там по выбору кластерного индекса (он один только, бедняга на всю таблицу) столько копий в свое время было поломано...

С уважением, Алексей

Sergej_STo Aleksey-K:
А так понял, Вы с SQL Server через pass-throuhg работаете?
ТОЛЬКО через pass-throuhg.
С уважением, Алексей

По поводу выбора в качестве кластерного индекса....
1. Все таблицы в любой моей базе данных (кроме случаев использование Merge Replication, который ТРЕБУЕТ наличие поля UNIQUEIDENTIFIER во всех реплицируемых таблицах) имеют суррогатный (т.е. искусственный и не связанный с атрибутами сущности, представленной данной таблицей) первичные ключ (PK) по полю Integer со свойством IDENTITY(1,1).
Для Constraint PK SQL Server ВСЕГДА создает сам индекс и по умолчанию делает его кластерным. Я раньше так все и оставлял, но теперь пересмотрел свое решение и, в зависимости от вида таблицы, поле для кластерного индекса выбираю след. образом.
1. Таблица - справочник, т.е. на ее PK есть ссылки в других таблицах через FK.
Кластерный индекс создаю на поле справочника по которому выполняется наиболее часто поиск - обычно это поле "видимого" (в отличии от "невидимого" для пользователя суррогатного поля) числового кода. По PK справочника создается некластерный индекс, т.к. при поиске ОДНОГО элемента справочника разница в скорости поиска по кластерному или по некластерному индексу правтически равна нулю.
2. Таблица фактов (документы, отчеты и пр.). Такие таблицы имеют ряд полей по которым очень часто необходимо произволить поиск на сервере (дата и № документа,..) и ряд ссылок на PK справочников на которые создаются FOREIGN KEY (FK - внешний ключ) . В этом случае по всем FK я обязательно создаю некластерный индекс. Кластервнй индекс создается по тому полю, по которому выполянется наиболее часто поиск имеено в диапазоне значений (WHERE ...BETWEEN ... AND ...). Для документов эти полем является дата документа. Вот по полю даты документа я и создаю кластерный ключ. По PK таких таблиц (также суррогатный INTEGER с IDENTITY (1,1)) создается некластерный индекс, т.е. как правило, его PK используется в командах удаления (DELETE ...) и обновления (UPDATE...) или JOIN-нах, т.е. при поиске ОДНОГО значения (PK однако). А в таком поиске кластерный индекс не дает существенного приемущества перед некластерным.
3. Часто меняющиеся таблицы, на которые имеются многичисленные ссылки из других таблиц. Хорошим примером такой таблицы явлется таблица складских остатков. В этом случае кластерный индекс создается по PK (INTEGER поле с IDENTITY (1,1)). Это связано с тем, что данная таблица (и подобные ей) интенсивно обновляется (добавляется, удаляется), а поиск в ней выполняется только по ее PK, который будет присутствовать во всех таблицах фактов, связанных с ней. А минимальные задержки и блокировки при удаление и обновлении этих таблиц с учетом большо кол-ва транзакций, обращающикся к ним, как раз и обеспечиваются свойством IDENTITY и невозможностью ОБНОВЛЕНИЯ PK.
С уважением, Алексей.

Для Crip.
12 байц на запись - это по вашему ерунда!?
Мда...
А вот давайте подсчитаем внимательно..
1. 12 байт на 2-3 миллиона записей (это я еще скромно указал для баз на основе SQL Server, уж поверьте моему опыту) ~ 36 миллионов байт на ОДНОМ тролько PK.
2. Считаем дальше. Пусть в таблице есть еще 10 (для ровного счета) некластерных индексов. Тогда получаем еще 360 миллионов дополнительных байт. (почему так могу объяснить или сами почитайте BOL).
3. Учтем, что данные храняться в страница по 8060 байт данных в каждой и строка таблицы НЕ МОЖЕТ БЫТЬ расщепленна на две РАЗНЫЕ страницы - думаю, что процентов 30 надо еще добавить к тем 400 миллионам байт.
4. Пусть таких таблиц у вас будет 10 штук - тоже не очень большая цифра.
Получается сколько ~ 5000 миллионов байт дополнитеоьно!

А теперь не забудьте, что для хорошей скорости работы SQL Server-а данные должны лежать в кэше, т.е. в оперативной памяти. Т.е. вы должны добавить 5Гбайт памяти серверу при переходи от INTEGER к UNIQUEIDENTIFIER для сохранения прижней скорости работы. Вот так.

Так что я бы на вашем месте так легко не относился бы к 12 байт на одну строку или забыл бы о разработке VLDB.
С уважением, Алексей

Crip
Это вообще в корне неверно. Почитайт внимательно форум по сиквелу.

Я эти форумы не читаю, я в них сам участвую.. :)
Обясните почему это в КОРНЕ НЕ ВЕРНО.
С уважением, Алексей.

Crip
Да не в корне. Я же говорю что слишком категорично получилось. Читайте пост выше.

Виноват, долго писал ответ и не увидел ваш пост... Исправлюсь и не буду отвечать сразу :)

Crip
Ну а касательно размеров. Все равно когда-нибудь БД превысит размеры оперативки. Лучше больше уделить внимания оптимизации запросов.

Двумя руками за, но...У меня оптимизация начинается с выбора структуры базы данных и, в том числе, выборе подходящих типов данных для столбцов. Скажу больше, в моей практике, эта фаза проектирования оказывала РЕШАЮЩЕЕ значение на производительность системы в целом.

Crip
Вообще выбор guid в качестве PK не одназначен, я лично не вижу серьезных ограничений по его использованию.

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

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

А разве мои прикидочные расчеты вас в этом не убедили!?
Если таблицы при хранении одного и того же объема ПОЛЕЗНОЙ информации имеет размер на ... мбайт меньше, это не аргумент?

Crip
А вот проблемы с IDENTITY периодически возникают.
Еще раз недостатки IDENTITY
1) Массовое добавление записей с возвратом ID

А в чем тут проблемма при использовании IDENTITY?

Crip
2) Работа с оторванными данными типа Web Services. Надо как-то возвращать кучу данных с новыми айдюками, что очень неприятно.

А при UNIQUEIDENTIFIER их возвращать не надо ? Или вы их на клиенте генерите?
Crip
3) Merge Replication.

Это тоже не аргумент.
Если вы внимательно изучали Merge Replacation в SQL Server 2000, то, должны знать, что UNIQUEIDENTIFIER (если не находит) Wizard добавляет в таблицы сам и использует эти поля НЕ ДЛЯ ИДЕНТИФИКАЦИИ строки, а для отслеживания ВО ВРЕМЕНИ изменений в строках реплицированных таблицах всех участников репликации. А IDENTITY вы при этом можете использовать, как использовали раньше. При чем Agent репликации может сам меняет ДИНАМИЧЕСКИ SCOPE IDENTITY (Seed и Increment) с целью получения на всех серверах - участниках репликации непересекающиеся множества значений полей IDENTITY.
С уважением, Алексей.