Гуе-визардо-мышедизайнерская разработка софта

[metaclass]

А вот скажите, как вы относитесь к инструментам, в которых для подключения, например, к БД, нужно пройти 5-10 экранов визарда? Ну или там поработать полчасика в неудобном мышедизайнере.
С одной стороны, для начинающих это сильно снижает порог входа - нажимаешь "сделать чо нибудь", оно задает кучу вопросов и это чо нибудь делает. С другой стороны - внутренности либ для подобных инструментов чуть более чем всегда совершенно не
пригодны для обычной разработки - "чтобы создать что-то из кода, надо выполнить страницу неадекватных вуду заклинаний".
Я подобные вещи стараюсь не использовать, благо, разработчики все делают для того, чтобы это было неудобно и медленно для сколько-нибудь сложных задач и подобное ретроградство и луддизм находят понимание среди коллег, особенно тех, кто ничем, кроме текста и его редакторов, принципиально не пользуется.

Comments

[jakobz.livejournal.com]

База существует в виде понятных ей одной бинарных файлов. Ну, и часто - в виде diff-скриптов в source control-е, которые если последовательно запустить - получится такая же база. Где ты там исходник видел?

[metaclass.livejournal.com]

У меня два разных исходника: для создания с нуля и для миграции между разными версиями.
В конечном итоге - diff-скрипты и есть исходник.

[jakobz.livejournal.com]

А как ты эти исходники синхронизируешь?

[metaclass.livejournal.com]

Я их разрабатываю параллельно, т.к. в общем случае состояние из миграций выводится хреново.
Особенно что касается живых данных в продакшене.

[jakobz.livejournal.com]

Ну, если допустить что в проде никто схему не меняет, то из миграций состояние выводится однозначно. По каким причинам у тебя прод и скрипты миграции разъезжаются?

[metaclass.livejournal.com]

Не разъезжаются.
Создавать таблицы в стиле "добавил 10 полей, удалил 5, добавил еще 20" меня огорчает, поэтому я для новых деплойментов создаю базу из финальных скриптов.
Я в голове не смогу удержать разработку, если таблица будет разбросана по нескольким файлам.

[theaspect.livejournal.com]

Ребе, а ты используешь какую-нибудь тулзу для накатывания и донакатывания миграций?

[metaclass.livejournal.com]

Самодельная софтина-обновлятор. Она все накатывает - базу, бинарники, итд.

[fraks-nsk.livejournal.com]

Что бы эти бинарные файлы создать требуется дать серверу команды.
Либо эти команды даются в текстовом виде скриптом и это и есть исходник
либо это делается через ГУЙ.

Если у какого-то сервера есть возможность создать объекты в базе только через гуй и мышку - это адов пиздец и втопку такой сервер.

Некоторые сервера даже бэкапы баз делают в текстовый вид.

[jakobz.livejournal.com]

Речь о том, что исходники базы обычно являются последовательностью SQL-команд, которые меняют схему от начала существования базы. Читать это чтобы понять текущую схему базы никто в здравом уме не будет.

Как минимум будут как-то выгружать из поднятой из исходников базы ее метаданные, и как-то их читать. Можно выгрузить SQL-скрипт, можно какой-нибудь еще текст красивый, можно картинку. Картинка для многих случаев очень удобна.

Никто не говорит про то, что картинку хранить в VCS и по ней поднимать базы. Нет, картинка - производная, артефакт получаемый из текстовых исходников.

[fraks-nsk.livejournal.com]

>> Речь о том, что исходники базы обычно являются последовательностью SQL-команд, которые меняют схему от
>> начала существования базы. Читать это чтобы понять текущую схему базы никто в здравом уме не будет.

Как по мне - скрипты для перевода базы из старого состояния в новое - это не есть исходник базы.
Исходник - это один скрипт прогнав который получаем базу требуемой структуры.
Другое дело что когда в базе есть какие-то данные (а это практически всегда) то исходника обычно не достаточно и требуются специально написанные скрипты по изменению базы с данными. Они тоже нужны и хранятся в CVS но исходником не являются, это уже типа инструмент.

[jakobz.livejournal.com]

Я считаю первоисточником именно последовательность изменений от нулевой версии. Их все равно нужно делать, они позволяют создать бд в последней версии, а также поднять бд любой предыдущей версии до последней. Не вижу смысла поддерживать еще отдельный скрипт, дублирующий информацию в diff-ах. Этот скрипт, кстати, можно сгенерировать со свежей базы, подняв ее diff-ами.

Речь идет только о схеме данных. Всякие хранимки и вьюшки - это тот же код, их надо хранить также как остальные исходники.

[berezovsky.livejournal.com]

