Size: a a a

2020 February 26

ГМ

Геннадий Малинин in Delphi & Lazarus
У нас была огромная база на Oracle и соответственно PL/SQL. Там реализовывалось не мало функционала дабы освободить клиентскую часть. Сложности возникали только тогда, когда разработчикам приходилось вносить измнения в один и тот же пакет функций. Но это решалос KDiff ом

А да, у нас была тестовая база и рабочая. Тестовая каждую неделю переписывалась с новой.
источник

Дt

Дмитрий texnix 🇨🇳 in Delphi & Lazarus
Дмитрий Плясунов
в своей бд-песочнице?
так как база обновляется скриптами. каждый разработчик может накатить свежую актуальную версию бд, и работать далее, у нас налажена обнова так, что обновляться можно хоть каждую секунду.
источник

AS

Alexey Shumkin in Delphi & Lazarus
Дмитрий Плясунов
в своей бд-песочнице?
да
потом SQL -> в код
SQL-код сливается -> в БД (свою)
источник

ДП

Дмитрий Плясунов in Delphi & Lazarus
Alexey Shumkin
да
потом SQL -> в код
SQL-код сливается -> в БД (свою)
вот тут непонял, он открывает инструмент разработки, там правит таблицы, вьюхи, процедуры
источник

ДП

Дмитрий Плясунов in Delphi & Lazarus
тестирует их как-то у себя - ну работают ли ваще
источник

ДП

Дмитрий Плясунов in Delphi & Lazarus
теперь он знает, что менял - создает руками? скрипт?
источник

SB

Sergey Bodrov in Delphi & Lazarus
Отсюда два простых правила:
- не использовать код в SQL (хранимые процедуры, триггеры, сиквенсы, и прочее). Только чистый SQL.
- учитывать версию схемы БД и автоматически при старте выполнять последовательность апгрейдов (изменение таблиц и колонок, модификация данных)
источник

ДП

Дмитрий Плясунов in Delphi & Lazarus
у нас бизнес-логика на ХП
источник

ДП

Дмитрий Плясунов in Delphi & Lazarus
убег плавать ) буду через 1,5 часа
источник

AS

Alexey Shumkin in Delphi & Lazarus
Дмитрий Плясунов
теперь он знает, что менял - создает руками? скрипт?
у себя я решил эту проблему выгрузкой в файлы (выше я кинул ссылку на месагу с описанием что делается ))
SQL -> код
источник

AS

Alexey Shumkin in Delphi & Lazarus
Sergey Bodrov
Отсюда два простых правила:
- не использовать код в SQL (хранимые процедуры, триггеры, сиквенсы, и прочее). Только чистый SQL.
- учитывать версию схемы БД и автоматически при старте выполнять последовательность апгрейдов (изменение таблиц и колонок, модификация данных)
у первого правила есть обратная - неприятная - сторона )
источник

SB

Sergey Bodrov in Delphi & Lazarus
Хранимые процедуры хороши, если база одна на всех, и у всех к ней прямой доступ.
источник

AS

Alexey Shumkin in Delphi & Lazarus
Sergey Bodrov
Хранимые процедуры хороши, если база одна на всех, и у всех к ней прямой доступ.
ну, т.е. универсального правила нет )
источник

SB

Sergey Bodrov in Delphi & Lazarus
Sergey Bodrov
Хранимые процедуры хороши, если база одна на всех, и у всех к ней прямой доступ.
Или для глубокой оптимизации при работе с большими объемами данных - ГИС, например.
источник

AS

Alexey Shumkin in Delphi & Lazarus
Sergey Bodrov
Или для глубокой оптимизации при работе с большими объемами данных - ГИС, например.
поднимали этот вопрос уже )
https://t.me/Delphi_Lazarus/45760
https://t.me/Delphi_Lazarus/45764
источник

SB

Sergey Bodrov in Delphi & Lazarus
Но в большинстве случаев БД это просто хранилище данных, где достаточно CRUD + SQL для отчётов.
источник

SB

Sergey Bodrov in Delphi & Lazarus
Я привел правила для большого количества серверов, когда баз много - разные автономные филиалы, например.
источник

AS

Alexey Shumkin in Delphi & Lazarus
Sergey Bodrov
Я привел правила для большого количества серверов, когда баз много - разные автономные филиалы, например.
но не уточнил для какого случая )))))
источник

SB

Sergey Bodrov in Delphi & Lazarus
Alexey Shumkin
но не уточнил для какого случая )))))
Согласен, неловко получилось.
источник

Дt

Дмитрий texnix 🇨🇳 in Delphi & Lazarus
Sergey Bodrov
Но в большинстве случаев БД это просто хранилище данных, где достаточно CRUD + SQL для отчётов.
для большинства, ха. Когда БД простая. то и продвинутые программисты не нужны. Пиши себе отчётики и всё
источник