Последние записи

made in programmersforum 1

Интенсив по Python: Работа с API и фреймворками 24-26 ИЮНЯ 2022. Знаете Python, но хотите расширить свои навыки?
Slurm подготовили для вас особенный продукт! Оставить заявку по ссылке - https://slurm.club/3MeqNEk

Online-курс Java с оплатой после трудоустройства. Каждый выпускник получает предложение о работе
И зарплату на 30% выше ожидаемой, подробнее на сайте академии, ссылка - ttps://clck.ru/fCrQw

14th
Окт

Обновление таблицы от версии к версии. Как?

Posted by Chas under Заметки

Что вы делаете, если изменили структуру таблицы, добавили новую?

phomm
Ну, во-первых, проектировать надо так, чтобы не пришлось потом менять ни структуру ни количество таблиц, хотя добавление можно предусмотреть для добавления независимых фич.
Во-вторых, на этапе постановки задачи, при подозрениях на необходимость серьёзных перемен можно рассмотреть задействование ОРМ.

В-третьих, лично я для некоторых задач использую генераторы и построители. Как для SQL кода, так и для дельфи кода. С SQL-то понятно, написал скрипт обхода по всем таблицам, чтение полей, и генерации SQL кода в тексте для хранимых процедур (если что, речь об SQL SERVER, моей основной субд), часть процедур, ессно, пишется руками. Построение кода в дельфи — хитрее, во-первых надо задекларировать енум для всех таблиц (по одному значению на каждую) + один для общего кода, потом построить необходимый набор компонентов (датасурсы, адосторедпроцедуры, и ещё какие потребуются) циклом по описанному енуму. Связи между таблицами для всяких гридов делаются динамически, перестраиваются датасеты с привязками по автоподстраиваемым лукап-полям, с функциональностью определения нужных связей через те же енумы и имена-строки, для чего соблюдается политика именования всех причастных сущностей. Вся логика же заложена преимущественно в написанных руками хранимках, автогенерированные хранимки в основном для справочных таблиц, где единообразие.
Могу показать наработки в какой-то части, но персонально и кусками.

В-четвёртых, всё делается полностью руками. Так у меня на работе, в принципе, это не смертельно, полёт нормальный.

maLoy*508
1 вариант
Ведем разработку на копии базы, которая в продакшене. Сделали ТЗ запланированные на версию, потом находим различия по метаданным между двумя базами, формируем скрипт, и накатываем его на базу требующую обновления… и так от версии к версии…

2 вариант
«Разрабатывать базу данных скриптами», т.е. есть некая эталонная база, разработку ведем на копии данной базы, после изменения процедур и т.д. формируем скрипт различий, и так по каждой фиче… скрипты складываем, где нибудь в СКВ… в итоге имеем эталонную базу, которую можем собрать на любом стенде для тестов или для пользования…

p/s/ я считаю не стоит пытаться проектировать структуру которую не придется менять, лучше проектировать так, что бы потом было легко изменять… ибо никогда неизвестно чего захочет заказчик…

тема на форуме