Программерское, опять с работы

[nagwal]

Настоящий enterprise-программист это тот, который не начинает плакать горькими слезами при виде вот этого:

Comments

[bopox]

это если у тебя оракл, а если у тебя MSSQL то если ты заведёшь виртуальные временные таблицы - всё встанет колом.

А про where hui = @huiDELL ... io.id in (@table-IO-params) истину глаголишь. Более того, неплохо было бы prepare делать, ну чтобы смазка лучше легла =)

[nagwal]

Знаешь, еще пару раз увижу такое в коде - начну применять опиздюлятор. Как показывает практика: после пары ударов по печени/почкам на программера снисходит просветление :)

[deroc]

Бить ногами по почкам за такое!

1. Оно - не поддерживаемое
2. Оно - пиздец сколько работает
3. Не факт, что работает правильно, ибо человек отследить правильность не сможет, а дебагером - хрен пройдешь :)
4. Если это результат hql, значит структура классов выстроена извратным образом и пизды уже архитекторам
5. DISTINCT нам какбе намекает на то, что данные дублируются, значит ER спроектирована херово.

[nagwal]

Это результат работы местного велосипедного sql-генератора (логика которого раскидана по 2-3 десяткам классов). И мне надо подправить порядок возвращаемых значений.

А виноваты в этом ужасе ВСЕ. И программеры, и архитекторы и начальство.

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

[nagwal]

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

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

Главное - продержаться еще пару месяцев, рассчитаться с долгами и купить самые критичные и дорогие штуки.

[bopox]

Ошибка: (SELECT MAX(cpuPeak.AvgUsage) PeakValue !!тут должна быть запятая!! cpuRes.InventoryId VmId FROM
Ошибка: SELECT SUM(vfi.SizeBytes) SizeBytes !!тут должна быть запятая!! vvf.InventoryId VmId FROM

это вообще чегобля? SELECT hvgd.VmId VmId SUM(hvgd.capacityBytes) capCol
SUM(hvgd.freeSpaceBytes) fsCol FROM vk_vmware_guest_disk hvgd

короче хуёво написанный простенький запросик. Когда мои седые яйца тряслись над гиперкубами корпорации InBev, там были запросики на десяток pagedown'ов

PS: что за прога так ловко табулирует джоины?

[nagwal]

Прога называется руки. Отформатировал пока разбирался с этим запросом.

Но ИМХО за такие запросы надо отрывать руки. И за запросики на десяток pagedown'ов - тоже. Это должно биться на несколько более простых запросов и собираться в результат на уровне аппсервера. Потому что я например в рот ебал SQL вместе с ораклом и мс-ом. В нормально написанном коде на java/.net - разобраться можно очень быстро + безболезненно смасштабировать все это на кластер. А в ебучем sql - хрен чего поймешь.

[bopox]

это ты с непривычки. я sql читаю так же просто как java или fortran.
у нас как раз аппсервер из подобных запросов собирал себе кэш =) добро пожаловать в SAP CRM и CAS CPWerx. Писали то не мы, а немцы. Мы чисто аналитику разную прикручивали и performance tuning'ом занимались таких вот запросиков =)
Когда у тебя десятки тысяч таблиц, подобные запросы в финансовой аналитике - обычное дело. Собственно чтобы избегать нагрузки от таких запросов на OLTP базы, и придумали OLAP.

Я хотел специально для парсинга SQL'я сделать сайтик, который бы подобные запросики из одной строчки разбивал бы в структурный вид, как у тебя.

[nagwal]

Ну скажем так, не с непривычки, а от нелюбви к оному sql :) Ну и да - понятно что при базе на десятки тысяч таблиц это нормально. Но в данном случае а) Это рядовой запрос именно к OLTP базе. 2) никаких кэшей, кроме браузерного, не придусмотрено. 3) OLAP-ом там и не пахнет.

Насчет сайтика - в принципе задачка не из сложных. За выходные-двое пишется. По крайней мере в базовом варианте.

[emoveo]

Как ж хорошо, что я не в корп.секторе.
У нас тут, в вебовом хайлоуде, все в итоге приходит к
select id from qqq where что-то только из индекса
и
select * from qqq where id=
иначе пизда, джойны только изредка, очень аккуратно и по маленьким таблицам, либо статистика всякая для местных

либо sql совсем нет, никаких блять ООП генераторов, хибернейтов и прочей хуйни.

[bopox]

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

[deroc]

Мне кажется - наоборот. Обычного SQL достаточно для большинства задач. А вот в enterprise нужны другие методы работы с данными. Не от хорошей жизни появляются OLTP, OLAP и прочие хрени.

[nagwal]

Угу, в вебе хорошо :) Я тоже к вам хочу! Просто сейчас больно уж неподходящее время для очередной смены работы.