LINUX.ORG.RU

Как размещать код SQL в проекте?

 , ,


0

1

Есть проект десктопного приложения, который я сейчас активно рефакторю. Там и в коде бардак и в структуре каталогов. Положил я всё это в git, коммичу:

loader/ui: center OK button
loader/model: refactor SomeClass code
...

При этом:

  • файлики, меняемые коммитом «loader/ui», в каталоге проекта лежат тоже в loader/ui;
  • от коммита к коммиту проект должен собираться и работать;
  • коммит не должен изменять более одной области проекта.

Всё шло неплохо, а теперь мне надо убрать лишние поля из одной из таблиц. Ступил я в ранее нетронутый подкаталог sql и увидел там, что вся база loader лежит в одном большом файле.

Первое, что хочу сделать – распилить один файл на мелкие, по одному на каждую таблицу/вьюху/процедуру.

А дальше вопрос – куда их класть? Например, есть класс FooStorage с методом GetFoos, который дёргает хранимую функцию fnGetFoos. Получается, что код fnGetFoos – это как бы часть класса FooStorage, и лежать бы ей рядом с исходником FooStorage. Но я нигде не видел, чтобы SQL исходники хранили вместе с другими, видел только раздельное хранение.

Если я большой SQL распилю, а его части переносить не буду, тогда я буду вынужден нарушать свои же правила по ведению истории git:

  • изменю скрипт таблицы и закоммичу – поломаю код;
  • изменю и скрипт и код класса одновременно – коммит изменит больше одной области;
  • изменю и скрипт и код класса одновременно, и напишу в коммите loader/model – вроде бы всё верно, но один из изменённых файлов не лежит в подкаталоге, указанном в коммите.

Мозги плавятся, перфекционист внутри грызёт углы и воет: хочется сделать правильно и красиво. Возможно, я наркоман.

А как у вас хранятся SQL в проектах? Или может болт забить на аккуратную историю в git и просто фигачить? Проект веду я один, в принципе git могу вести как угодно, но хочется потомкам оставить хорошо структурированную историю.

★★

поржал немного, но понимаю ТС, хотЯ это в прошлом, ты просто начни что-то делать, братишка и поймешь что sql в одном файле это действительность а не «перфекционист воет», на работу устройся, девушку заведи, пивка выпей,ююю

anonymous ()

В чём проблема держать в одном файле? И что подразумевается под SQL, схема для создания базы, запросы к ней или апдейты схемы?

Harald ★★★★★ ()
Ответ на: комментарий от MyTrooName

в отдельной ветке разбей аккуратно по коммитам
потом всю ветку одним коммитом мержи в мастер

А внутри этой отдельной ветки код может быть временно поломанный, верно? Лишь бы в точке мёрджа собирался и работал как надо.

uuwaan ★★ ()
Ответ на: комментарий от Harald

В чём проблема держать в одном файле?

Хм. Сходу не скажу, просто не нравится. Наверное, можно и не распиливать.

И что подразумевается под SQL, схема для создания базы, запросы к ней или апдейты схемы?

Всё в куче там. Типа, запустил на пустом сервере, и скрипт тебе базу сделал. Никакой миграции между версиями базы нет, её структуру не меняли никогда.

uuwaan ★★ ()
Ответ на: комментарий от uuwaan

внутри ветки делай все, что заблагорассудится. хоть debug output в форме println. потом всё почистишь

потом всю ветку одним коммитом мержи в мастер

или несколькими

MyTrooName ★★★★★ ()

Большой файл разбивай на мелкие(таблицы, представления). Пусть каждый файл будет содержать свой DDL. А скрипт будет все это собирать в нужном порядке.

Нужно ещё подумать, куда класть DML скрипты, чтобы можно было структуру БД и основные справочники восстановить из DDL + DML. Это полезно, например, для тестирования.

