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

Прежде чем смеяться, скажи - нафиг оно тебе вообще сдалось, для начала. Для каких классов задач-то. Наследование это.

По поводу смеяться - в 10ке смеяться уже не над чем. Раньше да, было не совсем смешно
(пересоздавать классы). Впрочем, яж увы, так и не понимайт, чё те надо то вообще и о чём
(конкретно) речь идет.

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

И кинуть минус для явы. Называется - транзакционная межнодовая синхронизация сотояний объектов.
Которая у вас решается... (реально) только через то самое место - те же дергания блокировок,
только уже не латчей, а именно явных SELECT FOR UPDATE или менеджеров транзакций вроде
TUXEDO.

Что, в общем то, и доказывает однохренственность подходов. Как ни крути, а проблематика
единая, только лепить огород на яве - в разы тормознее (и по runtime и по разработке),
следовательно - дороже.

И в чем цимес - я не понимайт в упор. Вообще... (вспоминая стенания ебея про то, что без явы им
никак, ибо клястер видилите умирал на PL/SQLях... ну да, ну да.. типо).

Софтверный проктологЭто неправда :)
Я не знаю, что правда, а что неправда.

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

--

Мегазадача, кстати, тоже в огород яверов. Называется рефакторинг. Ты ведь SQL-и руками пишешь?
Ну и?

Ты поменял имя поля (или добавил, удалил). И что? Понеслась .... по трубам, перепроверять весь
.java/.jsp код (особенно последний, с подными связываниями биндинга)?
Мило. То ли дело - сразу получить инвалидацию пакетов.

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

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

Мда... и списочег "тупизмов" можно и продолжить.

-----

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

Софтверный проктологДаже в чисто вычислительных задачах Java быстрее чем PL/SQL :)

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

Будешь зело удивлён (о том, что 98% времени занимает мегаинтеллектуальный процесс постоянной
прогонки данных "туды-сюды" между БД и сервером приложений).

Софтверный проктологОткрой для себе Unit-тестирование :)
Ну ты мне сейчас ещё про третью нормальную форму расскажешь.
Ты хоть понял вообще, о чём я изначально говорил выше?

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

Яб даже посмотрел на оную фантастику. Честно.

Софтверный проктолог
ренегат
И отдельное укотайко. Яверы вообще головой не думают, как я посмотрю. Идея о том, что можно
генерировать базовые классы из метаданных в БД
Здрасьте, приехали.
Ты опять всё придумал :)
Да сколько ж можно? :)
Ну ну. Вообще я сужу по твоему посту выше. Сам же заикался, что автогенератором не пользуешься, а
пишешь всё руками. Или я не так тебя понял?

Софтверный проктолог
ренегат
Кстати, ты на пример ООП в бизнес задачах таки забил? Нет реальных примеров?
Я тебе уже всё сказал еще на прошлой странице :)
Конкретную прикладную задачу на ООП ты так и не озвучил. Общие фразы - не канают.

При том я тебе привел два примера на ООП в бизнес-задачах (клиенты по видам, и документы как
унифицированная сущность).

И? Так где там у тебя реально ООП применяется то? В виде геттеров и сеттеров, и коллекций для
итераторов? И? Это просто - особенности твоих средств доступа к данным, не более того.
Замечательно можно на геттеры и сеттеры забить (триггерами). Про итераторы даже заикаться
не буду (курсоры).

А что ещё то?

;))))))))

Софтверный проктологОсобенно замечтальеон, когда логика начинает присутствовать и на сервере СУБД, и на клиенте. Это просто чума :)

На клиенте логика отображения данных. К примеру раскраска цветом и тыкание пользователя
в незаполненные поля (во избежание насилований сервера экспешинами и роллбеками).

Никакой чумы не вижу.

Или ты вообще о чем?

Кстати, ещё раз для танкистов - с какого перепугу твой JVM перестал называться Клиентом?
Чем он отличается, по сути доступа к данным, от plsqldev.exe или toad.exe?

А?

Софтверный проктолог ренегат
Будешь зело удивлён (о том, что 98% времени занимает мегаинтеллектуальный процесс постоянной
прогонки данных "туды-сюды" между БД и сервером приложений).
Да, в некоторых задачах это так. В других — вычислительные расходы слишком велики :)

