Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.08.14;
Скачать: [xml.tar.bz2];

Вниз

Создание уникального идентификатора в Mssql   Найти похожие ветки 

 
k2 ©   (2005-07-06 07:29) [0]

Необходимо создавать для записей идентификатор, уникальный для нескольких таблиц. К сожалению uniqueidentifier применить нельзя, ограничена типом varchar(16). Пока вижу два решения:
1)создать вспомогательную таблицу аналог оракловых сиквенсов, в которую записывать последний созданный/свободный идентификатор
2)функцию, которая будет формировать идентификатор по текущей дате (например convert(char(30), getdate(), 121) и удаление всех разделительных символов).
Посоветуйте, может есть нормальный правильный выход, или если нет, то какое решение было бы предпочтительней и почему? граблей с уникальностью в обоих случаях похоже много :(


 
ЮЮ ©   (2005-07-06 07:54) [1]

>Необходимо создавать для записей идентификатор, уникальный для нескольких таблиц

Чем это обусловлено?

Ещё вариант: Таблица с единственным IDENTITY полем, а у тех нескольких таблиц - связь 1..1 с этой таблицей


 
ЮЮ ©   (2005-07-06 08:00) [2]

1..0, конечно.
Правда, если не обезопасить себя триггерами или подобными фенечками, это позволит иметь во всех таблицах записи с одним и тем же идентификатором :(


 
k2 ©   (2005-07-06 08:32) [3]

ЮЮ ©   (06.07.05 07:54) [1]
Спасибо

>Чем это обусловлено?
База данных оборудования, разделение на несколько таблиц: во-первых, по видам оборудования, во-вторых по набору признаков(1таблица:общиепризнаки для всех видов оборудования; 2:набор признаков конкретного вида оборудования; 3: данные испытаний)
Идентификатор(уникальный) при заполнении формировался сторонним приложением при создании соответствующего объекта на графической схеме. Теперь появилась необходимость дополнения данными, для которых нет объектов на схемах. Все хранимые процедуры по выборке и обновлению данных  параметром получают идентификатор, если он будет неуникальный, то при выборке различных видов оборудования мы можем получить всяческие неприятности (обойти можно введением дополнительных условий в ХП и вьюхи)


 
k2 ©   (2005-07-06 08:34) [4]

ЮЮ ©   (06.07.05 08:00) [2]
"я работы не боюсь..", просто и лишнего не хочется наворачивать во многих местах :(, если можно было бы сделать в одном месте правильно


 
Fay ©   (2005-07-06 08:36) [5]

2 k2 ©   (06.07.05 7:29)  
>> типом varchar(16).
именно varchar именно 16 ?


 
k2 ©   (2005-07-06 08:45) [6]

Fay ©   (06.07.05 08:36) [5]
да именно, структура таблиц вида 1(общие признаки для всех видов оборудования), создавалась сторонним приложением, и настройке не поддается, я думаю в принципе расширить можно было бы, но при возникновении вопросов обмениваемся частью базы, и разработчики могут расстроиться, что вмешались в структуру :) хотелось бы на самый крайний-прекрайний случай оставить эту возможность


 
Fay ©   (2005-07-06 08:50) [7]

declare @s varchar(33)
select @s = cast(cast(newid() as varbinary(33)) as varchar(33))

select @s, len(@s)


 
k2 ©   (2005-07-06 08:55) [8]

Fay ©   (06.07.05 08:50) [7]
спасибо :) а я вертела этот newid, и никак приспособить не доумилась


 
sniknik ©   (2005-07-06 08:55) [9]

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

если нужен сквозной номер на несколько таблиц, обычно его делают добавлением еще одной с автоинкрементом, а на все нужные таблици вешают тригер на добавление записи, в котором добавляют запись в дополнительной таблице и читают значение @@IDENTITY, это и будет нучное сквозное значение, его записываеш а из дополнительной записи стираеш (нафига пустые данные).

но в твоем случае и этого не надо... просто добавь к таблицам информационное поле (байт), можно вычисляемое (место не занимать) и в паре с автоинкрементом это и будет уникальное среди всех твоих таблиц значение. т.к. каждой ты его присвоиш разный, а использовать будеш как префикс идентификатора (1_1 /первая запись первой таблици... и тд. 2_125 сто двадцить пятая второй) для удобства и это значение можно вычисляемым полем представить и тогда вообше никаких заморочек с добавлением/тригерами, создать таблицы и читать из заданного поля строковые идентификаторы... а пользоваться (и назначить ключем) для связок и обновлений всетаки автоинкрементным полем.


 
ЮЮ ©   (2005-07-06 08:58) [10]

>Все хранимые процедуры по выборке и обновлению данных  параметром получают идентификатор,

Экономия на количестве процедур? Ведь все-равно корректируются разные таблицы, в зависимости от того, записью которой из них оказался "объект" с этим идентификатором, т.е. дополнительные условия в ХП и вьюхах<b/> уже присутствуют.

Что мешает использовать свои ХП и вьюхи? Ведь сторонне приложение не должно же видеть ваши новые объекты или, наоборот, должно?


 
k2 ©   (2005-07-06 09:43) [11]

sniknik ©   (06.07.05 08:55) [9]
спасибо, попробую тоже, а то newid преобразованный как-то нелицеприятно выглядит, боюсь не устроит заказчика, попросит што симпатишнее
> если первое... то это изврат, идентификатор (уникальный. ключ)
как раз первое, но не думаю што это такой уж большой изврат, приложение ориентировано больше на работу с графикой(это не реклама :)), операции с бд только массовое занесение данных(все остальные операции с данными на это время тормозятся), просмотр и редактирование по одной записи и усе

ЮЮ ©   (06.07.05 08:58) [10]
>Что мешает использовать свои ХП и вьюхи? Ведь сторонне приложение не должно же видеть ваши новые объекты или, наоборот, должно?
нет видеть не должно
хп и вьюхи наши все, экономию если чесно хотелось бы навести, ибо все это в разработке, и когда добавляется какое то новое условие приходиться тупо вколачивать всюду(несколько десятков уже :(, хп гораздо больше чем таблиц ибо в таблицы сведены группы оборудования)думаю методы обновления нужно пересмотреть, но прежде чем пытаться свести, подожду пока все хотелки вывалятся, ну или у меня знаний прибавится :)

всем спасибо за помощь


 
<Lelik>   (2005-07-06 10:02) [12]

>К2
наверно так красивее
select cast(newid() as varbinary(255))
или так
select cast(newid() as varchar(255))


 
Fay ©   (2005-07-06 10:10) [13]

Ага!
select len(cast(newid() as varchar(255)))


 
Anatoly Podgoretsky ©   (2005-07-06 10:35) [14]

Это зачем же использовать аж 255 байт, когда размер поля всего 16 байт - as varbinary(16)



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2005.08.14;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.49 MB
Время: 0.024 c
1-1122380177
Alexey_T-O
2005-07-26 16:16
2005.08.14
Курс $


3-1120734847
Ирина
2005-07-07 15:14
2005.08.14
ADOTable


14-1121749700
NeyroSpace
2005-07-19 09:08
2005.08.14
А если нефть и газ будут никому не нужны?


14-1121848754
|imp|
2005-07-20 12:39
2005.08.14
Факс на delphi


4-1118757036
Dr. Genius
2005-06-14 17:50
2005.08.14
Определение доступа к ресурсам компьютера





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский