vandererЧто мешало задать вопрос автору статьи? Тем более, что цель вопроса - всего лишь придраться к этой интуитивно-экспертно-потолочной оценке.

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

Вот он тут и обсуждает, обсудить-то хочется...

IzyavandererЧто мешало задать вопрос автору статьи? Тем более, что цель вопроса - всего лишь придраться к этой интуитивно-экспертно-потолочной оценке. Нет, цель вопроса - узнать, является оценка "два порядка" верной ли по мнение местной публики. У людей есть опыт, мысли. По мне, она имеет право на жизнь, но вдруг я ошибаюсь?


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

Ну, уж изволь, раз уж ты так хочешь ...

авторОбщая скорость работы приложения обуславливается двумя категориями:
1) скоростью работы каждого из звеньев приложения;
2) скоростью взаимодействия между звеньями приложения.

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


Ага, а что есть state full запросы и в серверах приложений -- это автор не знает.
и что всякие техники распараллеривания БД есть -- видимо, тоже не знает.

авторИ из этой ситуации сейчас существует два выхода:
а) разместить логику приложения внутри базы данных;
б) кэшировать данные внутри сервера приложений.

Выбрав вариант «а», вы сможете увеличить скорость примерно на два порядка порядок: до 100 000 запросов в секунду. Неудобство в том, что при этом мы вынуждены логику реализовывать на встроенном языке базы данных. Вариант с С# или Java –процедурами не подходит, т.к. такие процедуры выполняются в виртуальной машине, которая фактически является отдельным процессом и по времени взаимодействия практически не отличается от внешнего сервера приложений. И хотя встроенный язык программирования не очень приспособлен для реализации логики приложения, во многих банках используется именно такой подход. В основном в таком случае используется, конечно же, Oracle со своим встроенным PL/SQL.


Ага, и интересно чем это эти встроенные языки не подходят....
Во-первых, во многих СУБД есть и встроенные C# с Java -- пиши, если нравится.
Во-вторых, языки типа Transact SQL и PL/SQL мощны, близко находятся к данным, хорошо с ними работают, лишены проблем типа утечек памяти, и -- главное -- поддерживают ту же парадигму программирования, что и БД -- реляционные вычисления. И учаться ещё легко.
Это ИДЕАЛЬНО для разработки бизнес-логики.

авторТеперь поговорим о перспективах. Сейчас тихо и незаметно происходит настоящая революция в компьютерной технике – переход на 64-бита.


Статья за март 2012 года.
ДА 64 БИТА УЖЕ ЛЕТ 5 как рулят вовсю! 2001 году винды вышли 64 бита и ядро линукса.
Автор проспал всё на свете...

авторПо всей видимости, в скором будущем мы увидим объединение сервера приложения и базы данных. Первые шаги сделаны: Oracle купила технологию Java, а Microsoft уже встраивает SQL-запросы в язык C#. Т.е. они стараются засунуть логику внутрь своей СУБД.


Ну, и с этим автор тоже давно уже всё "проспал".

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


Ну фееричный вывод. Да.. не может ООП-то нами использоваться, не может!
В общем, детский сад.

IzyaЯ и с первого раза понял, что по делу Вам сказать нечего.


Как раз он очень по делу сказал. Чтобы иметь конкретные цифры, надо иметь конкретную задачу, а тут (в статье) -- только пустые слова.

IzyaУ Вас есть опыт переноса какой-то конкретной логики с клиента на сервер в какой-нибудь (любой) конфигурации? Если есть, какой выигрыш (оценочно или точно) Вам это дало при использовании этой конкретной логики? Если не трудно - что это была за конфигурация.


В разных ситуациях будут разные выигрыши, иногда это будут наоборот проигрыши.

iscrafmэто действительно так, но это не "мэйнстрим".


Это -- мейнстрим.

iscrafmК тому же, нужно уметь разложить сложный процесс на простые и быстрые составляющие и скормить их в нужном порядке СУБД.


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

iscrafm Но!... Сейчас этому не учат, концентрация внимания на ООП, даже там, где оно "за уши притянуто". Попробуй среднестатистическому современному разработчику поставить какую-либо задачу из бизнес-логики... Будет долгий поиск сущностей и объектов там, где необходимо 2+2 выполнить. По этой причине в ход идут совершенно другие инструменты.


Где не учат? Не знаю...
Вообще-то в мире баз данных ООП противопоказано. Т.е. объект со структурой -- пожалуйста, наследование -- пожалуйста, но не инкапсуляция. Даже ОО-СУБД не такие уж ОО -- инкапсуляцией даже там и не пахнет.
Суть БД (и СУБД) в том, что приложение РАСКРЫВАЕТ для СУБД внутреннюю структуру данных, описывая её в виде метаданных,
и этим позволяет СУБД выполнять всяческие оптимизации по хранению и обработке этих данных.

И это признано всеми вроде бы ведущими экспертами. Никто вроде бы не спорит. Так что я не знаю, про что это.