Уважаемые эксперты подскажите пожалуйста, как правильно хранить даты в базе, если дата может быть неполной. Например календарь выхода чего либо. Мы не всегда знаем точную дату выхода, иногда только месяц и год, иногда только квартал и год и т.д
Вот пример как надо хранить:
Первая строка содержит (месяц-год), вторая строка содержит точную дату (день-месяц-год), третья содержит (квартал-год), и последняя только (год).
Как все это правильно хранить и потом работать, правильно сортировать и выводить? Я использую 4 разных поля (дата, месяц, квартал, год) но что-то мне подсказывает что есть способ более логичный и правильный.
Для правильного вопроса надо знать половину ответа
Два поля - `date` и `estimation`. Второе поле - enum('date', 'month', 'quarter', 'year'). В первое поле вписывается точная дата или последняя дата соответствующего интервала. Тогда сортировка ORDER BY (`date`, `estimation`) выдаст в оптимальном порядке. Ну и для красоты останется сделать преобразование даты в соответствующий интервал.
apptimeru: Просто в коде выводить не просто дату, а если `estimation` == 'month', то писать 'декабрь 2016', если 'quarter', то '4 квартал 2016', 'year' - '2016 год'.
Rsa97: А ну да это понятно, спасибо за вашу помощь, благодаря этому удалось сократить базу на целых 2 поля) И еще один смежный вопрос если позволите, как лучше сделать табличку например со смартфоном, там куча полей под характеристики надо, и не всегда они все известны. Как лучше с точки зрения оптимизации, создать в таблице все поля, и просто не заполнять некоторые, или создать основные поля, и все характеристики отдельными строками в другую таблицу? но с другой стороны так в другой таблице будет по 8-10 строк для каждого смартфона, и если их будет например 1000шт, то во второй таблице будет как минимум 8000 строк) Вот не знаю как лучше сделать
apptimeru: Под характеристики, чаще всего, заводится достаточно сложная структура.
Первая таблица - это список возможных характеристик (id_характеристики, название, тип, единица_измерения), где тип - 'строка', 'число', 'вариант' или 'мультивариант'.
Вторая - варианты характеристик для типов 'вариант' и 'мультивариант' (id_характеристики, id_варианта, название).
Третья таблица - применимость характеристик (id_характеристики, id_группы_товаров, обязательная).
И, собственно, таблица характеристик (id_товара, id_характеристики, значение), где значение может быть, в том числе, и списком вариантов.
За счёт сложности структуры можно потом строить сложные фильтры для поиска по характеристикам.
Если не хочешь быть первым - не вставай в очередь!
С учётом сущности "квартал" - вряд ли получиться логичней, не припоминаю ни одного готового формата/стандарта даты в БД, где было бы поле "квартал", если только свой составной тип сделать, но такой фунционал "из коробки" в MySQL отсутствует и вряд ли так вот просто получиться в MySQL его "вкрутить".
Единственный вариант, который приходит мне в голову - изобрести свой формат даты на основе поля CHAR/VARCHAR, типа ГОД-КВАРТАЛ-МЕСЯЦ-ДЕНЬ, и пустые значения соотв. заполнять нулями, так по крайней мере будет какой-то намёк на корректную сортировку.
Средний
