|
|
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Я всегда делал один генератор на одну таблицу. а в новом проекте решил сделать один генератор на все таблицы. какие из этого плюсы, я сам вижу. А какие минусы? ну кроме ограничение на количество уникальных строк в 4 миллиарда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 05:42 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
А какие в этом плюсы, если не секрет? Ну кроме экономии времени на создание генераторов, если их много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 07:52 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Секрет :-) но лично для тебя, о таинственный Guest-2 я открою один из многих айдишники у разных таблиц в одном порядке идут. таким образом одна таблица может принадлежать нескольким другим при помощи одной ссылки. остальные преимущества проектно-зависимы, но недостатков раз нет, значит я на верном пути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 07:58 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Кроме того, что множество ID не пересекается в разных таблицах, добавлю некоторые другие плюсы общего генератора: - порядок первичных ключей в рабочих таблицах становится несколько "разреженее", что может быть удобным при ручной вставке записей минуя клиентскую программу. Конечно это не есть хорошо, но кто же этим не занимался? - с точки зрения программиста проще и быстрее организовать доступ из программы к одному генератору, чем к нескольким. Часто бывает необходимо вытаскивать значение ID явным образом, а не доверившись Fib-ам или триггеру, и тогда единственная функция + единственный Query без использования подстановок - путь наименьшего сопротивления. - в конце концов: один объект - одна проблема. Зачем плодить несколько генераторов? Хотелось бы услышать противоположное мнение. Кроме отго, слышал, что их можно использовать не по прямому назначению: как средство отслеживания продолжительности выполнения ХП или что-то подобное. Может обсудим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 08:39 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Кроме того, что множество ID не пересекается в разных таблицах, добавлю некоторые другие плюсы общего генератора: - порядок первичных ключей в рабочих таблицах становится несколько "разреженее", что может быть удобным при ручной вставке записей минуя клиентскую программу. Конечно это не есть хорошо, но кто же этим не занимался? - с точки зрения программиста проще и быстрее организовать доступ из программы к одному генератору, чем к нескольким. Часто бывает необходимо вытаскивать значение ID явным образом, а не доверившись Fib-ам или триггеру, и тогда единственная функция + единственный Query без использования подстановок - путь наименьшего сопротивления. - в конце концов: один объект - одна проблема. Зачем плодить несколько генераторов? Хотелось бы услышать противоположное мнение. Кроме того, слышал, что их можно использовать не по прямому назначению: как средство отслеживания продолжительности выполнения ХП или что-то подобное. Может обсудим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 08:39 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
alex_k Слишком мало вы открыли секретов о мудрейший alex_k чтобы однозначно ответить на ваш вопрос. :) arni Как заметил alex_k, все эти "преимущества" проектно-зависимы. Вопрос для чего создается генератор. Если, скажем, для справочника, то о каких преимуществах может идти речь? Ну присвоился какому-нибудь объекту какой-нибудь ID, ну и какая разница как он присвоился - одним общим генератором на всех или специально сосзданным для данной таблицы-справочника? Главное чтобы этот ID был уникален для данной таблицы и в данном случае должно быть абсолютно фиолетово есть ли где-нибудь в другой таблице такой же ID . А насчет разреженности /уникальности - вы сами себе противоречете - если использовать общий генератор и затем вручную вставить/подправить ID, то где гарантия, что такой ID уже не существует в другой таблице (особенно если этих таблиц много) Опять таки в зависимости от задачи, может произойти ситуация, когда надо сделать какой-нибудь "сброс" ID в одной из таблиц, сохранив значения в других, при этом ID должен опять генерироваться с начала. Если честно, то в общем случае я не вижу особых преимуществ ни в создании одного навсех, ни в создании для каждой таблицы отдельного генератора. Ну и плодить генераторы - по моему это не такой уж трудоемкий процесс :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 09:22 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Для того чтобы использовать только один Query для генерации ID на все таблицы, как предлагает Arni, я создаю хранимую процедуру примерно следующего содержания: CREATE PROCEDURE SP_GET_NEXT_ID ( TABLE_NAME VARCHAR(31) ) RETURNS ( ID INTEGER ) AS begin if(:TABLE_NAME = 'TABLE_1') THEN ID = gen_id(GN_TABLE_1, 1); else if(:TABLE_NAME = 'TABLE_2') THEN ID = gen_id(GN_TABLE_2, 1); ... else if(:TABLE_NAME = 'TABLE_n') THEN ID = gen_id(GN_TABLE_n, 1); SUSPEND; end Тогда единственный Query на все генераторы у меня выглядит так: SELECT ID FROM SP_GET_NEXT_ID(:TABLE_NAME) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 09:53 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Zmeishe Мой встречный вопрос alex_k был: А какие плюсы, кроме экономии времени на создание генераторов? :) Честно говоря мне не очень нравится ваш метод - делать селект ХП (затем инсерт?) , перечисляя при этом n-ое количество таблиц. Например для тех же справочников обычно используют тригеры :) Да и update/insert-ом можно обойтись. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 10:27 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Guest-2 arni привёл следующий довод: - с точки зрения программиста проще и быстрее организовать доступ из программы к одному генератору, чем к нескольким. Часто бывает необходимо вытаскивать значение ID явным образом, а не доверившись Fib-ам или триггеру, и тогда единственная функция + единственный Query без использования подстановок - путь наименьшего сопротивления. Я предложил вариант с процедурой (генераторов несколько - Query один). Ничего не имею против триггеров, но сам сталкивался с необходимостью получить на стороне клиента значение ID до того как запись будет физически занесена в таблицу БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 13:59 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
во-во... зачем плодить сущности? одно дело общий генератор и другое дело куча генераторов и ХП... есть разница? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 15:10 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
alex_k << во-во... зачем плодить сущности? Есть задачи, в которых необходимо несколько генераторов. Например для одной таблицы два генератора. Один изменяется от нуля с шагом плюс(+) 1 Другой изменяется от нуля с шагом минус(-) 1 В противном случае пришлось бы создавать две таблицы или дополнительное поле в этой же таблице. А так получается две "в одном флаконе" т.к. структура информации оказалась одинаковой, только физический смысл разный. Работает очень шустро уже 4 года. Думаю нет смысла дискутировать о целесообразности или её отсутствии. Надо смотреть конкретную задачу. И не только с позиции голой теории, но и чистой ПРАКТИКИ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 15:31 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
>Один изменяется от нуля с шагом плюс(+) 1 >Другой изменяется от нуля с шагом минус(-) 1 А что, прикольное решение :-) не знаю зачем но выглядит оригинально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 16:48 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Если пользователь видит этот номер в справочнике/документе то, ИМХО, нужно делать несколько генераторов, иначе будет вызывать недоумение последовательность 1, 100, 1000 в одном справочнике. В противном случае, ИМХО, это дело программиста... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 16:59 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
alex_k > во-во... зачем плодить сущности? Ой подумаешь, создали генератор, прям сразу сущностью его обзывать, тоже мне сущность нашли > одно дело общий генератор и другое дело куча генераторов и ХП... > есть разница? В общем случае - практически никакой :) Хоть куча, хоть один , использование примерно одинаковое - gen_id(gen_name,gen_inc) Единственный, весьма сомнительный плюс - время, сэкономленное на создание генераторов. С другой сторооны, во многих случаях структура базы будет более понятной (на мой взгляд), если для каждой таблицы создавать свой генератор: create generator client_id_gen; create generator servcie_code_gen; По крайней мере назначение данных генераторов более или мене понятно, в отличии от скажем create generator one_generator_for_all; Ну и побочные эффекты там всякие, связанные с изменением значения генератора, скажутся на одной таблице, а так сразу на нескольких Zmeishe >> Думаю нет смысла дискутировать о целесообразности или её отсутствии. >> Надо смотреть конкретную задачу. И не только с позиции голой теории, но и чистой >> ПРАКТИКИ. Вот! Совершенно верно. И не зная задачи , трудно вообще говорить о каких-то плюсах или минусах, так что, alex_k - давай колись и расскрывай все секреты - вот тут то мы тебе со Zmeishe-м враз все недостатки и укажем ;))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 17:05 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
не укажите :-) были бы недостатки, уже бы указали... конечно, я могу накосячить, а потом выдать свой косяк за недостаток метода, ну дак это совсем другая фишка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 17:30 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
alex_k Слушай, напоследок, поделись еще одним секретом: > айдишники у разных таблиц в одном порядке идут. таким образом одна таблица может > принадлежать нескольким другим при помощи одной ссылки. Че сия фраза означает и причем тут один или несколько генераторов? А то я конечно умен, но в меру, да и товарища по армейке вчера встретил со всеми вытекающими последствиями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 18:07 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Ну, это я ненаучно конечно выразился. короче, есть у меня таблица людей. а эти люди могут принадлежать таблице клиентам а могут отделу кадров. или есть таблица контактов(ну там мыло, телефон, тырым-пырым). а эта таблица принадлежит клиентам или людям(которые работают или на нас или на клиентов). вот такие фишечки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 18:15 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
alex_k Ну теперь более или менее понятно. :) Ну успехов тебе, сам наверное все плюсы и минусы обнаружишь в ходе работы. Best ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2003, 18:25 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Интернет у меня редкость, поэтому отвечу сейчас, когда поезд уже ушел. to Guest2: >Если, скажем, для справочника, то о каких преимуществах может идти речь? Ну присвоился какому-нибудь объекту какой-нибудь ID, ну и какая разница как он присвоился - одним общим генератором на всех или специально созданным для данной таблицы-справочника? Главное чтобы этот ID был уникален для данной таблицы и в данном случае должно быть абсолютно фиолетово есть ли где-нибудь в другой таблице такой же ID. Раз разницы нет, то ставим плюс модели с одним генератором. to Zmeishe: под одним Query на выборку ID для всех таблиц я понимал примерно следующее: Query.SQL.TEXT:='select GEN_ID(MY_GEN, 1) ID from rdb$database' функция, возвращающая кому надо (любой табцице) ID, если это необходимо сделать не в триггере, а явно: function GetID:integer; begin Query.Open; GetID:=QueryID.AsInteger; Query.Close end; т.е. городить здесь ХП и подстановку имени таблицы ни к чему. Все просто и универсально. Наконец, может все таки поговорим о "нетрадиционном" использовании генераторов. Ведь не только ID из них таскают. Поделитесь опытом, други ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 08:54 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
arni > Раз разницы нет, то ставим плюс модели с одним генератором. Ну классный аргумент! Но у меня тоже кое-что в запасе есть! Раз разницы нет, то ставим плюс на модели со многими генераторами Если действительно хотите что-то обсуждать, то давайте обсуждать, а не разводить детский сад (флейм). Не могли бы вы более конкретно сказать, в чем вы видите преимущество, кроме как , опять повторюсь, некоторой экономии времени? Насчет получения/изменеия значений генераторов. Как уже было сказано выше - ВСЕ ЗАВИСИТ ОТ ЗАДАЧИ. И все не так просто. Ну получили вы значение генератора. А если вам нужно узнать в какую таблицу это значение было засунуто? Придется делать выборку из всех таблиц и смотреть максимальное значение, а так все ясно - генератор такой то, значит таблица такая-то. У alex_k имеется некая связь между таблицами, в этом случае возможно есть какие-нибудь преимущества (хотя сомневаюсь), ну а если таблицы независимы между собой, но как то взаимодействуют с другими? Изменили вы генератор (через set generator, а не gen_id) , а как оно скажется на зависимостях между другими таблицами при в ставке новых значений? А универсальность в данном случае - она несколько во вред читабельности, как мне кажется. > Наконец, может все таки поговорим о "нетрадиционном" использовании генераторов. Ведь не > только ID из них таскают. Поделитесь опытом, други ! Я использовал генераторы только для генерации ID :) Моя точка зрения - в общем случае разницы нет . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 11:40 |
|
||
|
один генератор на все таблицы
|
|||
|---|---|---|---|
|
#18+
Guest-2 >>А если вам нужно узнать в какую таблицу это значение было засунуто? >>Придется делать выборку из всех таблиц и смотреть максимальное >>значение, а так все ясно - генератор такой то, значит таблица такая-то. ... >> универсальность в данном случае - она несколько во вред читабельности Серьёзный аргумент! Если после Вас другой программист будет сопровождать эту БД, и читать структуру будет неудобно ОН ЖЕ УМОМ ТРОНЕТСЯ. Я сейчас перекраиваю (практически создаю с нуля) БД, которую до меня 7(семь!!!) человек делали. Так БЕЗ ПОЛЛИТРЫ НЕ РАЗБЕРЁШЬ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.07.2003, 15:03 |
|
||
|
|

start [/forum/topic.php?fid=40&fpage=512&tid=1580243]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
67ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
33ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 374ms |

| 0 / 0 |
