Форум: "Базы";
Текущий архив: 2006.11.05;
Скачать: [xml.tar.bz2];
Внизкак сделать ввод дат "до н.э." Найти похожие ветки
← →
angelsaint (2006-09-08 10:56) [0]Доброго времени суток!
Проблема такая: Нужно написать прогу для архива. В некоторых документах есть поля дат, отражающие, например, когда было сделано каменное орудие труда. Оракл позволяет вводить год в диапазоне от -4713 до 9999. А если нужно ввести например дату, которая находится дальше чем 30 000 лет до н.э? Также нужно производить поиск. К примеру вводят диапазон от "20000 лет до н.э" до "12.10.2005" и нужно чтобы все документы попадающие в этот диапазон находились. Даты могут приходить в архив как в формате "01.01.2005" (или 12.11.1501 - 01.01.1800), так и в формате XVI - IX вв.
Посоветуйте как организовать ввод и поиск данных?
← →
isasa © (2006-09-08 11:06) [1]На мой взгляд, лучше не связываться, а хранить "as is". Подумать только над тем, как сортировать, выбирать и прочее.
У гуманоидов(историков, в частности :) ) в датировках болный бардак...
II тыс. до н.э., IV век до. н.э., вторая половина IX века.
Я как-то читал ТЗ по разработке системы паспортизации единиц хранения в музее. Вот там историки на датах отдохнули. :)
← →
Desdechado © (2006-09-08 11:22) [2]Как вариант.
Хранить отдельно (в разных полях) век (с минусом - до .н.э.), диапазон лет в веке (для случаев - 3-я четверть 10 века или вторая половина 11 века или конец 20 века, если известен год точно, то конец диапазона равен началу или пустой), месяц, день, время.
Некоторые из полей могут быть не заполнены. Например, известен только век или век+год.
А способ отображения можно сделать настраиваемым.
Если уж очень запредельные даты и веками мерить не удобно, можно добавить тысячелетия и т.д.
← →
angelsaint (2006-09-08 12:17) [3]спасибо за советы
← →
ANB © (2006-09-08 13:12) [4]
> angelsaint (08.09.06 12:17) [3]
Свой тип создай и изгаляйся.
← →
Соловьев © (2006-09-08 14:08) [5]Дата - это целое число, кол-во дней от точки отсчета: + после, - перед. Все остальное дело реализации и как работать на клиенте с таким типом. можно класс создать свой, можно и не заморачиваться.
ЗЫ Лично для меня было шоком то что даже FireBird может нормально хранить нижние границы дат, тогда как промышленная СУБД MS SQL 2000 только до 1753 года
← →
ANB © (2006-09-08 14:21) [6]Упс. Подеркал оракл - тоже хрен на рыло :
08.09.1606 - ввелось
08.09.1599 - заменилось на текущий год.
← →
ANB © (2006-09-08 14:24) [7]Вру :
select to_date("01.01.0001", "DD.MM.YYYY") from dual - прекрасно работает
← →
ANB © (2006-09-08 14:25) [8]Вот только вот так
select to_date("01.01.0001", "DD.MM.YYYY") - 3650 from dual
ораклу уже клинит.
← →
Desdechado © (2006-09-08 15:57) [9]ANB © (08.09.06 14:25) [8]
из справки 9.2
Oracle can store dates in the Julian era, ranging from January 1, 4712 BCE through
December 31, 4712 CE (Common Era). Unless BCE ("BC" in the formatmask) is
specifically used, CE date entries are the default.
← →
isasa © (2006-09-08 19:11) [10]В контексте ветки речь идет не о дате, а о датировке.
В некоторых документах есть поля дат, отражающие, например, когда было сделано каменное орудие труда.
Датировка предмета - это период. В интерпретации историков - период, с произвольной записью.
Например можно написать "2 тысячелетие до н.э.", а можно "II тысячелетие до н.э.". "вторая половина XVIII в." - "вторая половина 18в." ?
← →
Shaman_ © (2006-09-10 19:40) [11]Я бы в таком случае хранил дату в виде диапазона:
вторая половина XVIII в. это - 1850-1900 г.
II тысячелетие до н.э. это (-2000)-(-2000) г.
Тоесть определить в клиентской части все возможные методы задания дат и написать алгоритм приводящий эти абстрактные формулировки к четкому диапазону. Сделать выборку из такой структуры не составит труда
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2006.11.05;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.045 c