White Owl
Подобную задачу можно в принципе решить вот так:


Ей-ей, что за ужасы вы рассказываете. Достаточно поменять формат хранения времени с интервала ('00:01:02') на секунды ('00:01:02' = 62) и задача решается тривиально и без проблем с производительностью. В текущем варианте возникнут проблемы, например, при биллинговании только тех звонков, которые превышают нетарифицируемый интервал.

Bingo_BongoОчень интересно. Значит я ввелся в заблуждение когда оформлял базу в SQLiteadmin'e там предлагают именно типы данных DATE и TIME. Тогда конечно лучше забивать время в секундах. Только как выводить его потом в нормальном для пользователя виде(%H:%M:%S) через SELECT разумеется?

Проще всего забиндить пользовательскую функцию, которая преобразует время для отображения:


Пример на тикле, но тоже самое можно сделать на любом языке.

White OwlMBGПроще всего забиндить пользовательскую функцию, которая преобразует время для отображения:А еще проще будет почитать список предопределенных функций: strftime(), time(), date(), datetime()... Они очень даже мощные :)

В формат оракла и из формата оракла тем не менее проще преобразовывать пользовательской функцией. При желании форматировать, например, в виде "1 минута 5 секунд" - тоже. Не стоит забывать, что возможности встраиваемой СУБД легко расширяются функциями приложения.

White OwlMBGВ формат оракла и из формата оракла тем не менее проще преобразовывать пользовательской функцией.
Уточните пожалуйста что такое "формат оракла" и зачем в него преобразовывать при работе с sqlite?

Даты вида 1-APR-05, полученные при выгрузке из оракла. Преобразовывать понятно зачем - для оптимизации запросов по этим данным. Например, есть месячная выгрузка из биллинга, кидаем ее в эскулайт на отдельный сервер и пользователи могут строить любые отчеты в любом количестве, не перегружая основной биллинг. Благо сложные объединения таблиц эскулайт выполняет блестяще и данные хранит весьма компактно.

White OwlMBGПри желании форматировать, например, в виде "1 минута 5 секунд" - тоже.
И никаких пользовательских функций :)

И как при необходимости сменить форматирование вы поступите - будете по всему коду искать и заменять этот паттерн? Лучше создать функцию reportview для отображения даты в отчетах, к примеру, и вызывать ее во всех отчетах, тогда изменение формата отображения времени в отчетах потребует модификацию одной лишь функции.

White OwlДва пункта:
- Формат представления даты для пользователя это чисто клиентская задача. И решать ее в любом случае будет ГУЙ. Движку БД клиентский формат данных глубоко по барабану, лично я с датами в БД работаю только в одном формате - yyyy-mm-dd. Все остальные форматы - известны только ГУЮ.
- Ни разу не встречал задачу в которой по настоящему пришлось бы заниматься сменой формата даты. Если программа изначально готовится для международного рынка, значит i18n и подобные ему словари закладываются еще при старте проекта. И опять таки - язык приложения это чисто ГУЕвая задача. БД, будь она хоть трижды встраиваемой с форматами даты никак взаимодействовать не должна. Иначе при смене локали для ГУЯ старая база либо не сможет работать совсем, либо серьезно затормозиться потому что теперь ей прийдется тратить время на вызов каких-то внешний процедур коневертации данных.

Стандартная ситуация - приложение генерит sql-запрос, который потом автоматически мапится в отчет. Никакой дополнительной обработки не нужно, есть прямое соответствие таблица результата запроса - таблица/график/etc. отчета. Формат хранения даты в базе стандартный, секунды с начала эпохи юникс, а вот отображаться дата может в самом различном виде. Например, пользователи могут попросить, чтобы временной интервал меньше 3-х минут отображался как строка "отлично", до 10-ти минут - как "хорошо", и свыше этого - как "удовлетворительно". Базу менять не надо, приложение менять не надо, достаточно лишь изменить содержимое функции отображения даты. Раз мы можем функции приложения и СУБД запустить в едином адресном пространстве, не нужно делать дополнительную обработку после проведения выборки.