Ошибка: (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'ов
Прога называется руки. Отформатировал пока разбирался с этим запросом.
Но ИМХО за такие запросы надо отрывать руки. И за запросики на десяток pagedown'ов - тоже. Это должно биться на несколько более простых запросов и собираться в результат на уровне аппсервера. Потому что я например в рот ебал SQL вместе с ораклом и мс-ом. В нормально написанном коде на java/.net - разобраться можно очень быстро + безболезненно смасштабировать все это на кластер. А в ебучем sql - хрен чего поймешь.
это ты с непривычки. я sql читаю так же просто как java или fortran. у нас как раз аппсервер из подобных запросов собирал себе кэш =) добро пожаловать в SAP CRM и CAS CPWerx. Писали то не мы, а немцы. Мы чисто аналитику разную прикручивали и performance tuning'ом занимались таких вот запросиков =) Когда у тебя десятки тысяч таблиц, подобные запросы в финансовой аналитике - обычное дело. Собственно чтобы избегать нагрузки от таких запросов на OLTP базы, и придумали OLAP.
Я хотел специально для парсинга SQL'я сделать сайтик, который бы подобные запросики из одной строчки разбивал бы в структурный вид, как у тебя.
Ну скажем так, не с непривычки, а от нелюбви к оному sql :) Ну и да - понятно что при базе на десятки тысяч таблиц это нормально. Но в данном случае а) Это рядовой запрос именно к OLTP базе. 2) никаких кэшей, кроме браузерного, не придусмотрено. 3) OLAP-ом там и не пахнет.
Насчет сайтика - в принципе задачка не из сложных. За выходные-двое пишется. По крайней мере в базовом варианте.
Ошибка: 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: что за прога так ловко табулирует джоины?
Reply
Но ИМХО за такие запросы надо отрывать руки. И за запросики на десяток pagedown'ов - тоже. Это должно биться на несколько более простых запросов и собираться в результат на уровне аппсервера. Потому что я например в рот ебал SQL вместе с ораклом и мс-ом. В нормально написанном коде на java/.net - разобраться можно очень быстро + безболезненно смасштабировать все это на кластер. А в ебучем sql - хрен чего поймешь.
Reply
у нас как раз аппсервер из подобных запросов собирал себе кэш =) добро пожаловать в SAP CRM и CAS CPWerx. Писали то не мы, а немцы. Мы чисто аналитику разную прикручивали и performance tuning'ом занимались таких вот запросиков =)
Когда у тебя десятки тысяч таблиц, подобные запросы в финансовой аналитике - обычное дело. Собственно чтобы избегать нагрузки от таких запросов на OLTP базы, и придумали OLAP.
Я хотел специально для парсинга SQL'я сделать сайтик, который бы подобные запросики из одной строчки разбивал бы в структурный вид, как у тебя.
Reply
Насчет сайтика - в принципе задачка не из сложных. За выходные-двое пишется. По крайней мере в базовом варианте.
Reply
Reply
Leave a comment