Здравствуйте, уважаемые формучане :)

Вот встал передо мной вопрос, как наиболее "гуманно" реализовать хранение даты. Все бы ничего, если бы не специфичность задачи.
А специфика ее вот в чем: необходимо реализовать хранение дат написания литературных произведений. А это значит, что охват происходит от 2000 лет до н.э и по сей день. Порывшись в документации MySQL, я нашел информацию, что поле DATE хранит диапазоны значений от 1000-01-01 до 9999-12-31, что не охватывает необходимый диапазон. При этом не все даты лит. произведений известны точно, а некоторые и вовсе неизвестны. Например "Беовульф" был создан между 8-м и 10- веками.
И еще один очень важный момент: по датам будут происходить всевозможные выборки. Вот.

Немного пораскинув мозгами я пришел к следующей схеме со своими минусами: в таблице books будет поле типа DATE , которое будет хранить даты произведений, написанных в период от 1000 года по сегодняшний день. Если поле заполненно нулями (0000-00-00), то дата написания неизвестна. Если поле заполнено значением NULL , то дата просто не была введена для этого произведения.
Для произведений, написанных раньше 1000 года, сделаем еще одно поле типа SMALLINT , для хранения годов (месяцы и дни здесь уже не нужны, ибо они неизвестны у таких старых произведений). А для того, чтобы реализовать хранение диапазона дат, придется добавить еще одно поле SMALLINT , и при считывании данных проверять его существование. Если оно существует, то речь идет о неточной дате произведения.

Вот собственно и все, что мне пришло в голову. Мне такой вариант абсолютно не нравится, но другой придумать я не смог.
Буду очень благодарен, за любую полезную информацию или наводку.

murtukov,

причина, по которой я не хочу хранить даты в UNIX-формате - это не очень гибкая выборка данных. Ну, по крайней мере я так слышал. Своего опыта с этим у меня не так много. Если я не прав, буду рад быть переубежденным)

tanglirПо-моему, нормально у вас получилось. Только я бы туда в случае с известной неточной датой записывал ту же самую дату. Имхо так искать проще.
Возможно вы опечатались и хотели написать "в случае с известной ТОЧНОЙ датой". То есть, насколько я понял, если известна точная дата, как например 17 апрела 1987, то в обоих полях хранить значение 1987-04-17. При извлечении сравнивать значения, и если они равны, значит известна точная дата написания.
Но в таком случае у меня возникают вопросы:
- Почему так искать проще?
- Не лучше ли хранить NULL, чтобы не занимать лишнюю память?
- Стоит ли вообще выделять отдельное поле для этого, ведь произведений с неточной датой единцы. Я думаю второе поле для интервала будет в 99% случаев NULL (ну или таким же как первое, по вашему совету).
tanglirPS. Уверены, что у вас не будет произведений с периодом, который будет задаваться точными датами? :)
Не уверен :D Просто мне не известны современные произведения, у которых известна только примерная дата написания.

Кстати, поле DATE у меня прекрасно хранит диапазон значений от 0000-00-00 до 9999-12-31. И прекрасно отображается. Функции тоже прекрасно работаю. Отрывок из документации:

Документация MySQLПоддерживается диапазон величин от '1000-01-01 00:00:00' до '9999-12-31 23:59:59'.(''поддерживается'' означает, что хотя величины с более ранними временными значениями, возможно, тоже будут работать, но нет гарантии того, что они будут правильно храниться и отображаться).
Так вот вопрос: стоит ли хранить в типе DATE Значения раньше чем 1000-01-01? Чем это чревато?

Akina,

AkinaПервый вывод из описания - для хранения требуется два поля. Если известен период - храним начало и конец, если точная дата - оба поля заполняем одним и тем же значением (можно и NULL, но усложнится поиск).

Почему поиск усложнится?

Akina,

понял, спасибо. А как же быть с датами до нашэй эры? Получается, надо 4 поля сделать: 2 для диапазона DATE и 2 для более ранних периодов. А не лучше ли вынести старые книги в отдельную таблицу, чтобы не создавать 4 поля, 2 из которых точно будут пустыми?

AkinamurtukovА как же быть с датами до нашэй эры?Отрицательный год :)

Тип DATE ведь не поддерживает отрицательных значений. Что вы имеете ввиду?

Arhat109murtukov,

А не проще принять для клиента двоично-десятичный формат даты в японском стиле (ГГГГММДД) и хранить 2 числа для диапазонов в десятичном формате? Там вроде как до 64 цифр и есть знак для "до н.э"?
Звучит заманчиво, но как это осуществить? Что за двоично-десятичный формат? Какого типа должно быть поле?

Спасибо всем за ценные советы и почву для размышлений.
Отдельное спасибо MasterZiv, думаю так и буду делать.