Да, так удобно.
SQL-файлики хранятся в контроле версий и именуются YYYYMMDD_Description, в каждом - создание табличек, раздача полномочий, создание процедур и т.п.
В каждом последующем может быть добавление полей, изменение процедур и т.д.
При установке смотришь, какие скрипты ещё не наложены и запускаешь последовательно.
Тогда у каждого клиента будет версия базы, соответствующая определённой версии софтины.
Хуёво только, что у MS нету стандартного механизма для таких вещей, всё приходится руками делать, пихать в setup и прочая.
После выхода 2010 студии на форумах смеялись ещё. Мол, да, подключение к базе, схема - всё есть. А как на практике быть? Ни тебе развёртывания автоматического, ни диффов. Кто же в жизни из студии к продакшену подключается? В таком духе.

[jakobz.livejournal.com]

Да, это удобно, и это - единственный мне известный способ по-человечески засунуть базу в контроль версий и вообще жить с БД без бардака.

Действия все автоматизируются и сводятся к выполнению скриптика. Я делал такую тулзу, да и многие себе что-то такое приделывают.

Хранимки и прочие вьюхи я хранил в отдельных файликов - и история есть, и не надо через diff-скрипты проводить.

Стандартной такой штуки для MSSQL нет, и это печально, да. Впрочем, для других баз я тоже такого не видел.

Самый минималистичный вариант из тех что я видел - это тупо сишный препроцессор, который склеивает include-ами кучу скриптов.

[fraks-nsk.livejournal.com]

>> Не вижу смысла поддерживать еще отдельный скрипт, дублирующий информацию в diff-ах.
>> Этот скрипт, кстати, можно сгенерировать со свежей базы, подняв ее diff-ами.


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

Вообще говоря, я и скрипты-исходники делаю крайне редко, только когда они нужны именно в виде скрипта что бы сделать по нему diff и посмотреть разницу. А обычно я работаю с последней версией в виде копии рабочей базы, хожу в нее через IBExpert который показывает мне объекты базы в виде дерева и дает массу удобных плюшек. Однако, для внесения изменений в структуру базы я использую только SQL-текст в том же эксперте и не юзаю его множественных ГУЙ-оглупляторов которые подменяют исходник некими гуевыми примочками которые не всегда понятно как связаны с реальными SQL-командами.
Крайне редко я пользуюсь этими оглупляторами когда они делают то что мне понятно, но лишь для того что бы посмотреть какой SQL в результате генерится, и в дальнейшем обычно использую именно его.

Но к примеру если надо посмотреть DDL таблицы - то я смотрю ее именно на вкладке с ее SQL-текстом а не там где оно же представлено в более графическом виде, ибо мне так быстрее и понятнее.

Пробовал как-то сгенерить визуальную схему по своей базе, в IBExpert и такой инструмент встроен, но столкнулся именно с тем о чем говорит метакласс - даже зная структуру глядя на ее схему хрен поймешь что к чему ибо слишком много связей которые невозможно отобразить на схеме так что бы оно было читабельно.
Один раз сделал, распечатал на десятке листов, ибо на экране не видно толком, повесил на стенку.
При переезде в другую комнату уже вешать не стал, ибо устарела, а опять растаскивать связи и таблицы что бы было читабельно - ну его нах.

[jakobz.livejournal.com]

Зачастую к продакшн-базе у большинства разработчиков вообще нет доступа - во-первых страшно, во-вторых там данные, которые им видеть не положено.

Потом крайне желательно чтобы у каждого разработчика была своя отдельная база. Я видел когда это не так - там получается ад. В результате все сводится к тому, что все изменения в схеме удобнее распространять в виде diff-ов.

А дальше все работают кому как угодно - можно пересоздать базу с нуля, можно скопировать с какого-нибудь QA-ного инста, чтобы там какие-нибудь красивые данные были. Иногда бывает можно взять с прода через обфускатор, если он есть.

Главное - что никто ни в одну базу напрямую не гадит, всегда есть возможность довести любую базу до актуальной коду версии, и ничего нигде не разъезжается.

>Однако именно этот скрипт я называю исходником а не пачку переходных скриптов.
"Исходник" - это все-таки от "source", т.е. правильнее - "источник". Любой сгенерированный код - это не исходник, а артефакт, полученный из исходника. Таким образом "исходники" - это таки diff-ы.

[fraks-nsk.livejournal.com]

>> Таким образом "исходники" - это таки diff-ы.

Каждый остался при своем мнении по поводу терминологии и того что из нее следует.

Вы исходники программы тоже как комплект диффов воспринимаете или таки результирующий текст на момент времени?

:P

[berezovsky.livejournal.com]

Программа, в отличие от SQL и базы, пересобирается и обновлятся перезаписыванием.

[fraks-nsk.livejournal.com]

Кстати, про бинарный вид. Программы они тоже работают только в бинарном виде (условно, не будем вдаваться в различные варианты :) ) Тем не менее, исходником программы называют не этот бинарный вид а ее текст на котором она была написана, на каком-то из языков программирования, в текстовом виде.