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

когда нужны уникальные ключи, а не последовательные и можно забить на фрагментацию (64 бит на порядка миллиона записей) - клиент берёт диапазон и генерит

а взятие диапазона можно атомизировать забив на перформанс

currval -- старьё, как я понимаю. А вот nextval -- чтобы заранее получить нужное значение, бывает нужно.

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

ну или написать сервер - тупо на сях - и забыть о проблеме

Не нашёл. Если там, где про JavaScript Python и PHP, то там другое утверждение. Там утверждение о достаточности, а я о том, что если найдётся вин, который таки сделал сантехник для программистов, то всегда можно сказать, что этот сантехник самый что ни на есть программист.

выявляется часто на продакшне, когда данных почему-то стало много.

Еще кстати такой момент - все что получено на клиента - по определению устарело. Что бы знать наверняка что данные еще не протухли - надо принимать специальные меры или согласиться с тем что данные могут быть протухшими. Вытаскивание данных в ОРМ - складировать протухшую инфу или напрягать программу и сервер на отслеживание актуальности данных.

Вы про что ORM умеет транзакции тоже не слышали да?

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

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

Да мне пофигу что там от чего отстает.

Это заметно.

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

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

Не. Не так.
На SQL оптимизация выполняется в процессе написания, и гавно видно сразу, кроме кривых планов на возросших данных.
А на ОРМ приложив усилие можно тоже написать гладко, но по дефолту легко получить гавно и не заметить этого.

На SQL оптимизация выполняется в процессе написания, и гавно видно сразу, кроме кривых планов на возросших данных.

Ну рассказывайте, рассказывайте. Что ни разу индекс не забывали?

А на ОРМ приложив усилие можно тоже написать гладко, но по дефолту легко получить гавно и не заметить этого.

На ORM не надо прикладывать усилий чтобы написать гладко. Там точно так же как и в случае SQL мы знаем тут будет много надо сразу сделать оптимизацию. Опять же такая оптимизация туда вносится ровно так же как и в SQL. У меня есть большой проект на ORM JPA и если бы я использовал SQL то усилий я бы затрачивал местами даже больше. Так-как местами пришлось бы выкручиваться а тут как а там как.

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

Я пишу код таким что бы я же с ним мог и разобраться.

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

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

Это вот из разряда не читал, но осуждаю. Для начала давайте вы посмотрите две документации
http://www.yiiframework.com/doc/guide/
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/
И расскажете что тут не так по вашему и чего же так остро не хватает и тому и тому.

Не слышал. Но речь не про транзакции а про то что не надо работать с данными которые по определению устарели. Надо работать с актуальными данными в базе. А если через ОРМ ухитриться так работать - то зачем оно вообще нужно? Промежуточное складирование перед показом на экране? А для чего такая трехходовка?

Посмотрел на код и не понял про что ты говоришь.
Какая логика работы? Тут вся логика - прочитать поле NAME, и записать его обратно, если редактирование было завершено.

На свете много чего есть. С какой стати я должен тратить свое время на освоение технологии которая может быть в чем-то удобнее, но требует кучу времени на изучение и переписывание. Вообще, желание "переписать все заново" нифига не конструктивно. Кроме того у меня проблемы с "быстрее/медленнее" нету. Она не в этом месте.

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

Слушайте вы прикидываетесь или правда не знаете фундаментальных вещей? Когда вы сделали select из базы эти данные уже устарели, потому что это данные не в СУБД, это данные у вас на экране. Из-за этого и нужны транзакции различные уровни изоляции.

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

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

Вообще, желание "переписать все заново" нифига не конструктивно. Кроме того у меня проблемы с "быстрее/медленнее" нету. Она не в этом месте.

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

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

Да не я не против. Чем больше таких людей как вы тем больше ценнее те кто знает более одной технологии и изучает новые.

У меня тупо кода мало - в нем и разбираться проще.
Пишет один - я, плюс брал еще одного товарисча по удаленке, москвича. Он пишет неплохо но сложно - как вам и нравится, обвешать все классами и объектами так что физ.смысл что это все делает заипешься отслеживать. Мне в памяти ячеек не хватает все это одновременно удерживать :) Поэтому давал ему такие вещи которые в случае возникновения косяков на критичные вещи в программе не повлияют.

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

Могу дать пример такого продукта. VirtualTreeView. Хорошая дока, и компонент. Но страдает тем же. И я не уверен что есть хоть что-то что было бы описано полностью. Хотя нет, вспомнил - документация на ОС РАФОС, он же RT11. Если ты там чего-то не нашел это означало только одно - плохо искал. Все что надо я там в конце-концов находил. "Но сейчас так уже не делают".

У меня тупо кода мало - в нем и разбираться проще.
Пишет один - я

Ну этим можно и закончить. Для того чтобы начать ценить такие вещи как ORM фреймворки и прочее надо поработать там где код пишет не один человек.

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

Как я и говорил. К тому времени когда надо будет копаться уже будет поздно.

Вы писатель? Это _Я_ вам пишу что все что вы получили из базы - по определению устарело. Но транзакции вам из тухнятины свежатинку никак не сделают. Они могут вам помочь получить непротиворечивое состояние временного среза данных. Они могут поймать и попытаться развести конфликт обновлений. Но без блокировки возможности изменений записи в базе вы никак не можете быть уверены что на клиенте копия этой записи не протухла. А вот блокировка может быть реализована не только с помощью транзакций.

Это _Я_ вам пишу что все что вы получили из базы - по определению устарело.

Да ладно? это кто пишет:

Надо работать с актуальными данными в базе.

Это вообще про что? И как? Вызывать данные в хранимке? Да та же фигня. Так же объявится транзакция и так же вы будете работать с устаревшими данными. Это суть всех РСУБД. Мы всегда работаем с данными которые потенциально устарели. Когда это критично объявляется максимальный уровень изоляции и все.

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

А зачем? Транзакция и нужна как раз для того что мы взяли данные провели манипуляции сунули в базу. ORM на устаревание данных никак не влияет.

А вот блокировка может быть реализована не только с помощью транзакций.

ДА ЛАДНО? Это как же и зачем?

Вы явно незнакомы с паттерном MVC. Сходите познакомьтесь.

У меня всего один большой проект который будет вечно ;)
Если вдруг он перестанет быть актуальным - у меня есть куча другой работы. Программизм - не единственное мое занятие.

Я в жизни изучил не одну технологию, многие из них уже устарели, например Clipper, FoxPro, Когда-то на фортране писАл, и макроассемблере. Просто сейчас мозг уже не позволяет просто так, из любопытства изучить какую-то новую технологию. Ресурсы ограничены и их становится все меньше.
FoxPro кстати был вполне неплохим инструментом для своего времени, позволял быстро решать задачи. ;) То что я на FoxPro делал за одну ночь между командировками, имея только одну бумажную книжку - справочник и никакого опыта, кроме фортрана и макро, потом на Delphi уже делалось за неделю.
Технологии становятся все сложнее и многочисленнее, каждая заявляется как революция и панацея, но немногие переживают более нескольких лет. Все узнать и изучить невозможно. Да уже тупо и неинтересно.

Threaded | Top-Level Comments Only

Page 7 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

no subject