Kolbasoff wrote:helg wrote:Тут приходит век ORM - и ароматный вегетарианец оперативно пишет замену системе.
Доводилось оптимизировать вегетарианский код с хайбернэйтом. Сначала делают какой-нить customer = getCustomerById(), который транслируется в запрос на килобайт и рассовывает результат на три килобайта по классам. А потом оказывается, что нужно-то всего один маленький флажок на пару байтов, типа customer.isCustomerTaxExempt(). Но пяток килобайт уже по сети слетал. А потом под нагрузочку это ставят. И фсё тихо умирает. Тогда вегетарианские мудрецы созывают консилиум и решают, что необходимо кэширование. И оно таки улучшает процесс, но начинаются проблемы с рассинхронизацией кэша и базы, что приводит к неправильным биллам для кастомеров. Да и код становится угорожающе объемный. И тогда вегетарианцы-консультанты обновляют резюме ибо не царское это дело гумно утрамбовывать (в резюме они не забывают перечислить все новые познанные технологии и упомянуть как они улучшили и углубили), а вегатарианцы-постоянщики подходят к старику Колбасоффу, который занят поисками нужной комплектухи для его поделок, и просят взглянуть на код незамутненным взглядом. Старик Колбасофф чешет лысеющую голову, выкидывает весь этот хлам нафик и пишет createSQLQuery("select tax_exеmpt from customer where customer_id = :customer_id"). И о чудо! Код начинает работать раз в пять быстрее и биллы уже не так лажают.
Это реальная история если что, хотя я уверен что лично у вас все не так. Ведь красавицы не пукают.
а вот что молодой Комиссар писал 12 лет назад:
Komissar Wed Apr 30, 2003 9:27 am wrote:
Уже несколько лет мне приходится работать с миддле-тирами (не моего изготовления), где табличное представление Оракла конвертируется в обьектное. Из личного опыта -- очень тормозные штуковины. Начинается все весело: глав.архитектор говорит, возрадуйтесь девелоперы, таперича заместо заморочных "select a,b, c from employee where ssn=123456789..." вам достаточно написать, getEmployee(123456789) и все пучком. Пишется небольшая демо прога, где, действительно, employee вытягивается из БД со скоростью сравнимой с прямым запросом. Все дружно радуются.
По ходу дела, клиенту, оказывается, нужны имена работников, у которых ssn такие-то, и к-рые брали отпуск в период с авг 2001 по окт 2002, и к-рые задолжали по 1 книге в компанейской библиотеке... и т.д. Причем клиенту в результате запроса нужны только имена, богатство и структура наших бизнес-обжектов ему до фени. То, что легко и свободно сделалось бы джойном школьного уровня, теперь надо раскоряченно писать, собирая огромные коллекции обьектов, а потом интеррогировать каждый обьект. Система жутко тормозит, клиент недоволен.
Ничего, глав. архитектор пишет всякие "хелперы", и "класс фактори". Какие-то проблемы решаются, возникают новые.
В конце концов, глав. архитектора осеняет, и он пишет супер-обжект getRecordSetFromSQL(String sql), и говорит, возрадуйтесь, девелоперы. Теперь вместо того, чтобы писать заморочный код типа :
getCollectionOfEmployees();
getCollectionOfVacations();
getCollectionOfLoanedBooks();
а потом муторно их процессить, вам достаточно составить легкий и удобопонятный SQL, запустить его в обьект, и процессить потом симпатичную табличку рекордов. Пишется демо прога, где совершенно ясно доказывается преимущество "нового" ООП против прежнего "ООП". Все дружно радуются.
Приходит новый глав. архитектор, смотрит и говорит, надо, робяты вам переходить на более ОО подход. Надо думать в обьектах: Employee, Vacation, LoanedBook. Пишется демо прога...
когда мы учились, джавы еще не было, вернее не была так распространена.
если в этом году выполню первый разряд, то поеду на чемп РФ.
А для Big Data хибернейт наверняка не нужен ...
