Текущий архив: 2005.02.20;
Скачать: CL | DM;
ВнизКомпоненты ввода даты в базу данных Найти похожие ветки
← →
stud1 (2005-01-22 21:48) [0]Уважаемые мастера, пожалуйста посоветуйте. В б.д. требуется хранить даты неких событий, которые могут быть в форматах 1990 ("y"), март 1990 ("m.y"), 1.01.2005 ("d.m.y"). Решили "разложить" дату на составляющие и хранить их в отдельных полях. В режитме просмотра дата "собирается". Если в случае "d.m.y" при вводе даты естественно использование обычного календаря, то как быть при вводе по форматам "m.y" и "y"? Посоветуйте, как быть? Спасибо за внимание.
← →
Sergey_Masloff (2005-01-22 22:02) [1]Странное решение. Обычно (в 99.9% случаев) применяется система в которой
1990 = 01.01.1990
март 1990 = 01.03.1990
1.01.2005 = 01.01.2005
ну, вобщем, понятна идея? Можно еще ПОСЛЕДНИЙ день брать но это реже встречается.
← →
stud1 (2005-01-22 22:10) [2]To Sergey_Masloff
Спасибо, но это не совсем то. Речь в конечном итоге идет о составлении мед. документа, например анамнеза заболевания. Зачастую о том, что было 10 лет назад пациент говорит именно так:
"март 1990" и интерпретировать это в документе как 1.03.1990 не совсем корректно.
← →
aus (2005-01-22 22:31) [3]не проще ли в таком случае хранить дату просто в текстовом поле, а то могут последовать такие даты как "конец 1990", "летом 1990".
Или будут какие-то выборки по датам?
← →
stud1 (2005-01-22 22:43) [4]To aus
Спасибо. Выборки по датам, безусловно будут, но только по тем, где формат "d.m.y", например, анализы за период... Что касается предложенных Вами вариантов, то оба они, в нашем случае, должны быть интерпретированы в формате "y" как "1990".
← →
Некто (2005-01-22 23:09) [5]Используй 3 поля в базе данных и 3 эдита для ввода/редактирования значений, про каледарь забудь, либо эдиты, либо маскэдиты. При "сборе" даты анализируй что было введено, а что нет. Иного решения наверно нету.
← →
Sergey_Masloff (2005-01-22 23:32) [6]Все это классно но у меня складывается твердое впечетление о неправильном проектировании. Если поле даты и оно будет анализироваться - там должны быть дата а не март 2000. Если нужно записать март 2000 нужно просто добавить еще одно текстовое поле.
А то получите не данные а свалку мусора (что и происходит в медицинских учреждениях постоянно - я работая в крупной страховой компании много с ними дела имею и картину знаю. И потом у них в базах вместо кода врача написано доктор петров и так далее. Это конечно лирическое отступление не обращайте внимания.)
← →
Anatoly Podgoretsky © (2005-01-23 02:58) [7]stud1 (22.01.05 22:10) [2]
Почему не корректно, вполне нормально что 1.03.1990 так же и 31.03.1990
И для запросов удобно и проблем не будет, как в случае разделнеия одной сущности на три.
← →
aus (2005-01-23 08:31) [8]Sergey_Masloff (22.01.05 23:32) [6]
вместо кода врача написано доктор петров и так далее
Как это все мне близко...)))
← →
stud © (2005-01-24 10:30) [9]анамнез заболевания обычно храниться в блобе где и пишут "где-то 5 лет назад" или "не помню точно но кажется тогда"
а если точная дата не известна, кто мешает вытащить интересующий месяц? к тому же отчет составляется обычно за период т.ч.
> Anatoly Podgoretsky © (23.01.05 2:58) [7][Ответить]
вполне логично
← →
Соловьев © (2005-01-24 11:04) [10]Мне кажется логично будет хранить 2 даты: начало периода и конец. Если пациент знает точно дату, то эти границы совпадают, если нет. то это начало и конец нужного месяца.
← →
Sergey13 © (2005-01-24 11:09) [11]2[10] Соловьев © (24.01.05 11:04)
>Если пациент знает точно дату
А если он помниттолько, что "после войны уже". Или "при Хрущеве". 8-)
← →
Соловьев © (2005-01-24 11:21) [12]можно в проге предусмотреть периоды - после войны, до войны, при Хрущове, Сталине, когда колбаса была по 2.30 8)
← →
Sergey13 © (2005-01-24 11:24) [13]2stud1 (22.01.05 21:48)
>В б.д. требуется хранить даты неких событий, которые могут быть в форматах 1990 ("y"), март 1990 ("m.y"), 1.01.2005 ("d.m.y").
А это правда требуется? ИМХО, тут просто года хатит. Все равно остальная часть даты придумывается.
← →
Danilka © (2005-01-24 11:24) [14]Тогда проще к дате доп. поле - "точность". например, 0 - день, 1 - месяц, 2 - год.
← →
stud © (2005-01-24 12:35) [15]
> Тогда проще к дате доп. поле - "точность". например, 0
> - день, 1 - месяц, 2 - год
проще уточнить ТЗ и предоставить вод даты на усмотрение врача.
интересно как вводить "а в последнее время ( 3-4 мес.)"
анамнез например тут http://5ka.ru/50/10359/1.html
формировать автоматически можно на основании работы своей системы, а то, что было до этого - хранить например в блоб поле. (хотя формировать такую такую вещь автоматически - интересно что получится)
← →
msguns © (2005-01-24 15:22) [16]Похожая петрушка с годами-датами в архивном деле. Но тут решение более-менее найдено. Даты, как таковой, нетути (Вернее, есть даты, но это дата регистрации, передачи или утери документа), а есть год. Точнее, два поля: год начала и конца периода, когда документ был создан (найден, начат и т.д.). Если год известен точно, то второе поле=первому. Если год не известен, то в поле примечаний пишется век или диапазон веков.
Причем в БД есть строгое разделение годов: это дата самого документа и период, охватываемый этим документом. Например, том ревизской сказки был начат в таком-то году и охватывает такой-то период.
Т.е. надо разделять все же эти самые "даты" по смысловой и хронологической "нагрузке". Впихать все в одну систему (период, например) категорически нельзя !
Применительно к медкартотеке я бы померкувал над такой системой хронологии:
1.Дата для конкретной записи в конкретном документе (т.е.имеется сам документ)
2.Период для отслеживания истории болезни, который может состоять из двух граничных "дат", каждая из которых представлена годом и месяцем (не обязательно). Ну и для унификации поиска ввел бы специальное поле-признак, где бы указывал тип второй "даты": период в годах, период в месяцах и т.д.
Страницы: 1 вся ветка
Текущий архив: 2005.02.20;
Скачать: CL | DM;
Память: 0.49 MB
Время: 0.035 c