![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
>> С опенсорсем риски тоже есть, они другие но их не меньше.
>>> Есть, но риска "мы взяли и убили проект и давай до свидания" как-то нет.
Да точно так же есть. Убили проект, самостоятельно вы его развивать не сможете а желающие разбежались. Все, приплыли.
Кстати, тот самый Firebird образовался когда Borland решил убить Interbase. В итоге есть бесплатный опенсорс Firebird и платный закрытый Interbase.
>> Да ладно? Борланд продали не от хорошей жизни.
У Борланда было херово с маркетингом.
Но то что Delphi был куплен другой компанией и продолжает развиваться - о чем-то говорит.
>> Нужна не дрочка, а соответствие реалиям. Использовать Delphi 7 в 2013 год это верх идиотизма.
Начинать длительный проект в 2013 году на Delphi7 - да, идиотизм. Хотя тоже могут быть ньюансы.
А вот переписывать код под каждый выходящий ежегодно Delphi - это что, не идиотизм?
>> А между тем мое приложение спокойно переехало с spring framework 3.0->3.1->3.2 и не кашляет.
>> И да особого времени и сил это не затребовало.
Ну, смена последней циферки может скрывать весьма небольшие изменения.
Моя программа мигрировала с Delphi (просто Delphi) на D2, D5, D7.
Каждая миграция была не просто так а вслед за полезными языковыми конструкиями которых не хватало в предыдущей. D1 вообще был 16-разрядным. Каждый переезд требует обновления всех используемых библиотек а они не все живут так долго. Обжогшись на этом перестал использовать либы без исходников т.к. с ними переход невозможен, приходится искать аналоги и переписывать. Так же стал стараться использовать стороннее по минимуму.
>> Гениально. Давайте подстраивать платформу выполнения под программу.
С вашей точки зрения программиста это выглядит дикостью, а с точки зрения бизнеса - это нормально.
Кроме того аналогичная ситуация вообще в компьютерном мире - вполне исправное и устраивающее железо может не заработать на новой платформе из-за отсутствия драйверов под эту платформу. Соответственно при смене ОС надо поменять еще и железо. Вопрос - нафига тогда менять ОС?
>> Это вы выдумываете. Используется последний зарелизенный Firebird 2.5.1.
>>> Это вот у вас единственный вменяемый компонент и используется у вас только в силу свой как раз таки opensource.
Миграция на новые версии Firebrird обусловлена тем что в нем вносится много полезных и нужных мне вещей.
Опенсорс тут особо не влияет. Он для меня все равно получается как бы платным, я являюсь членом Firebird Foundation и ежегодно плачу туда взносы. Они не велики но это мой вклад в развитие нужного мне продукта.
>> Мягко говоря все образчики кода которые вы показывали ни у кого восторга не вызывает, скорее даже наоборот.
Вызвать восторг - не является моей целью. Код должен быть простым и легко понятным, с привлечением минимимума лишних абстракций.
no subject
Да точно так же есть. Убили проект, самостоятельно вы его развивать не сможете а желающие разбежались. Все, приплыли.
Есть разница. В случае opensource вы имеете исходные коды и можете заниматься поддержкой сами. В случае закрытого продукта можете только рвать волосы на себе. Особенно весело если данные там лежат в своем закрытом формате.
Кстати, тот самый Firebird образовался когда Borland решил убить Interbase. В итоге есть бесплатный опенсорс Firebird и платный закрытый Interbase.
Как раз яркий пример почему использование не opensource плохо.
У Борланда было херово с маркетингом.
Но то что Delphi был куплен другой компанией и продолжает развиваться - о чем-то говорит.
Увы ни о чем это не говорит. Новых приложений на этой штуке я не видел ни одного. А вот на Qt видел.
Начинать длительный проект в 2013 году на Delphi7 - да, идиотизм. Хотя тоже могут быть ньюансы.
А вот переписывать код под каждый выходящий ежегодно Delphi - это что, не идиотизм?
Не переписывать, а портировать. И портировать надо если хочется чтобы программа не закончила свой жизненный цикл. На портирование с версии на версию как правило затрачивается меньше усилий. Но если этого не делать, а спохватится в 2013 году, то уже проще написать с нуля.
Ну, смена последней циферки может скрывать весьма небольшие изменения.
На момент старта разработки слава богу 2.5 уже можно было не использовать. Но и при его использовании я бы спокойно переехал на тройку.
Моя программа мигрировала с Delphi (просто Delphi) на D2, D5, D7.
Там какие-то значительные изменения были только с D2 на D5.
Каждая миграция была не просто так а вслед за полезными языковыми конструкиями которых не хватало в предыдущей. D1 вообще был 16-разрядным. Каждый переезд требует обновления всех используемых библиотек а они не все живут так долго. Обжогшись на этом перестал использовать либы без исходников т.к. с ними переход невозможен, приходится искать аналоги и переписывать. Так же стал стараться использовать стороннее по минимуму.
А потом дойдя до D7 стало незачем? Ну а библиотеки опять же яркий пример почему не стоит использовать закрытые решения. И да в Delphi с открытыми библиотеками и их качеством весьма грустная история. Это кстати еще одна из причин почему мы выкосили свое старое приложение на Delphi.
С вашей точки зрения программиста это выглядит дикостью, а с точки зрения бизнеса - это нормально.
С точки зрения бизнеса это тоже дикость. Так-как в один прекрасный момент все сложнее становится купить необходимую платформу. Это тоже самое что продолжать упорно использовать автомобиль прослуживший 10 лет, потому что у нас в кузов наш старый кран помещается.
Кроме того аналогичная ситуация вообще в компьютерном мире - вполне исправное и устраивающее железо может не заработать на новой платформе из-за отсутствия драйверов под эту платформу. Соответственно при смене ОС надо поменять еще и железо. Вопрос - нафига тогда менять ОС?
Компьютеры имеют такую особенность выходить из строя. И да сейчас уже все меньше компьютеров позволяет запускать Windows XP без бубна. А скоро этого сделать будет вообще нельзя.
Миграция на новые версии Firebrird обусловлена тем что в нем вносится много полезных и нужных мне вещей.
Опенсорс тут особо не влияет.
Влияет. Это дает возможность туда добавлять нужные вещи. В том числе и самому при должной квалификации.
Код должен быть простым и легко понятным, с привлечением минимимума лишних абстракций.
Увы сейчас ваш код таким не является. Он как минимум плохо структурирован.
no subject
no subject
no subject
з.ы. но был дико рад, когда наконец свалил от этого всего в java
no subject
Хотелось бы конечно нативного кода, но он идет в нагрузку с С++ :)
no subject
no subject
no subject
Именно так. Все что нужно имеется. Тотальный юникод в строках не нужен. Будет нужен - подумаю над этим вопросом.
>> Влияет. Это дает возможность туда добавлять нужные вещи. В том числе и самому при должной квалификации.
Я не питаю иллюзий по поводу своей квалификации и способности разобраться в объемном и сложном чужом коде. Компиляторы и СУБД намного сложнее чем междумордия для бизнеса. Поэтому мне без разницы опенсорс это или нет - я не собираюсь в одиночку тащить чужие глобальные проекты. Я лучше куплю готовый инструмент и буду им пользоваться.
>> Код должен быть простым и легко понятным, с привлечением минимимума лишних абстракций.
>>> Увы сейчас ваш код таким не является. Он как минимум плохо структурирован.
Мое больное место - сложность в удержании в памяти слоев абстракций и каскадные ссылки и переходы. Соответственно я пишу так что бы этот дефект не сказывался. Пока-что получается. Но по этой причине код с водопадами классов я читать не могу и соответственно не применяю.
no subject
no subject
no subject
Мое больное место - сложность в удержании в памяти слоев абстракций и каскадные ссылки и переходы. Соответственно я пишу так что бы этот дефект не сказывался. Пока-что получается. Но по этой причине код с водопадами классов я читать не могу и соответственно не применяю.
Извините но в таком случае не вам судить что ORM плохо. А то с вашей колокольни много чего плохо будет казаться. К примеру Haskell.
no subject
no subject
no subject
no subject