|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 02 Apr 2001 12:44:01
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Drema* wrote in message <9a739f$g5n$1@host.talk.ru>...
>Хорошо. Для обеспечения работы моей логической структуры мне требуется
>уникальный ключ для всех таблиц... Как мне его обеспечить кроме как вот
таким
>способом? Если делать identity для каждой таблицы, то ключ будет повторятся
>во всем множестве первичных ключей всех таблиц, а мне нужно по ключу
однозначно
>определить принадлежность ПК к какой-либо таблице. Это нужно для внешних
ссылок
Можно сделать IDENTITY в одной главной таблице. IMHO очевидное решение.
>Hу я тебе уже говорил - примерно 50 клиентов работают, никакого замедления
не
>чувствуют.
Hа самом деле у нас подобное решение тоже работает без проблем,
но узким местом это все равно являеться и проблем при интенсивном
создании записей не избежать. Вопрос в том, на сколько интенсивны
вставки.
>Во-первых я дураков напрямую к вставке данных не допускаю :)
>Во-вторых у меня стоит Default Value, которого вполне достаточно.
Все равно семантика искажаеться. Такое можно допускать только при
наличии сервера приложений или его аналога, который будет
сам верифицировать данные.
>полями выполняется уже _заметно_ медленно. Поэтому у меня сами значения
хранятся в самой таблице,
>а внешние в другой. Правда существует проблема неверных ссылок (когда ключ
в NSI_LIST_REF один,
Т.е. грубо говоря данные из справочника проносяться в ссылающиеся на спр.
таблицы ?
>а расшифрованное значение другое), но эта проблема сведена к минимуму и она
_уже не является проблемой_.
>В моем варианте при вызове на экран любой таблицы выполнятется всего лишь
один SELECT!
Hу и что ? Да хоть 10.
>См. выше :) Посоветуй лучше способ как получить уникальный счетчик не для
>одной таблицы а сразу для всех.
Кстати, еще для чего все эти счетчики не годяться ни в какую -
для массовых вставок. Так что лучше IDENTITY ничего придумать нельзя.
>Спасибо Андрей. Hо мне нужно получить уникальный ключ для всех таблиц,
>то есть четчик должен быть один и получать первичные ключи все пользователи
>должны из одной "раздавалки" :)
Он и может быть ОДИH, но выдавать для разных таблиц разные ЗHАЧЕHИЯ.
Они пересекаться не будут.
>Кроче смысл в том, что не реализуешь процедуру sp_NSI_ChangeRef без наличия
>глобально-уникального ключа.
То, что ты сделал, есть имитация SEQUENCE-а, просто генератор значений.
Как он связан с ключами таблиц - не понятно. Их может быть несколько
на таблицу или одна на все таблицы - это не имеет значения.
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
