Софтверный проктологА кроме code-complete в современных IDE есть:
а) автоматический рефакторинг всего и вся (включая JSP);
Не работает, если ты рефакторишь саму бд. Фактически, ты делаешь работу чуть-ли не дважды
(сначала там, потом сям). Средства валидации нет вообще (в виду позднего связывания биндинга и не только).

Символьные выражения - ничерта не рефакторятся (по определению).


Софтверный проктологб) шаблоны (хотя это даже в каком-нить PL/SQL Developer-е есть);
Фонарь полный. Очередной ....низм на тему copy/paste
Софтверный проктологв) отличная интерактивность в коде;
Вас из дас?

Софтверный проктологг) средства автоматизации работы с бинами, EJB, разнообразными фреймворками.
Нафиг надо оное, если оное - нафиг не надо? Нет бинов, нет EJB. Средства "автоматизации" - автоматически тоже - не нужны.

Софтверный проктологВ общем, полный контроль над кодом :)
Да? И чего там тебе в PL/SQL (PSD, TOAD) контролировать то не дают, а?

Софтверный проктолог

Спрыгиваешь вообще.

Итого ты не ответил:

а) примеры необходимости ООП в прикладном коде (бизнес-задачах);\
б) примеры массированной нагрузки вычислениями (в задаче биллинга, про кодирование видео мы говорить не станем).
в) принцип организации доступа к данным - ты так и не осветил, вернее сначала осветил, потом
открестился от самого себя (у тебя и руками ничего не пишется, и геттеры и сеттеры не используются,
и вообще хрен поди пойми, как из голого JDBC данные попадают из и на сервер БД и куда).

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

P.S. Так что в проктологи тебе пока рано (опыта, что-ль, нет, для сравнений).

P.P.S. Кстати, про SQL*Loader ты реально зря заикнулся. Это не есть надежное решение server-side (в задаче заливки логов). Да и глупо (особенно когда форматы разные - ты делаешь работу дважды - сначала льешь в таблицу-"обменник", а потом куда там тебе для счетов-начислений надо).

А мог бы и сразу ;))

Софтверный проктологJava — достойное решение, при любом раскладе :)
При любом раскладе использование явы следует минимизировать, или вообще сводить на нет (почти цитируя Кайта).

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

Ибо не сколько она тормоз, сколько тормозная и затратная разработка на ней. Это не тезис, это
жестокая правда жизни.

Софтверный проктологИ что интересно — я могу решить требуемую задачу кучей способов:
а) распарсить данные awk и залить sqlldr/bcp,
б) сделать заливку с помощью Java (с привязкой трафика к абонентам),
в) просто залить данные в СУБД и написать обработку с помощью хранимых процедур,
г) снимать данные напрямую с железки и лить их в СУБД,
д) другие способы

А товарищ grexhide может только в СУБД. И без СУБД он отдыхает :)
а) в т.ч. только это криво в драбодан.
б) не звизди про привязки. у тебя код устройства уже есть в схеме учета, а вносить избыточность в данные сьема показаний счетчков - бессмысленно.
в) что значит "просто залить"? INSERT-BY-INSERT со скоростью тыща записей в секунду... два дня на пару десятков миллионов?
г) по пункту в?
д) ну ну, как всегда, конкретика на высоте.

----

Короче, дядя, что-то ты уже совсем заговорился. Лучше ответь на мои вопросы выше.

Софтверный проктолог ренегат
а) примеры необходимости ООП в прикладном коде (бизнес-задачах);\

Это бессмысленно :)

Т.е. реально тебе ООП и даром не нужен?

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

Я уже сказал про тарификацию. Это самый длительный и трудоемкий процесс (если ты не сталкивался — что я могу поделать)?
Я то как раз и сталкивался. Все замечательно решается на PL/SQL, ява там и нахер не нужна.

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

Запросы. Инсерты. Апдейты. Вот мои принципы организации доступа к данным :)
На Клиенте (который мы называем уже Севером! приложений) то что? В массивы данные закатываешь, что-ли?
Софтверный проктолог
ренегат
д) по поводу обработки данных не на сервере приложений ты тоже слил.
если ты щелкаешь все SQL запросами - тогда тем более не понятно, на кой там ява-сервер это раз, а
два - ты вяжешься на диалекты SQL, и вся твоя незевисимость от БД - пустой треп (в виду отсуствия
оной, независимости).

Ты же все-равно не хочешь знать, на кой вообще нужен ява-сервер :) Что языком попусту молоть.
А ты и не пытаешься объяснить, увы.

Софтверный проктолог ренегат
P.P.S. Кстати, про SQL*Loader ты реально зря заикнулся. Это не есть надежное решение server-side (в задаче заливки логов). Да и глупо (особенно когда форматы разные - ты делаешь работу дважды - сначала льешь в таблицу-"обменник", а потом куда там тебе для счетов-начислений надо).
Ну, я видел такие решения.
Заливается всё-таки быстро.
Или ты хочешь сначала с сервера предбиллинга качать файлики на сервер биллинга и уже в нем из select from external table получать данные? Разве не глупо? :)
Качать ты будешь в любом случае (что-то там). А заливать через EXTERNAL TABLE - реально быстрее,
можешь пораскинуть мыслью, почему-же (кстати, при любых раскладах).

И где глупость то?

Софтверный проктологКстати, трафик проходит очень много превращений пока не станет строчкой счета. Ты же понимаешь? :)
Ну и что с того? Вся суть этих превращений - схемы агрегаций с вариациями. Тот самый
INSERT INTO Строка_счета SELECT FROM (SELECT CASE FROM GROUP BY), Тарифы) GROUP BY и т.ж.

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

