Пришлось мне по работе иметь дело с "замечательным" биллингом UTM5.
Задача: вытащить все данные клиентов, включая id и имя основного лицевого счета (мастер-аккаунт) и всех связанных с ним с подчиненных аккаунтов. Учитывая гениальную "...улучшенную и оптимизированную структуру БД..", в которой, к слову сказать, во всех таблицах 1 индекс (и то не уникальный) по полю id, задача нетривиальная. Поиск по форуму зазрабов ничего не дал. Несколько дней мучений, советов на #mysql, несколько литров кофе, тонна табака и куча матершины дали результат :) Всем UTM-мученикам посвящается:
Забирайте. Пользуйтесь. Кто там кричит "неоптимизированный запрос" и "зачем столько проверок" ?! Не нравится - не пользуйся! Можешь лучше - покажи! Запрос рабочий. Тянет всю читабельную инфу из users, обращенный IP и маску, id тарифа, id сервиса.
Минусы: весьма тяжелый запрос. На нашем серваке он так и не отработал; тупо повис. Пришлось по одной таблице перетянуть на локальную машину, - это раз. Два - для сбережения своих же нервов советую сразу в поднятом локально дампе проставить индексы. Даже на локальной машине этот запрос вешался, пока я не добавил индексы. Хотя бы такие: в users добавляем по полю login; в ip_groups - ip и ip_group_id; в ip_group_id - ip_group_id, account_id, tariff_link_id; в account_tariff_link - account_id и tariff_id. Хотя, даже половина этих индексов уже заметно ускорит выполнение тяжелых запросов вроде этого.
NOTICE: В данном запросе не учитываются дайлапщики, но я думаю, на этой базе уже не так сложно будет допилить запрос под свои нужды.
Задача: вытащить все данные клиентов, включая id и имя основного лицевого счета (мастер-аккаунт) и всех связанных с ним с подчиненных аккаунтов. Учитывая гениальную "...улучшенную и оптимизированную структуру БД..", в которой, к слову сказать, во всех таблицах 1 индекс (и то не уникальный) по полю id, задача нетривиальная. Поиск по форуму зазрабов ничего не дал. Несколько дней мучений, советов на #mysql, несколько литров кофе, тонна табака и куча матершины дали результат :) Всем UTM-мученикам посвящается:
SELECT DISTINCT
u.id main_id, u.login main_login,
sl.account_id acc_id,
ip.uname uname, ip.upass upass,
atl.tariff_id tarif,
sl.service_id service_id,
u.full_name,
inet_ntoa(ip.ip&0xffffffff) ip,
ip.mask,
u.juridical_address jur_address, u.actual_address actual_address,
u.work_telephone work_telephone, u.home_telephone home_telephone,
u.mobile_telephone mobile_telephone,
u.tax_number tax_number, u.kpp_number kpp_number
FROM ip_groups AS ip
LEFT JOIN iptraffic_service_links AS isl ON isl.ip_group_id = ip.ip_group_id
LEFT JOIN service_links AS sl ON isl.id = sl.id
LEFT JOIN users AS u ON sl.user_id = u.id
INNER JOIN account_tariff_link AS atl ON sl.account_id = atl.account_id
WHERE
sl.is_deleted = 0
and isl.is_deleted = 0
and ip.is_deleted = 0
and u.is_deleted = 0
AND atl.is_deleted=0
AND ip.is_deleted=0
ORDER BY u.login
Забирайте. Пользуйтесь. Кто там кричит "неоптимизированный запрос" и "зачем столько проверок" ?! Не нравится - не пользуйся! Можешь лучше - покажи! Запрос рабочий. Тянет всю читабельную инфу из users, обращенный IP и маску, id тарифа, id сервиса.
Минусы: весьма тяжелый запрос. На нашем серваке он так и не отработал; тупо повис. Пришлось по одной таблице перетянуть на локальную машину, - это раз. Два - для сбережения своих же нервов советую сразу в поднятом локально дампе проставить индексы. Даже на локальной машине этот запрос вешался, пока я не добавил индексы. Хотя бы такие: в users добавляем по полю login; в ip_groups - ip и ip_group_id; в ip_group_id - ip_group_id, account_id, tariff_link_id; в account_tariff_link - account_id и tariff_id. Хотя, даже половина этих индексов уже заметно ускорит выполнение тяжелых запросов вроде этого.
NOTICE: В данном запросе не учитываются дайлапщики, но я думаю, на этой базе уже не так сложно будет допилить запрос под свои нужды.
Комментариев нет:
Отправить комментарий