Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
 PRIMARY KEY если существует то не ADD а обновить  [new]
hlopotun
Member

Откуда:
Сообщений: 673
Всем доброго дня,

сегодня использую след процедуру для добавление PRIMARY KEY:
create or alter procedure SYSTEM_ADD_PKEY (
    TAB_NAME varchar(31),
    CONSTR_NAME varchar(100),
    KEY_LIST varchar(200))
as
begin
if (not exists(
    select 1 from rdb$relation_constraints rf
where rf.RDB$CONSTRAINT_NAME = :constr_name AND rf.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
        AND rf.RDB$RELATION_NAME = :tab_name))
then
    execute statement 'ALTER TABLE "'||:tab_name||'" ADD CONSTRAINT '||:constr_name||' PRIMARY KEY ('||:key_list||')';
end

но она требует предварительно удаления этого ключа.
Есть что то аналогигное UPDATE OR INSERT INTO но уже для ключей и индексов в FB2.5.8 и выше.

Спасибо.
12 ноя 21, 13:11    [22395029]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4926
hlopotun
Всем доброго дня,

сегодня использую след процедуру для добавление PRIMARY KEY:
create or alter procedure SYSTEM_ADD_PKEY (
    TAB_NAME varchar(31),
    CONSTR_NAME varchar(100),
    KEY_LIST varchar(200))
as
begin
if (not exists(
    select 1 from rdb$relation_constraints rf
where rf.RDB$CONSTRAINT_NAME = :constr_name AND rf.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
        AND rf.RDB$RELATION_NAME = :tab_name))
then
    execute statement 'ALTER TABLE "'||:tab_name||'" ADD CONSTRAINT '||:constr_name||' PRIMARY KEY ('||:key_list||')';
end


но она требует предварительно удаления этого ключа.
Есть что то аналогигное UPDATE OR INSERT INTO но уже для ключей и индексов в FB2.5.8 и выше.

Спасибо.
Да щас же.
12 ноя 21, 13:15    [22395032]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30245
hlopotun,

и зачем эта дичь, интересно.
1. зачем вот так вообще делать
2. зачем "обновлять" ПК, если он уже построен.

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

p.s. и ты обломишься, если на существующий ПК уже есть ФК.
12 ноя 21, 13:32    [22395048]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

kdv
и зачем эта дичь, интересно.

Ну ты же помнишь его старую песню: "25 лет говнокода в авгиевых конюшнях,
разгребать некогда, да и лень, надо быстро как-то отхакать".

Posted via ActualForum NNTP Server 1.5

12 ноя 21, 13:35    [22395050]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30245
hlopotun
Есть что то аналогичное

кроме того, что я сказал выше, DDL обычно это не просто "инсерт или апдейт одной системной таблицы", а изменение нескольких системных таблиц (ПК это не только констрейнт, но еще и индекс, плюс сегменты индекса, т.е. как минимум 3 таблицы), плюс еще дополнительные действия. И если ты мог заметить, триггеров на системных таблицах нет (и даже создать их нельзя).
12 ноя 21, 13:36    [22395052]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
hlopotun
Member

Откуда:
Сообщений: 673
kdv
hlopotun,

и зачем эта дичь, интересно.
1. зачем вот так вообще делать
2. зачем "обновлять" ПК, если он уже построен.

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

p.s. и ты обломишься, если на существующий ПК уже есть ФК.


с ФК понятно что они удаляются раньше, а с ПК вроде как нет необходимости они всегда стоят в обновлении после удаления ФК и после изменения структуры таблиты. И если поля входящие в ПК не меняются было бы удобно.
Тут используется концепт в котором обновление можно запускать многократно.
Это экономит кучу времени на этапе отладки обновления. Позволяет отлаживать изменения всего кода в одном файле обновления, если сильно разростается конечно можно и разделять. А если есть ошибки в порядке обновления процедур индексов итп то они вылазят сразу по мере их добавления в файл обновления. Еслть самописная библиотека с подобными функциями, на самом деле очень удобно и сокращает обьём кода при каждом обновлении. А также упрощает восприятие кода обновления и соотв уменьшает вероятность возникновения ошибок.
Если это не по чьим то канонам не пользуйтесь. Мы от этого концепта уже не откажемся. Это действительно удобно в чём была возможность убедиться на протяжении многих лет использования такого концепта.
п.с. прийдётся тогда просто немного дописать эту процедуру.
12 ноя 21, 14:02    [22395075]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

hlopotun
Еслть самописная библиотека с подобными функциями, на самом деле очень удобно и
сокращает обьём кода при каждом обновлении.

А у меня объём кода при каждом обновлении нулевой. И знаешь почему? Потому что
исходная версия базы известна и на неё можно просто накатить скрипт обновления,
не гадая что в базе есть, а чего нет. И если поля PK не меняются - его вообще
нет в скрипте. Отладка скрипта сводится к его прогону на базе и сравнении
результата с эталонной базой.

Posted via ActualForum NNTP Server 1.5

12 ноя 21, 14:08    [22395083]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30245
hlopotun
И если поля входящие в ПК не меняются было бы удобно.

а в чем смысл изменения ПК если столбцы не меняются? Поменять имя констрейнта?
Я понимаю, допустим, это "благообразный" рефакторинг какой-то древней базы. Но автоматизировать-то это зачем?
Вся эта "автоматизация бардака" ведь будет выкинута после окончания бардака.
Опять же, понимаю, когда автоматизируются рутинные действия. Но смысла в этих рутинных действиях я не улавливаю.
hlopotun
Это экономит кучу времени на этапе отладки обновления