Если у тебя есть ХП, udf в проекте, то создай каталог sql и код клади туда. Хотя можно в тот же каталог с DDL. В каждом коммите по master будет отображаться, что ты менял в каталоге. Ничего страшного, что коммит содержит файлы из разных областей. В производственную среду коммиты так и делаются.

Также могут быть скрипты DML, их лучше делать отдельными файлами, но связать их для последовательного выполнения (в один или несколько скриптов), как и файлы с DDL.

sania ()
Ответ на: комментарий от sania

а маленькие файлы разбивай на строчки. и пусть будет скрипт на node.js, который это будет собирать маленькие файлы, а потом скриптом на python это будет собираться в большой файл.

что за бред? нахрена инициализацию структуры базы раскидывать по файлам?

понимаю, когда потом идут инкрементальные изменения. Но это не кейс автора. И в совете вообще ничего нет про то, как организовать, собственно, повторяемое выполнение инкрементальных скриптов, особенно с учётом бранчей и мержей.

Давайте все будем делать всё самым сложным способом, в стиле The Incredible Machines.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 2)
Ответ на: комментарий от dzidzitop

А как у вас хранятся SQL в проектах?

Вопрос был «а как у вас». Только sql кода два миллиона строк. Представь этот один файл ?

Дальше ТС может и сам сопоставить варианты, у кого как, задать вопросы, произвести анализ и принять решение.

инициализацию структуры базы раскидывать по файлам?

Действительно, зачем? Потом ведь никто код админить и уж тем более читать не будет, и изменений никогда не предвидится.

sania ()
Ответ на: комментарий от sania

DDL на 2 миллиона строк не бывает.

Вероятно, там ещё наполнение базы. А если так, то возникает вопрос - зачем смешивать структуру базы и её наполнение в одном файле? Ответ очевиден - нет никакой причины это делать. И есть причины это не делать.

А вот зачем определение структуры базы изначально раскидывать по файлам - ещё один вопрос.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

DDL на 2 миллиона строк не бывает.

Бывает. Если ты чего-то не знаешь, это не значит, что это не так.

А вот зачем определение структуры базы изначально раскидывать по файлам

Еще раз. Большой объём кода. Например тебе нужно узнать, что значит поле в какой-то из таблиц или просмотреть код одной из ХП. И опять - кто-то кроме тебя будет читать код.

sania ()
Ответ на: комментарий от uuwaan

Зачем держать схему в разных файлах? Запросы у меня в моделях прям строками прописаны. Придерживайся MVC, а на sql забей, это не логика, это всего лишь помощник.

Deleted ()
Ответ на: комментарий от uuwaan

Тред не читал, но если ты создаёшь себе бранч для выполнения задачи, то пока он не смерджен с мастером, твоё личное дело что в этом бранче происходит.

Единственный момент: одна задача - один бранч.

SaBo ★★ ()
Ответ на: комментарий от sania

2 миллиона строк DDL - это не меньше десятков тысяч таблиц или вся система написана на stored procedures. Если такие системы существуют - то хотелось бы узнать в какой предметной области.

Stored procedures выносить в файлы можно. Таблицы и индексы - нет практического смысла.

dzidzitop ★★ ()

Вот это называется аннонирование на git как на таковой, а не занятие делом. Это все равно что говорить, что я не буду писать код, потому что он не влезает в строку (заранее ограниченная количеством строк), а переносить с разделителем не по моим правилам.

anonymous ()
Ответ на: комментарий от dzidzitop

Если такие системы существуют - то хотелось бы узнать в какой предметной области.

Тут не от области зависит, а от размера компании.

Возвращаясь К примеру с 2млн строк, есть хранилище данных, в которое сливаются данные с большого количества систем. Вот в нем 1.66 млн строк. Это скрипты таблиц, ХП отчётов.

Есть стороннее приложение, фронт для всех сотрудников, 4.4млн строк сиквела. Там вся логика в хп. Триггеры в основном по несколько тысяч строк.

Всего строк в директории sql - 10 млн.

sania ()