metaclass | В Советской Белоруссии SQL разжигает айседа

В Советской Белоруссии SQL разжигает айседа

http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.

Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).

Threaded | Top-Level Comments Only

Объясните мне еще про транзакции, я про них первый раз слышу.

Поделитесь, как ви на поцгресе запросы обычно хинтами перепиливаете?

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

Какой месяц на explain, каких данных мало?
Количество данных очевидно на этапе постановки требований, а кривые планы видны на первом же запуске на забитой тестовыми данными базе, если оптимизатору крышу сорвало.

Далеко не всегда :) Иногда есть проблема вида надо вчера. Плюс изначально при постановке предполагался меньший поток данных, а фактически получили больший. Плюс можно поймать баг explain использует не тот индекс. Я такое на PostgreSQL ловил. Лечилось отстрелом индекса как это не парадоксально.

Конкретно к планам и количеству данных ORM никакого отношения не имеет, если не делать херни вида "забрали все 100500 объектов на клиента, там обработали и положили обратно".

Конкретно надо по месту смотреть что там будет. И старательно бить канделябром за забрали 100500 объектов.

Ну что вы. Нужно выделять N бит внутри PK, чтобы каждый клиент создавал ключи в своём адресном пространстве.
;-)

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

Как раз чтобы она была понятной для поддержки развития у нее должна быть внятная архитектура и понятный код.

Архитектура должна позволять вносить изменения не скатываясь при этом до набора костылей.

Учитывая какой вы показывали код для формы у вас программ как раз набор костылей. Ну не пишут так уже давно. Это приводит к хреновой читаемости кода и размазыванию логики по всей программе ровным слоем.

Теряюсь в догадках...
А что же такое тогда поцгрес от баз данных? А DB2? MsSQL?

Вы как-то странно делаете вывод о моей скорости из описания процесса.

Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%

ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.

Что такое "разработчик насладится игранием в explain и его адаптацией к конкретной ситуации" - я не понял.
В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,
кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.
Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.

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

Из того что я потрачу на 5 минут меньше на кодинг не изменится ровным счетом ничего.

После быстрого старта бывают проблемы с медленным развитием когда этот быстрый старт надо перепроектировать.

У меня старт был давным-давно, сейчас просто эволюция вместе с бизнесом.

У меня нет постгреса в таких масштабах пока.

>Запрос пишется и отлаживается в IBExpert,

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

После быстрого старта бывают проблемы с медленным развитием когда этот быстрый старт надо перепроектировать.

Узнайте для себя такую вещь как слабая связность. И быстрый старт тут касается не проектирования, а написания кода.

Я рад за вас, но меня лично сильно раздражает необходимость каждый раз писать код для такой тривиальной операции как CRUD.

Вы как-то странно делаете вывод о моей скорости из описания процесса.

Написать запросы - 15% времени.
Закодировать - 25%
Постановка и уточнение задачи - 60%

ОРМ тут поможет в тех 25%, допустим ускорит в 2 раза, общее время практически не изменится.

Он поможет в 40 процентах. Так-как написание запросов может и не потребоваться.

В большинстве форм ее смысл заключен в запросе/запросах. Да, это надо тестить. Но 15% времени - это немного,

Вы бы про MVC почитали уже. Вы видимо даже как-то не в курсе что в случае ORM форма это и есть объект с данными.

кроме того этот смысл в виде запроса легко достать из программы и проверить/отладить в IBEXpert. Там есть подсветка, и переход на объекты, каменты, всякая статистика, просмотр описаний, отслеживание зависимостей и т.п.

Для crud операций? А смысл?

Кстати, стуктура БД - это практически основное, и любая форма отталкивается от данных, потом пишутся запросы и только потом это суем в программу.

Вы видимо меня плохо понимаете. У меня проектирование начинается с БД, а потом по ней генерится слой для работы с ней. В результате я сразу могу переходить к разработке приложения, в том числе минуя стадию отладить запрос вот для этой штуки. Когда таких запросов надо отладить больше 10 это мягко говоря утомительно и однообразно.

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

У меня складывается ощущение, что в вашу программу изменения вносятся раз в пятилетку. При таком подходе работает какой угодно метод программирования.

В этой вашей жабе эта "слабая связность" приводит к аду фреймворков с конфигурациями на хымыле, которые в 90% нахрен не нужны. FactoryOfFactoryOfFactoryOfFacade

Я не представляю что такое "сразу переходить к разработке приложения"
Запрос select * from table в отладке не нуждается, а иных у вас после генерации и не будет.

Это вы про метакласса? :P

User

theiced referenced to your post from Уебланология (http://theiced.livejournal.com/238876.html) saying: [...] http://metaclass.livejournal.com/800013.html?thread=17348877&style=mine#t17348877 [...]

Я айседу давно говорю, что у меня Firebird и дельфи и пиздец, а он не верит :)

Его надо принУдить к просмотру :)

ну не пизди.

http://metaclass.livejournal.com/800013.html?thread=17316365&style=mine#t17316365

такое у тебя тоже есть?

А я сочувствую тем, кто покупает еду в российских магазинах, учатся в школах, ходят к местным врачам и ездят по дорогам.

Они никогда не узнают, что бывает лучше.

Но, ведь они - жители - сами все это производят и обслуживают. За деньги. Производят говно и потребляют его же. И система находится в относительном равновесии.

Возможно, кто-то первый должен начать делать не-говно не за очень большие деньги, а за свою обычную зарплату. Но, я не вижу причины, по которым первыми(читай - крайними) должны быть именно программисты.

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

>панацея революция бизнес-процессы буллшит-бинго

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

Я вот все жду, когда вы до явовского Swing'а доберетесь. Было бы очень интересно почитать именно ваше мнение.

~~а ведь есть еще и Vaadin...~~

Как правило, люди не умеют планировать, поэтому требуют "фичи" "ко вчера". Больше нипочему.

Threaded | Top-Level Comments Only

Page 9 of 15

В Советской Белоруссии SQL разжигает айседа

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Уебланология

no subject

no subject

no subject

no subject

no subject

no subject