Наболевшее об исходном коде объектов БДИсточник: habrahabrru/post/142255/ Грамин Максим
Представьте такую ситуацию: команда разработчиков работает над программой. При этом исходный код приложения нигде не хранится. Каждый программист с помощью специального декомпилятора выгружает нужный код из бинарника, работает с ним, а потом вновь собирает и отдает на дальнейшую разаработку коллегам. Но почему-то такой подход довольно часто применяется при разработке приложений БД. Объекты создаются и изменяются "наживую" прямо в БД. Большинство специализированных IDE предоставляют массу "удобных" инструментов для этого - поиск нужного объекта с помощью навигационного дерева, его модификация несколькими щелчками мыши и т.д. При этом об исходном коде мало кто задумывается - а при сборке версии часто используются утилиты, которые на основании кода текущей базы и кода базы продакшена генерируют диф-скрипт (для меня до сих остается загадкой как, т.к. альтер (таблицы например) можно сформировать множеством способов, все зависит от конкретного случая, от логики изменения и т.д.). Получается, что исходного кода базы как бы и не существует, он считается неким машинным кодом, который трудно воспринимается человеком и полностью отдается на откуп визуальным средствам разаработки. Программист работает не с функционалом своей СУБД, а с функционалом конкретной IDE, неким красивым и (как кажется первое время) удобным промежуточным слоем. При этом приходится изучать именно IDE, а не саму СУБД. Стоит помнить, что после того, как вы с помощью собственно написанного кода (выверенного, отформатированного по корпаративным стандартам, оформленного комментариями) создаете объект БД, этот код нигде не сохранится, вы потеряете его, а взамен получите то, что соберет за вас машина (IDE, специальные утилиты или библиотеки), опираясь на словарь данных БД. При этом теряется история изменения объектов (становится невозможным узнать/вспомнить кто, когда и зачем создавал/удалял/изменял тот или иной объект), могут возникать конфликты при совместной разработке и еще очень много чего. Об этом можно почитать в "PLSQL Standards Developed for the PLSQL Starter Framework" в главе "Source Code Control": Remember to never modify the PL/SQL stored in the database. Work from the source code file instead. Yes, modifying the compiled code inside the database is technically feasible, but a really bad idea. It is comparable in some ways to modifying Java bytecode or C object files. и в главе "Data Models and DDL": Most DDL is still created by hand. Make it clean, commented and readable, just like source code. Напоследок приведу код создания простой таблицы в Oracle и то, что из него получается после выгрузки из БД различными утилитами. Исходный код создания таблицы: -- This is test_table DBMS_METADATA: Tora: TOAD Eclpise plugin: Как видно солянка полная, кто на что горазд. Конечно это не значит, что нужно полностью отказаться от современных визуальных средств и работать в консольном редакторе. Самое главное - работать именно с исходным кодом вашего приложения БД, контролировать его самостоятельно, не отдавать на откуп машине. Исходный код приложений БД ничем не хуже кода Java или C++ приложений и требует к себе такого же обращения: форматирование, комментарии, контроль версий и т.д. Несколько рекомендаций: 1. Весь код БД (DML, DDL, DCL, TCL и т.д.) необходимо хранить в репозитории (один объект = один файл); |