Нужно формировать отчеты за каждый месяц; соответственно создал один выпадающий список для месяца, другой для года. Нужно заполнять эти списки в соответствии с данными в таблице. Например, если есть записи в 2011 за все месяцы, а в 2012 только за январь, то во списке годов должны содержаться значения 2011 и 2012, а при выборе 2012 в выпадающем списке месяцев будет только Январь.
Мысли:
А) Одна основная таблица, в ней поле Date. Списки заполняем SQL-запросом, который пробегается по всем записям, вычленяет из них год и месяц и возвращает уникальные строки.
Б) Тоже самое, что и вариант А, только дата хранится не в одной ячейке, а в 3-х (день, месяц, год).
В) Одна основная таблица, в ней поле Date. Отказаться от списков год и месяц, а сделать периоды дат, выбираемые в календаре. Минус данного подхода в том, что пользователю нужны только отчеты по месяцам, и заставлять его каждый раз выбирать период с 1 января по 31 января не очень хорошо.
В) В каждом новом году создается новая таблица (напр. tablename2011, tablename2012). Список годов составлять по именам таблиц, а месяцами можно пренебречь и заполнить список с Января по Декабрь для любого года (в принципе можно пренебречь и годом, сделав его не списком, а как отображение текущего года + кнопки "назад" и "вперед" увеличивающие или уменьшающие значение
). Здесь лишняя накладка может быть в том, что таблица связана с другой и при попытке удаления записи из второй таблицы, должна выполниться проверка, есть ли связанные записи в tablename2011 и tablename2012 и т.д.Д) Создать отдельную таблицу в которой будут хранится Год-Месяц и при добавлении новых записей в основную таблицу, добавлять новые года-месяца в эту. Вроде бы самый оптимальный вариант.
Может есть ещё у кого какие интересные варианты? Ещё интересует, как думаете, как SQLite справится с миллионом записей? Есть смысл создавать отдельную таблицу на каждый год?
Спустя 7 минут, 49 секунд (24.11.2011 - 06:41) bulgakov написал(а):
Наверное следовало бы использовать что-то более подходящее для таких объемов, тот же mysql. Хотя попробуйте, можно хотя бы протестировать, добавить несколько миллионов случайных записей в таблицу и попробовать их оттуда подергать. Но все таки не думаю что SQLite заточена под такие объемы.
Спустя 28 минут, 23 секунды (24.11.2011 - 07:09) Rand написал(а):
Я достаточно долго выбирал, пока что остановился на SQLite - многопользовательность мне не нужна, особо сложных запросов нет. ОЧЕНЬ желательно, чтобы БД была встраиваемая, а не как сервер. Тесты буду проводить, после того, как определюсь со структурой, если ничего не получится - поменять не проблема, архитектура приложения позволяет.
Добавлено: Извините, с количеством записей я переборщил, недавно вернулся к проекту, и почему-то был уверен, что там миллион , сейчас пересчитал максимальное количество записей в год 100 тыс. На деле около 45тыс. ))
Добавлено: Извините, с количеством записей я переборщил, недавно вернулся к проекту, и почему-то был уверен, что там миллион
, сейчас пересчитал максимальное количество записей в год 100 тыс. На деле около 45тыс. ))