хренасе, обновления... С модификацией ПК, ФК, и прочего.
hlopotun
разростается

разрАстается. Рост, но "расти".
12 ноя 21, 14:33    [22395113]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
hlopotun
Member

Откуда:
Сообщений: 673
Dimitry Sibiryakov

hlopotun
Еслть самописная библиотека с подобными функциями, на самом деле очень удобно и
сокращает обьём кода при каждом обновлении.

А у меня объём кода при каждом обновлении нулевой. И знаешь почему? Потому что
исходная версия базы известна и на неё можно просто накатить скрипт обновления,
не гадая что в базе есть, а чего нет. И если поля PK не меняются - его вообще
нет в скрипте. Отладка скрипта сводится к его прогону на базе и сравнении
результата с эталонной базой.


да, если скрипт обновления создаётся автоматически при сравнении баз тем же IBExpert.
А если куча разработчиков которым каждому на своей машине надо ежедневно накатывать этот скрипт, и у каждого своя конечная база и не факт что подходит под этот скрипт. Каждый так же вносит свои правки в структуру бызы под свои задачи итп.
У меня иногда возникает впечатление что я дискутирую с людьми с одной стороны грамотными и знающими тот же Firebird но которые работают или в одиночку или малой командой. Если Вас поместить в фирму где десятки разработчиков пилят тулз работающий с несколькими одними и теми же базами одновременно, у всех свои тикеты и всё это должно разрабатываться одновременно то ваша идеология тупо остановит сам процесс разработки. То что я тут обсуждаю худо бедно но работает в большой команде и уже много лет, и позволяет выкатывать более менее сносные релизы по 6 раз в год. И всё это реально работает и приносит реальные, весьма не маленькие деньги.
п.с. Ваша модель подходит только для случая когда сначала строится база а потом она обвязывается клиентом. В реальных больших проектах такое бывает редко. Тут многозадачность и параллельность в разработке. Совсем другой мир.
12 ноя 21, 18:23    [22395270]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 1119
hlopotun,

десятки разработчиков работают с одной базой и никакого контроля над ними? Так бывает? Хаос???
12 ноя 21, 18:39    [22395281]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

hlopotun
У меня иногда возникает впечатление что я дискутирую с людьми с одной стороны
грамотными и знающими тот же Firebird но которые работают или в одиночку или
малой командой.

Лайфхак: команда любого размера превращается в малую посредством разделения
обязанностей. А то, что описываешь ты, это хаотическая модель разработки.
Действительно, совсем другой мир.

Posted via ActualForum NNTP Server 1.5

12 ноя 21, 18:39    [22395282]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
hlopotun
Member

Откуда:
Сообщений: 673
Dimitry Sibiryakov

..............
Лайфхак: команда любого размера превращается в малую посредством разделения
обязанностей. А то, что описываешь ты, это хаотическая модель разработки.
Действительно, совсем другой мир.

да, в принципе к тому и двигаемся по мере роста количества персонала. Но на данном этапе на все темы по специализации народа хватает. Не по причине количества а по причине погружения в тему. Есть спецы которые поднимали определённые разделы и владеют темой глубоко, есть люди прищедшиее позднее или с других проектов. Есть спецы которые пилят Framework и владеют только технической стороной но не очень в бизнес процессах. Сейчас идут реорганизации, пробуем, эксперементируем как имеющимися силами справляться. Что то получается, что то не очень. Пробуются всякие методы типа Scrum, Agile итп но пока складывается впечатления что для них мы недостаточно большие. Безусловно есть кучи старого кода и старых фреймворков но потихоничку выпиливаем их. Пробуем частично смешивать группы разработки дабы при потере спеца всё не шло прахом итп. Явно назрела тема архитектуры и архитекторов. Но что бы подготовить архитектора для такого обьёма информации и кода нужны годы. Мне многое не нравится как написано, спланировано и организовано но человек в этой конторе я новый потому для начала надо в сам предмет погрузиться а потом пробовать что то кардинально менять. И как бы там ни было всё работает, релизы выходят, ошибки правятся и денюжку всё это приносит. Поэтому без резких телодвижений будем всё причёсывать стараясь не закладывать новые ошибки и подготавливая спецов. Тему архитекторов пока решаем на уровне проектов, возможно когда то дорастём до чего то большего. Хаотичной эту разработку я назвать не могу, всё делается по планам, с тестированием итп Да многое можно улучшить, что постепенно и делаем.
Как то так.
13 ноя 21, 16:15    [22395596]     Ответить | Цитировать Сообщить модератору
 Re: PRIMARY KEY если существует то не ADD а обновить  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

hlopotun
Пробуются всякие методы типа Scrum, Agile итп но пока складывается впечатления
что для них мы недостаточно большие.

Раз недостаточно большие - попробуйте объяснить каждому, кому хочется
что-то поменять в базе, что для этого надо:

1. Испытать скрипт на изменение на локальной базе;
2. Внести соответствующее изменение в мастер-скрипт создания базы с нуля;
3. Внести соответствующее изменение во все скрипты апгрейда базы со
старых версий до текущей;
4. Запустить скрипт на общей БД разработчиков;
5. Закоммитить эти изменения в СКВ.

И тогда никому никогда не придётся гадать есть у таблицы ПК или нет его. Когда
облажаетесь с объяснением - количество людей, допущенных к изменению БД
сократиться как бы само собой за счёт отъёма прав у тех, до кого не дошло.

Posted via ActualForum NNTP Server 1.5

13 ноя 21, 16:29    [22395600]     Ответить | Цитировать Сообщить модератору
Все форумы / Firebird, InterBase Ответить