Здравствуйте все.
Есть запрос:



И это лишь 2 таблицы.
Просто прикидываю алгоритм. Но БД будет 4-5, а дальнейшем количество БД будет лишь расти.
Можно ли как-то соптимизировать данный запрос средствами mySQL?
Или нет?

MasterZivI.CaRИ это лишь 2 таблицы.
Просто прикидываю алгоритм. Но БД будет 4-5, а дальнейшем количество БД будет лишь расти.
Можно ли как-то соптимизировать данный запрос средствами mySQL?
Или нет?

Можно, и ты не поверишь -- надо ВСЕ ДАННЫЕ СЛОЖИТЬ В ОДНУ ТАБЛИЦУ!
Надо же! Как-так я сразу-то, глупый я человек, недогодался при разработки БД!!!
А хранить её в облаке? С постоянным коннектом с интернет?
Посвящу вас немного в проект... ПО Клиент-Серверное приложение, локальное. Работает в ЛВС. Распространено по переферии, по разным регионам РФ, где не всегда и интернет-то есть (не забываем, что РФ, это не только МСК). В БД пишутся и фотографии, так что сами понимаете, чем это чревато при нестабильной связи.
Как раз сейчас и занялся разработкой выгрузки данных из периферийных БД и загрузкой в так называемую "центральную" БД.
А данный пример выборки делал для, как всегда срочного отчёта в кикие-то властные структуры нашей бюрократической страны, дабы не напрягать девчонок перебеванием в ПО с листочков уже когда-то вбитые данные.
Есть конструктивные предложения по централизации данного ПО? Пишите, рассмотрю.

miksoftI.CaR
За такое надо по рукам давать.
Если это не работает, то за одно, а если работает, то за другое :)
Ёпт твою ... на лево!
Вас здесь таких много, примитивов?
Упрощение листинга - понятие для вас чуждо?
Хорошо, см:


Теперь вам проще, понятнее?

AkinaI.CaRБД будет 4-5, а дальнейшем количество БД будет лишь растиМожет, всё-таки таблиц?

I.CaRМожно ли как-то соптимизировать данный запрос средствами mySQL?Да нечего тут оптимизировать. Был бы индекс по полю date_test...
Спасибо за ответ. Этот пример, так... Девчонок спасаю. С них отчёт срочно такой вот потребовали, какие-то гос.структуры.
А реализовывать программно выгрузку-загрузку, не одного дня работа.
По поводу "кол-во БД". Я привёл пример, так как самих БД у меня 5, а ещё и новые доп.офисы постоянно открываются (поэтому исходя из этого выразился так), а в запрос, соответственно пойдёт лишь участие таблиц (пока участие таблиц...).

Dimitry SibiryakovI.CaRИ это лишь 2 таблицы.
А зачем это две таблицы, а не одна?
Почему не одна? Сроки для апрельского отчёта уже прошли, а консолидировать 5 БД, думаю, за кратчайшие сроки не выйдет.
Россия - ни чего не предусмотрено, но к старту готовы! Девчонок пожалел. Они хотели вообще по новой вбивать и экзамены перепроходить за людей повторно!

И раз уже так много вопросов, почему не одна...
Отвечу: Я эти БД в дампах из других городов получил. Экстрагировал из дампов сами таблицы. Над консолидированной БД уже начал работать.

AkinaПочему не загружать все данные в ОДНУ таблицу? тогда этой темы вообще бы не было (как и решаемой в ней проблемы).

Объясню. ПО уже работает давно. Но спохватились об отчётах в госструктуры только сейчас.
Консалидировать БД процесс не одного дня.
Первое - Конфигурировать БД для разделения принятых записей от филиалов.
Второе - Программировать действительно выгрузку только данных.
(ещё нужно заставить филиалы обновить ПО. Вы хоть раз были в периферии в Сибири? Да местным руководителям чхать на ПО, у них гараж, дача, ребёнок в детском саду - скорость установки обновлений достигает 15-30 дней.)
Третье (да и самое простое) - Запрограммировать разделение выборки при создании отчёта (общий и по филиалам), уже из сконфигурированной под эти нужды центральной БД.
Не знаю, как кто-то, но я за один-два дня такое не напишу. У нас не IT-контора с кучей программеров.
Вот поэтому-то и было принято мной решение пойти кратчайшим путём.
Результат достигнут уже вчера.
-
Вывод: Велосипед не очень эффективное средство передвижение, однако и он, при некоторых обстоятельствах, бывает очень полезен!
Хотя идею на перспективы вы дали хорошую. Но область применения данного ПО не такая уж и плодотворная на реализацию, как идей, так и самого ПО.