В каких именно? Говори вот на примере своих задач, хотя-бы.
Сказать, сколько будет реально занимать на SQL+PL/SQL парсинг сотни мегабайт логов?

Можно спаринг даже устроить, право. Только боюсь, что ява твоя - ни в жисть не догонит SELECT FROM EXTERNAL TABLE.
С отставанием только не в проценты, а в десятки раз (порядков).

Или тарификация, расчёт сальдо? (Сброс коллекции в БД супротив INSERT (MERGE) FROM (SELECT)?

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

Я тебе говорил, что не пользуюсь автогенераторами SQL.
Если ты решил, что я пишу в блокноте, то это исключительно твои проблемы мировосприятия :)

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

Это примитив и ручной (тупой) труд. Как любая рутина - плодящая глупые баги на пустом месте (в процессе и опосля).

Софтверный проктолог ренегат
И? Так где там у тебя реально ООП применяется то? В виде геттеров и сеттеров, и коллекций для
итераторов? И? Это просто - особенности твоих средств доступа к данным, не более того.
Замечательно можно на геттеры и сеттеры забить (триггерами). Про итераторы даже заикаться
не буду (курсоры).
Ерунда какая :)
Как геттеры и сеттеры соотносятся с триггерами? :) Ваще не пойму :)
Непосредстванно. На кой тебе вообще нужен геттер и сеттер? Геттер - это VIEW (соврал выше). А вот сеттер - в чистом виде триггер (на таблицу или вьюху). По сути и назначению.

А таблица (или вьюха) - это и есть коллекция бизнес-объектов (нет?)


P.S. На начинающих - пофег. Пусть буквари с лекалами читают. Через лет пять поймут, что буквари - это туфта ещё та.

Софтверный проктолог ренегат
В каких именно? Говори вот на примере своих задач, хотя-бы.
Сказать, сколько будет реально занимать на SQL+PL/SQL парсинг сотни мегабайт логов?

Давай устроим спарринг :)
Нивапрос.

Софтверный проктолог
ренегат
Можно спаринг даже устроить, право. Только боюсь, что ява твоя - ни в жисть не догонит SELECT FROM EXTERNAL TABLE.
С отставанием только не в проценты, а в десятки раз (порядков).
Проверим? :)
Готов выдать тестовые условия и исходные данные?
Тестовые данные просты. На 100000 лицевых счетов закатать почасовые величины объемов за месяц.
На входе - CSV файл, полученный с TACACS.

Софтверный проктолог ренегат
Или тарификация, расчёт сальдо? (Сброс коллекции в БД супротив INSERT (MERGE) FROM (SELECT)?
Ты уверен, что понимаешь в чем заключается процесс тарификации и каким сложным и гибким он бывает?
Вполне понимаю. Да, нужно иметь определённые навыки написания подобных SQL. И даже мощь Oracle не всегда спасает (бывает пару-тройков проходов таки нужно делать).

И что с того? В любом случае продолбить даже методом slow-by-slow (в циклах PL/SQL) в разы быстрее, чем сначала гнать данные на Клиента (типо тот самый Сервер Приложений), а потом
обратно.

Неужто ты в этом ещё сомневаешься?

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

Это примитив и ручной (тупой) труд. Как любая рутина - плодящая глупые баги на пустом месте (в процессе и опосля).
Примитива меньше, чем разработке на PL/SQL.
Увы ниачем.

Может быть у тебя какой-то мегачудо интеллектуальный свой ORM, но ты мне в упор не докажешь,
что банальная задача по той-же тарификации (или выписке счетов) у тебя на Java коде будет
в разы лаконичнее, чем на PL/SQL.

А вот я могу доказать обратное - с легкостью (только за счёт нивелирования декларации классов с обвязкой).

Или сомневаешься?


Софтверный проктолог
ренегат
Непосредстванно. На кой тебе вообще нужен геттер и сеттер? Геттер - это VIEW (соврал выше). А вот сеттер - в чистом виде триггер (на таблицу или вьюху). По сути и назначению.

А таблица (или вьюха) - это и есть коллекция бизнес-объектов (нет?)

Фантастическая аналогия :)
Ты по такому принципу разрабатываешь свои системы? :)
Ты разрабатываешь точно по такому же принципу. Стань на сервер БД и посмотри, что есть что для него.