@Remmi в вашем случае будут максимум задействованы 2 таблицы. У нас же можно выгрузить отчет за полгода (ограничено функционалом сайта), а то и больше. Не вижу ничего страшного, чтобы дернуть данные из двух таблиц. У вас же не реалтайм онлайн-игра. А разницу в полсекунды в запросах к MySQL вы не заметите. Еще раз повторюсь, выборка занимает мало времени. Больше времени у нас занимает генерация файлов, поэтому стоит специальный "отслеживальщик" его готовности в разделе сайта (то есть пока он не сформируется - пользователь видит лоадер).
Но, возможно не уточнил. У нас можно смотреть отчеты за текущий и прошлый месяц в онлайн. То есть выводится все детально со всеми вытекающими в разделе "Отчеты" на сайте. Если пользователь хочет более ранние отчеты - тогда мы уже собираем ему файлы.
Дык не пойму, причем интервал. Вы знаете, что выборка попадает от такого-то число до другого. Соответственно в курсе тех дат, которые должны присутствовать в запросе. Смотрите что за начальная дата и в какую таблицу попадает и смотрите, что за конечная. Просто пока у вас нет четкой структуры данных архивов отчетов - возникают непонимания. Дата выборки у нас на устоявшейся структуре служит для того, чтобы обратиться к нужной таблице по нужным ключам (у нас - ID партнера и ID проекта). Даты мы не выбираем. Просто в архивной таблице у нас исключена возможность попадания данных из другого месяца. Нужен период - смотрим какие месяца входят. Дергаем по очереди таблицы с именем (год, месяц) с данными по ID, складываем в отчет и запихиваем в архив.
@Remmi тут уже вопрос в другом. Насколько четко у вас структурированы данные, какие индексы на полях по которым ищутся данные и т.п. Еще раз повторю, таблицы у нас немаленькие (~20 млн записей в каждой) - выборка у нас занимает очень мало времени. Больше времени скрипты генерируют файлы и складывают их в архив.
Ну так, а куда вы денетесь, если отчеты надо хранить в любом случае? Что в базе они у вас будут, что на диске в формате csv. В вашем случае такой вопрос целесобразно задать? У вас отчеты постоянно выгружают и действительно они всем нужны и всегда в таком объеме? Просто если вы в этом не уверены - я бы просто так файлы не складывал на диск, а генерировал по запросу.
По вашему пункту 3. Мы так и делаем. Почему архивные таблицы? У нас количество записей в таблице отчетов увеличивалось на ~15-20 млн строк за месяц. Без разделения на месяца мы бы действительно столкнулись с долгой выгрузкой данных и тормозной работой. Данные выбираются из базы (архивных таблиц) напрямую, естественно, за прошлые месяцы. За текущий - из основной таблицы данных.
Я и говорю, что получилось сделать онлайн-сканнер только через такую свистопляску. Мы тоже себе хотели кнопку на рабочий стол "Сделай мне скан и положи вон туда", но как оказалось - проще через сервер.
Через Uploadify можно. Там есть access key и secret key.
Access Key ID—Your Access Key ID identifies you as the party responsible for service requests. You include it in each request, so it's not a secret.
Короче, он не секретен. Secret key для управления букетами нигде не светится, коннект идёт через PHP-файл. В JS он не отображается, а забит в константу в конфиге. Прямая загрузка нужна для того, чтобы не забивать свой сервер промежуточными файлами и не грузить лишними запросами (пересылка на амазон), плюс это сокращает время ожидания пользователем конечной загрузки (то есть фагрузка производится один раз, а не два). В кроне делать не хотелось, хочется реалтайма. В принципе решение уже опробую. Как сделаю — напишу здесь.
UPD: схема такая. Пользователь заходит на сайт, выбирает что загрузить (картинку, к примеру), жмёт кнопку сабмита и выбранный файл загружается напрямую на Amazon ебз промежуточной загрузки на мой сервер.
Но, возможно не уточнил. У нас можно смотреть отчеты за текущий и прошлый месяц в онлайн. То есть выводится все детально со всеми вытекающими в разделе "Отчеты" на сайте. Если пользователь хочет более ранние отчеты - тогда мы уже собираем ему файлы.