Софтверный проктолога) Ты соврал.
Ну ну, awk и sqlldr - это мегаэффективное средство?

Софтверный проктологб) Ты соврал. Ты реально не работал с биллингами, которые считают разные услуги разных классов.
Бабушке сказки расскажи, право. Услуги бывают двух типов - по счетчику или по нормативу. Точка.
Всё остальное - производные (суть у которых одна и та-же). А дальше - начинается просто банальная лирика - каждый факт расхода периода пропускается по схеме и тарифам.

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

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

Софтверный проктологв) INSERT-BY-INSERT со скоростью 45000 записей в секунду — хватит?
Сказочнег. В одной сессии то? Впрочем, если у тебя там в записи два числа и на той стороне стоит
(десяти)гигабитный линк, то может быть тебе и удастся достичь оного. Только на том же
оборудовании порядки никто не отменял. И там где у тебя будет 45к по записи - там будет 1м
пачкой.

Софтверный проктологг) по пункту в)
д) :)
Нуда, конечно.

Софтверный проктолог ренегатЯ то как раз и сталкивался. Все замечательно решается на PL/SQL, ява там и нахер не нужна.
Да, я видел такое решение.
Не стал бы употреблять слово «замечательно» в этом контексте :)
Ниачем.

Софтверный проктолог
ренегат
На Клиенте (который мы называем уже Севером! приложений) то что? В массивы данные закатываешь, что-ли?

В объекты. В коллекции объектов. В отличие от доступа через view и триггеров — эти операции очень дешевые в большинстве своем.
Неужели? Сколько ты говоришь стоит (по времени) заполнить коллекцию 10000-ю записей или 10000 коллекций по одной записи?

В сравнении?

Софтверный проктолог
ренегат
Качать ты будешь в любом случае (что-то там). А заливать через EXTERNAL TABLE - реально быстрее,
можешь пораскинуть мыслью, почему-же (кстати, при любых раскладах).

И где глупость то?

EXTERNAL TABLE не заливает никуда данные. Он их подбирает. Потом их всё-равно нужно вставлять в реальные таблицы (с реальными индексами и триггерами).
Ну ты меня совсем за идиота решил подержать? Сделай замер заливки данных. А тебе, стало быть, через sqlloader с индексами и триггерами делов иметь не надо уже?


Софтверный проктолог ренегат
Ну и что с того? Вся суть этих превращений - схемы агрегаций с вариациями. Тот самый
INSERT INTO Строка_счета SELECT FROM (SELECT CASE FROM GROUP BY), Тарифы) GROUP BY и т.ж.
Ты опять неправ.
Какой тут insert select case from? В прошлом веке еще такое могло проканать. Сейчас уже нет.

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

Софтверный проктолог ренегат
Я не видел ни одной схемы тарификации, которую нельзя было бы расчитать одним (пусть и сложным) SELECT-ом. Нет там таких фундаментальных моментов, которые выбиваются из агрегаций и итераций с условиями. Просто нет.

Я так не думаю :)
Пример в студию. Иначе - просто слив.

Софтверный проктолог ренегат
Сказочнег. В одной сессии то? Впрочем, если у тебя там в записи два числа и на той стороне стоит
(десяти)гигабитный линк, то может быть тебе и удастся достичь оного. Только на том же
оборудовании порядки никто не отменял. И там где у тебя будет 45к по записи - там будет 1м
пачкой.
Ты прикидываешь или просто не в курсе?
JDBC драйверы умеют работать в bulk-режиме — передавай только вставляемые в таблицу данные сплошным потоком.
Тоже мне, Америку открыл ;)) Я тебе про array insert и говорил изначально. Посчитай расходы
сначала на межпроцессные (и межмашинные) передачи данных, а потом поговорим, кто там, и что там будет быстрее.


Софтверный проктолог
Если у тебя сеть не пропускает больше 45k через JDBC — она не пропустит больше и ни через какой external table / sqlldr, в принципе :)
Ты ошибаешься. Сильно.

Софтверный проктологТолько что ты мне тут распинался, что я делаю двойную работу (типа заливаю туда, откуда еще нужно будет куда-то переносить).
Короче, дядя. Задачу на поиск оптимального способа заливки больших объемов данных ты не решал.
Да тебе и решать то её - не особо то и нужно. Особенно, если ты (не понятно на кой) - оное все
считаешь на своей чудо JVM.

Еще раз говорю - сравни затраты одного процесса (который просто открыл себе файл и пошел его обрабатывать) супротив межпроцессоного взаимодействия.

И на заливке данных в БД и на извлечении из неё на Клиента (который у тебя гордо именуется сервером).

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

Не больше, не меньше. А на кой это делается - вообще не понятно.

Софтверный проктологЭто как так? Получается, что это для тебя не новость, но скорости в 45k ты удивился? Прости, почему?
Реальные замеры. Выше 10к нам прыгнуть не удалось даже на гигабитном линке. Как оказалось - тормоза были вовсе не в сети. Реально тормозил OCI на клиенте (и система) и принимающая сторона (сама система + сам oracle).

Т.е. узкое место было уже в CPU (и в семафорах в т.ч. при распараллеливании).

Ах да, данные были чуть посложнее, чем два числа.


Софтверный проктолог ренегатТы ошибаешься. Сильно.
Заметь, я сказал про сеть. А не про скорость вставки.
А я как раз говорю про скорость процесса в целом.

Софтверный проктолог100%, что Цэбосс написан на Яве. На такой нереально мощной машине всего 2000 записей в секунду и 800 000 аккаунтов в час :)
Насколько я знаю - не на яве. А так - этож известный боян.

Причины там не в подходе, а в совсем ином месте.