Всем доброго дня,

сегодня использую след процедуру для добавление PRIMARY KEY:


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

Спасибо.

с ФК понятно что они удаляются раньше, а с ПК вроде как нет необходимости они всегда стоят в обновлении после удаления ФК и после изменения структуры таблиты. И если поля входящие в ПК не меняются было бы удобно.
Тут используется концепт в котором обновление можно запускать многократно.
Это экономит кучу времени на этапе отладки обновления. Позволяет отлаживать изменения всего кода в одном файле обновления, если сильно разростается конечно можно и разделять. А если есть ошибки в порядке обновления процедур индексов итп то они вылазят сразу по мере их добавления в файл обновления. Еслть самописная библиотека с подобными функциями, на самом деле очень удобно и сокращает обьём кода при каждом обновлении. А также упрощает восприятие кода обновления и соотв уменьшает вероятность возникновения ошибок.
Если это не по чьим то канонам не пользуйтесь. Мы от этого концепта уже не откажемся. Это действительно удобно в чём была возможность убедиться на протяжении многих лет использования такого концепта.
п.с. прийдётся тогда просто немного дописать эту процедуру.

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


да, если скрипт обновления создаётся автоматически при сравнении баз тем же IBExpert.
А если куча разработчиков которым каждому на своей машине надо ежедневно накатывать этот скрипт, и у каждого своя конечная база и не факт что подходит под этот скрипт. Каждый так же вносит свои правки в структуру бызы под свои задачи итп.
У меня иногда возникает впечатление что я дискутирую с людьми с одной стороны грамотными и знающими тот же Firebird но которые работают или в одиночку или малой командой. Если Вас поместить в фирму где десятки разработчиков пилят тулз работающий с несколькими одними и теми же базами одновременно, у всех свои тикеты и всё это должно разрабатываться одновременно то ваша идеология тупо остановит сам процесс разработки. То что я тут обсуждаю худо бедно но работает в большой команде и уже много лет, и позволяет выкатывать более менее сносные релизы по 6 раз в год. И всё это реально работает и приносит реальные, весьма не маленькие деньги.
п.с. Ваша модель подходит только для случая когда сначала строится база а потом она обвязывается клиентом. В реальных больших проектах такое бывает редко. Тут многозадачность и параллельность в разработке. Совсем другой мир.

да, в принципе к тому и двигаемся по мере роста количества персонала. Но на данном этапе на все темы по специализации народа хватает. Не по причине количества а по причине погружения в тему. Есть спецы которые поднимали определённые разделы и владеют темой глубоко, есть люди прищедшиее позднее или с других проектов. Есть спецы которые пилят Framework и владеют только технической стороной но не очень в бизнес процессах. Сейчас идут реорганизации, пробуем, эксперементируем как имеющимися силами справляться. Что то получается, что то не очень. Пробуются всякие методы типа Scrum, Agile итп но пока складывается впечатления что для них мы недостаточно большие. Безусловно есть кучи старого кода и старых фреймворков но потихоничку выпиливаем их. Пробуем частично смешивать группы разработки дабы при потере спеца всё не шло прахом итп. Явно назрела тема архитектуры и архитекторов. Но что бы подготовить архитектора для такого обьёма информации и кода нужны годы. Мне многое не нравится как написано, спланировано и организовано но человек в этой конторе я новый потому для начала надо в сам предмет погрузиться а потом пробовать что то кардинально менять. И как бы там ни было всё работает, релизы выходят, ошибки правятся и денюжку всё это приносит. Поэтому без резких телодвижений будем всё причёсывать стараясь не закладывать новые ошибки и подготавливая спецов. Тему архитекторов пока решаем на уровне проектов, возможно когда то дорастём до чего то большего. Хаотичной эту разработку я назвать не могу, всё делается по планам, с тестированием итп Да многое можно улучшить, что постепенно и делаем.
Как то так.