Собсвенно необходимо в запросе select отформатировать колонку типа datetime как мне надо.
нашол только такой способ:
select rtrim(year(getdate())) + '-' + right('0' + rtrim(day(getdate())),2) + '-' + right('0' + rtrim(month(getdate())),2)
неужели нету функции котороя бы принимала строку форматирования?
Здравствуйте, pumpurumer, Вы писали:
P>Собсвенно необходимо в запросе select отформатировать колонку типа datetime как мне надо. P>нашол только такой способ: P>select rtrim(year(getdate())) + '-' + right('0' + rtrim(day(getdate())),2) + '-' + right('0' + rtrim(month(getdate())),2) P>неужели нету функции котороя бы принимала строку форматирования?
для случаев встречавшихся мне, находилось такое N, что CONVERT( varchar(88), getdate(), N ) выдавал нужное... неужели надо именно YYYY-DD-MM ???
P>неужели нету функции котороя бы принимала строку форматирования?
Есть. Но только из стандартного набора.
По идее ничего не мешает прицепить любую CLR функцию для таких нужд. Так что идея не засорять код сиквела такой функциональностью в принципе верна.
Здравствуйте, VGn, Вы писали:
P>>неужели нету функции котороя бы принимала строку форматирования?
VGn>Есть. Но только из стандартного набора. VGn>По идее ничего не мешает прицепить любую CLR функцию для таких нужд. Так что идея не засорять код сиквела такой функциональностью в принципе верна.
Совершенно правильно на мой взгляд замечено про засорение сиквела. Сервер баз данных должен заниматься хранением и обработкой данных, а не их форматированием. Это задача более верхних уровней приложения.
Здравствуйте, igor_ku, Вы писали:
_>Здравствуйте, VGn, Вы писали:
P>>>неужели нету функции котороя бы принимала строку форматирования?
VGn>>Есть. Но только из стандартного набора. VGn>>По идее ничего не мешает прицепить любую CLR функцию для таких нужд. Так что идея не засорять код сиквела такой функциональностью в принципе верна.
_>Совершенно правильно на мой взгляд замечено про засорение сиквела. Сервер баз данных должен заниматься хранением и обработкой данных, а не их форматированием. Это задача более верхних уровней приложения.
Ерунда. Например в Oracle есть замечательная функция to_char, позволяющая очень гибко преобразовывать дату/время (и не только) в практически любое строковое представление.
Она ничего не засоряет, а наоборот делает код ясным и понятным:
Здравствуйте, Овощ, Вы писали:
О>Ерунда. Например в Oracle есть замечательная функция to_char, позволяющая очень гибко преобразовывать дату/время (и не только) в практически любое строковое представление. О>Она ничего не засоряет, а наоборот делает код ясным и понятным: О>
О>select to_char(sysdate, 'YYYY-DD-MM') from dual
О>
И эта ф-ция, как и любая другая inline в select, должна дёргаться для каждой строки возвращаемой запросом. Если строк 1М+ то имхо аффект на CPU utilization. И это только ради форматирования, т.е. привидения к "красивому" виду. Плюс, таким запросом можно загробить использование индекса, если таковой есть.
Остаюсь при своём мнении: наведение "красоты" — занятие не для самого нижнего уровня приложения, т.е. сервера БД.
Хотя, по большому счёту, каждый отдельный случай надо рассматривать в отдельности — it depends on..
pumpurumer пишет:
> Собсвенно необходимо в запросе select отформатировать колонку типа > datetime как мне надо. > нашол только такой способ: > select rtrim(year(getdate())) + '-' + right('0' + > rtrim(day(getdate())),2) + '-' + right('0' + rtrim(month(getdate())),2) > неужели нету функции котороя бы принимала строку форматирования?
Не надо форматировать данные в запросе. Это -- дело клиента,
это можно и нужно делать на клиенте.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _d_m_, Вы писали:
___>>Нет. S>Таким — нельзя. S>Зато вот таким — можно: S>
S>select to_char(OrderDate, 'YYYY-DD-MM') from orders where to_char(OrderDate, 'YYYY-DD-MM') like '2008%'
S>
S>А ведь это такое искушение — сделать фильтр после проекции.
При необходимости можно создать function based index.
(Создаем fbi-индекс orders_i1 и затем в плане запроса видим, что оракл может его использовать для вышеприведенного запроса)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Aug 25 11:26:54 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> create table orders(OrderDate date);
Table created.
SQL> create index orders_i1 on orders(to_char(OrderDate, 'YYYY-DD-MM'));
Index created.
SQL> insert into orders select sysdate from dual connect by level <= 100;
100 rows created.
SQL> explain plan for select/*+ index(orders orders_i1) */
2 to_char(OrderDate, 'YYYY-DD-MM') from orders where to_char(OrderDate, 'YYYY-DD-MM') like '2008%';
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------Plan hash value: 3207212940
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 9 | 2 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| ORDERS_I1 | 1 | 9 | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access(TO_CHAR(INTERNAL_FUNCTION("ORDERDATE"),'YYYY-DD-MM') LIKE '2008%')
filter(TO_CHAR(INTERNAL_FUNCTION("ORDERDATE"),'YYYY-DD-MM') LIKE '2008%')
Note
-----
- dynamic sampling used for this statement
20 rows selected.
В MS SQL Server наверняка тоже должна быть подобная функциональность.
А вот это — случайно не хинт? SQL>> explain plan for select /*+ index(orders orders_i1) */ <------- !!! О> 2 to_char(OrderDate, 'YYYY-DD-MM') from orders where to_char(OrderDate, 'YYYY-DD-MM') like '2008%';
Если хинт, то с тем же успехом можно было просто подпатчить where для использования OrderDate between.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Овощ, Вы писали:
S>А вот это — случайно не хинт? SQL>>> explain plan for select /*+ index(orders orders_i1) */ <------- !!! О>> 2 to_char(OrderDate, 'YYYY-DD-MM') from orders where to_char(OrderDate, 'YYYY-DD-MM') like '2008%'; S>Если хинт, то с тем же успехом можно было просто подпатчить where для использования OrderDate between.
Да, это хинт. Но я его использовал просто для упрощения и наглядности примера. Иначе надо думать над распределением данных (чтобы для оптимизатора вообще использование какого-либо индекса имело смысл, и соответственно усложнить процедуру наполнения тестовой таблицы данными) + собрать статистику по таблице.
Конкретно для использования FBI-индекса ни этот ни какой-либо другой хинт не нужен. Их вообще можно создавать совершенно прозрачно для самих запросов в которых они будут использоваться (оптимизатор их сам найдет, оценит, и если ему понравится — то использует).
О>Ерунда. Например в Oracle есть замечательная функция to_char, позволяющая очень гибко преобразовывать дату/время (и не только) в практически любое строковое представление. О>Она ничего не засоряет, а наоборот делает код ясным и понятным: О>
О>select to_char(sysdate, 'YYYY-DD-MM') from dual
О>
Вполне возможно, что тут накладывается способ хранения даты в оракле, позволяющий собственной процедурой форматировать её быстрее, чем UDF. Но не вижу в этом особого плюса. В отличие от функциональных индексов. А им в принципе не должно быть важно откуда функция взялась.
Здравствуйте, SHEMA, Вы писали: SHE>А если стоит задача, к примеру, сгруппировать данные по месяцам, как здесь обойтись без форматирования даты (поле timestamp)?
1. Поле timestamp в T-SQL никакого отношения к месяцам не имеет. http://msdn.microsoft.com/en-us/library/ms182776.aspx
2. Если речь про datetime, то надо пользоваться функцией DatePart.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair пишет:
> SHE>А если стоит задача, к примеру, сгруппировать данные по месяцам, как > здесь обойтись без форматирования даты (поле timestamp)? > 1. Поле timestamp в T-SQL никакого отношения к месяцам не имеет. > http://msdn.microsoft.com/en-us/library/ms182776.aspx
timestamp-ом в стандатре SQL называется тип datetime.
> 2. Если речь про datetime, то надо пользоваться функцией DatePart. > ... << RSDN@Home 1.2.0 alpha rev. 677>>
Здравствуйте, MasterZiv, Вы писали:
MZ>timestamp-ом в стандатре SQL называется тип datetime.
Да, здесь косяк MS SQL — явное противоречие стандарту. Но не убирают из-за обратной совместимости.
По идее это синоним типа rowversion, но дизайнер таблиц Management Studio упорно не хочет воспринимать rowversion почему-то
