|
Как бы лучше работать с Дата/Время?
|
|||
---|---|---|---|
#18+
Как бы лучше работать с Дата/Время? Имеется ввиду ввод, хранение и чтение... До этого использовали только свойства типа %Date... Но теперь нужно и время. Все еще усложняется тем, что данные будут вводить в CSP-страничке, а потом это все будет записываться в DBF-файл. Форматы нужны в итоге такие: ТипФорматДатаДД.ММ.ГГГГВремяЧЧ:ММ:СС ---------- Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2008, 16:55 |
|
Как бы лучше работать с Дата/Время?
|
|||
---|---|---|---|
#18+
Я использую %TimeStamp (поддерживается UTC). Формат даты/времени лучше настроить один раз в локали, например (для версии 2008.2.FT2): Код: plaintext 1. 2. 3. 4. 5. 6. 7.
Код: plaintext 1. 2. 3. 4.
Код: plaintext 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2008, 18:56 |
|
Как бы лучше работать с Дата/Время?
|
|||
---|---|---|---|
#18+
servitЯ использую %TimeStamp Вот что-то и я к нему склоняюсь... Но пока терзают сомнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2008, 08:08 |
|
Как бы лучше работать с Дата/Время?
|
|||
---|---|---|---|
#18+
ИМХО, правильно терзают :) Выбор формата хранения данных в БД в последнюю очередь должен зависеть от формата выходных данных, а в первую очередь - от того, какие запросы будут преобладать. E.g., будет ли поиск по дате и по интервалам дат, будет ли отдельный поиск по времени. Представьте, что у вас будет поиск по дате и по интервалам дат (но не времени), тогда при формате TIMESTAMP время ляжет избыточным бременем на индекс, следовательно, замедлится и скорость. Либо придется делать вычисляемые поля и строить индекс по ним - не головная боль ли это? Это соображения сугубо прагматические, "классиков", возможно, еще покоробило бы, что тип TIMESTAMP противоречит 1НФ. Мы не будем об этом спорить :) Я когда-то тоже мучился подобным выбором, и выбрал раздельное хранение Date и Time (в стандартном формате Cache) именно погоняв запросы, которые на этапе проектирования считались типовыми :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2008, 16:47 |
|
Как бы лучше работать с Дата/Время?
|
|||
---|---|---|---|
#18+
В моем случае запросы "не давят", т.к. табличка будет небольшая... Вот и думаю может потренироваться на ней? Задачка у меня следующая - - Ответственный работник монтирует областную БД - Указывает дату и время ее актуальности - Я провожу некие манипуляции с этой БД с целью получить из нее ряд таблиц - Полученные таблицы записываю в dbf-фалы для отправки в министерство - Для этого "пакета" файлов создается файл "этикетка". В который, помимо всего прочего, нужно записать на какое число и время были актуальны данные. Если сведения не "полные", т.е. шлю не всю информацию, а только "изменения", нужно еще указать дату и время предыдущей актуальности БД, которую отсылали последний раз Отсюда решаю следующие вопросы: - Ввод даты и времени из csp-страницы. Хранение их в неком классе вместе с другими установочными данными - Создание таблички где будет храниться история "актуальностей" обработанных БД Когда в csp делаю привязку объекта к форме даты записываю в формате ММ/ДД/ГГГГ, а время ЧЧ:ММ:СС (это если хранить в разных полях) - все нормально сохраняется. А как выполнить ввод или хотя бы запись в поле с типом %TimeStamp? Т.е. не методом кащейским, а именно через привязку объекта к форме? ---------- Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2008, 08:19 |
|
Как бы лучше работать с Дата/Время?
|
|||
---|---|---|---|
#18+
Alexey MaslovИМХО, правильно терзают :) Выбор формата хранения данных в БД в последнюю очередь должен зависеть от формата выходных данных, а в первую очередь - от того, какие запросы будут преобладать. E.g., будет ли поиск по дате и по интервалам дат, будет ли отдельный поиск по времени. Представьте, что у вас будет поиск по дате и по интервалам дат (но не времени), тогда при формате TIMESTAMP время ляжет избыточным бременем на индекс, следовательно, замедлится и скорость. Либо придется делать вычисляемые поля и строить индекс по ним - не головная боль ли это? Это соображения сугубо прагматические, "классиков", возможно, еще покоробило бы, что тип TIMESTAMP противоречит 1НФ. Мы не будем об этом спорить :) Я когда-то тоже мучился подобным выбором, и выбрал раздельное хранение Date и Time (в стандартном формате Cache) именно погоняв запросы, которые на этапе проектирования считались типовыми :)На DC вышла статья на эту тему: Improve SQL Performance for Date Range Queries Представленный там трюк подходит лишь для частного случая: когда TimeStamp1 < TimeStamp2 if and only if ID1 < ID2 for all IDs and TimeStamp values in table и в запросах учитывается вся отметка (дата/время) целиком. В общем случае целесообразней использовать умные индексы , позволяющие очень быстро искать как по отметке целиком, так и её частям или совокупности частей. Состав подобного индекса со временем может безболезненно дополняться новыми неучтёнными комбинациями. Кроме того в нём можно хранить данные необязательно в отображаемом виде ["2016-07-01"], а например в логическом [64100] для экономии дисковой памяти. При всём при этом отметка хранится именно как %TimeStamp, а не два отдельных поля %Date и %Time. Повторил тест с задействованием "умного" индекса и беспорядочной последовательностью ID: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
PS: у Kyle ошибка в коде: Property Data as %String ( MAXLEN =100, MINLEN =200); ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2016, 12:37 |
|
|
start [/forum/topic.php?fid=39&msg=39277725&tid=1556447]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 139ms |
0 / 0 |