Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Проблема с датами.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
komrad
alexeyvg
'20170101' тоже всегда однозначно распознаётся сервером.

справедливости ради, в данном случае будет неявное преобразование типов в случае сравнения с датой
Да, сиквел хранит как строку, и делает преобразование, так что я погорячился насчёт "константы типа дата".
29 дек 18, 00:19    [21776128]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Посетитель
Member

Откуда:
Сообщений: 1384
Andy_OLAP
alexeyvg
в формате, который всегда однозначно распознаётся сервером, не зависит ни от каких натроек

convert(datetime,...,112) всегда однозначно определяется сервером
alexeyvg
и при этом короткий

Я не понимаю, откуда такая тяга у российских разработчиков. Однострочники perl, компактные выражения. Краткость - сестра таланта. Но мачеха гонорара. Вы же работаете с молодыми, Вы понимаете, кто идет на смену. Или составляете выражения так, чтобы индус, которого разбудили в полночь, понял спросонья, или получаете рано или поздно проблемы.

Не нужно коротко. Нужно понятно.


единственное, что понятно в предложенном вами варианте - это то, что у вас что то с головой.
если преобразование к datetime еще можно хоть как то объяснить с точки зрения отказа от неявных преобразований типов, то конвертация числовой константы в строку может быть оправдана только одним - побуквенной оплатой.
никакой понятности и потребности в этом нет.
29 дек 18, 08:30    [21776189]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Руслан Дамирович
Member

Откуда: Резиновая нерезиновая
Сообщений: 940
Посетитель
...

Да ладно вам ругаться, я вон до сих пор в ORACLE вижу, как пишут TO_DATE('2019/01/01', 'YYYY/MM/DD'), хотя можно просто D'2019-01-01' или DATE'2019-01-01'.
Ну привык он так, в WHERE не смертельно. Вот в SELECT INT -> VARCHAR -> VARCHAR(30) -> DATE может сожрать ему чуть больше памяти. Подумаешь, сервер же не железный - прожует, ну разве что оптимизатор поругается немного...
29 дек 18, 10:10    [21776230]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
iap
Member

Откуда: Москва
Сообщений: 46954
В прежних версиях TSQL была хорошая статья, а теперь вроде и не с стало её...
Использование данных даты и времени
29 дек 18, 10:33    [21776242]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Посетитель
Member

Откуда:
Сообщений: 1384
Руслан Дамирович
Посетитель
...

Да ладно вам ругаться, я вон до сих пор в ORACLE вижу, как пишут TO_DATE('2019/01/01', 'YYYY/MM/DD'), хотя можно просто D'2019-01-01' или DATE'2019-01-01'.
Ну привык он так, в WHERE не смертельно. Вот в SELECT INT -> VARCHAR -> VARCHAR(30) -> DATE может сожрать ему чуть больше памяти. Подумаешь, сервер же не железный - прожует, ну разве что оптимизатор поругается немного...


собственно, как он там у себя привык делать - это сугубо его выбор. ну еще тех, кто с его кодом потом разбираться будет.
мы ему не вправе запрещать писать в привычном ему стиле.

но человек же идет с этим в массы и заявляет, что именно так - правильно и понятно. А остальное - это типа блажь "российских разработчиков"
29 дек 18, 10:47    [21776249]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
invm
Member

Откуда: Москва
Сообщений: 9123
Посетитель,

Не кормите "эксперта", не стоит становиться подопытным кроликом - он специально провоцирует реакцию.
Вот тут озвучены его истинные цели - 21420390 (два последних абзаца)
29 дек 18, 11:05    [21776258]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Руслан Дамирович
Member

Откуда: Резиновая нерезиновая
Сообщений: 940
invm
Посетитель,

Не кормите "эксперта", не стоит становиться подопытным кроликом - он специально провоцирует реакцию.
Вот тут озвучены его истинные цели - 21420390 (два последних абзаца)

Так он икспердов с масквы не любит, мы-то тут при чем?
29 дек 18, 11:23    [21776272]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
Руслан Дамирович
Да ладно вам ругаться, я вон до сих пор в ORACLE вижу, как пишут TO_DATE('2019/01/01', 'YYYY/MM/DD'), хотя можно просто D'2019-01-01' или DATE'2019-01-01'.
Ну привык он так, в WHERE не смертельно
Использование CONVERT в общем объяснимо - привычка всегда видеть название типа ещё хоть как то разумна, хотя и спорна (кто то скажет - избыточна). Но преобразование из числа??? Это уж точно абсурд.
29 дек 18, 15:20    [21776470]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Руслан Дамирович
invm
Посетитель,

Не кормите "эксперта", не стоит становиться подопытным кроликом - он специально провоцирует реакцию.
Вот тут озвучены его истинные цели - 21420390 (два последних абзаца)

Так он икспердов с масквы не любит, мы-то тут при чем?

Да не только. Еще не нравятся индусы из CenturyLink, которые соревнуются, кто быстрее минут за 20 внесет изменения в BGP. Ну просто таки зла не хватает. Впрочем, это все лирика.
30 дек 18, 00:53    [21776748]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Посетитель
Руслан Дамирович
пропущено...

Да ладно вам ругаться, я вон до сих пор в ORACLE вижу, как пишут TO_DATE('2019/01/01', 'YYYY/MM/DD'), хотя можно просто D'2019-01-01' или DATE'2019-01-01'.
Ну привык он так, в WHERE не смертельно. Вот в SELECT INT -> VARCHAR -> VARCHAR(30) -> DATE может сожрать ему чуть больше памяти. Подумаешь, сервер же не железный - прожует, ну разве что оптимизатор поругается немного...


собственно, как он там у себя привык делать - это сугубо его выбор. ну еще тех, кто с его кодом потом разбираться будет.
мы ему не вправе запрещать писать в привычном ему стиле.

но человек же идет с этим в массы и заявляет, что именно так - правильно и понятно. А остальное - это типа блажь "российских разработчиков"

Вы знаете - я думал это просто "пропустить мимо ушей". Ну кто думает и анализирует - тот поймет, кто нет - таки нет. Но решил для Вас специально совсем немного разжевать.

Итак. Почему именно convert(datetime,convert(varchar(8),20170101),112), а не просто convert(datetime,'20170101',112). Почему нужно бить палкой по голове и заставлять писать длинные преобразования.

А вот почему. Иногда нужно сделать так. declare @str nvarchar(MAX)
@str = N'select .......from ...... where date >= convert(datetime,convert(varchar(8),20170101),112)'
exec(@str)

И тут оказывается, что проще сделать так, чем следить, чтобы кавычки были внесены в двойном объеме.

Но даже не это главное. Иногда нужно сделать так:
declare @str nvarchar(MAX)
declare @int1 int
set @int1 = 20170101
set @str = convert(nvarchar(MAX),'select ... from ... where date >= convert(datetime,convert(varchar(8),') + convert(nvarchar(MAX),@int1) + convert(nvarchar(MAX),'),112)')
exec(@str)


Зачем "бить по голове" и заставлять молодежь делать явный " convert(nvarchar(MAX),' " - оставляю за кадром. Пусть каждый думает в меру своей испорченности.
30 дек 18, 00:59    [21776749]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
alexeyvg
Руслан Дамирович
Да ладно вам ругаться, я вон до сих пор в ORACLE вижу, как пишут TO_DATE('2019/01/01', 'YYYY/MM/DD'), хотя можно просто D'2019-01-01' или DATE'2019-01-01'.
Ну привык он так, в WHERE не смертельно
Использование CONVERT в общем объяснимо - привычка всегда видеть название типа ещё хоть как то разумна, хотя и спорна (кто то скажет - избыточна). Но преобразование из числа??? Это уж точно абсурд.

Потому что нужно приучать использовать явную конвертацию и писать длинно, но понятно. И на первом этапе нужно просто заставлять. Потом это будет на уровне автоматизма. И никаких посыпаний головы пеплом и криков "ой-вей, нельзя ли записать все это покороче".
30 дек 18, 01:01    [21776750]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Andy_OLAP
set @str = convert(nvarchar(MAX),'select ... from ... where date >=
...
Зачем "бить по голове" и заставлять молодежь делать явный " convert(nvarchar(MAX),' " - оставляю за кадром. Пусть каждый думает в меру своей испорченности.

И вообще можно заставить делать так. Тоже для педагогического эффекта.
set @str = convert(nvarchar(MAX),N'select ...
30 дек 18, 01:04    [21776754]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
Andy_OLAP
alexeyvg
Использование CONVERT в общем объяснимо - привычка всегда видеть название типа ещё хоть как то разумна, хотя и спорна (кто то скажет - избыточна). Но преобразование из числа??? Это уж точно абсурд.

Потому что нужно приучать использовать явную конвертацию и писать длинно, но понятно.
Преобразовать из числа - это "длинно, но понятно"?
Нужно было ещё несколько арифметических действий сделать, для лучшения конструкции. Типа
convert(datetime,convert(varchar(8),(40340205-3)/2),112)

Это, я думаю, уже ближе к идеалу. Это ещё вдвое повысит профит бизнеса от проекта, и вашу ценность как сертифицированного пастуха стада баранов руководителя команды разработчиков :-)
30 дек 18, 11:01    [21776824]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
Доброго дня суток. Хоть и работаю прогером много лет,но суть такая..у нас на предприятии используется ERP система+запросы на MS SQL. Вообще ,задача простая , есть 2 даты ремонта,где дата начала и дата конца,но дата начала может быть в этом году,а окончиться ремонт в следующем или через следующий и надо найти все ремонты,скажем ,за этот год который проводились или проводятся до сих пор с прошлого года . Т.е
data_begin='20181010' data_end='20200515' 
data_begin='20190101' data_end='20190931'
data_begin='20191109' data_end='20191231'
надо найти все записи,которые включают,нынешний год? По простому ,я думаю так и всё ок...
select * from rem where year(getdate()) between year(data_begin) and year(data_end)
Но суть в том,что наш "оптимизатор" с отдела,говорит,что не комильфо по оптимизации использовать "year",что надо брать начало нынешнего года ,конец нынешнего года и сравнивать эти две даты с "data_begin" и "data_end". Думаю..думаю,но не могу понять..зачем вообще такой геморрой надо делать? А чел при установке релиза будет проверять,думаю.Посоветуйте( возможно,надо как то брать "01.01.2019" и сравнивать с "data_begin" и "data_end",а потом брать "31.12.2019" с тоже сравнивать с "data_begin" и "data_end") . Посоветуйте с кодом..
25 янв 19, 22:01    [21794592]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
Юлик
Но суть в том,что наш "оптимизатор" с отдела,говорит,что не комильфо по оптимизации использовать "year",что надо брать начало нынешнего года ,конец нынешнего года и сравнивать эти две даты с "data_begin" и "data_end". Думаю..думаю,но не могу понять..зачем вообще такой геморрой надо делать?
Правильно говорит, это выглядит отвратительно :-(
Как складывать числа, преобразовав их в картинки и попросив Гугл сложить.
Юлик
Посоветуйте( возможно,надо как то брать "01.01.2019" и сравнивать с "data_begin" и "data_end",а потом брать "31.12.2019" с тоже сравнивать с "data_begin" и "data_end") . Посоветуйте с кодом..

select * 
from rem 
where getdate() >= convert(date, str(year(@data_begin)) + '0101') 
	and getdate() < dateadd(yy, 1, convert(date, str(year(@data_end) + '0101')))
25 янв 19, 22:49    [21794606]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
alexeyvg
Юлик
Посоветуйте( возможно,надо как то брать "01.01.2019" и сравнивать с "data_begin" и "data_end",а потом брать "31.12.2019" с тоже сравнивать с "data_begin" и "data_end") . Посоветуйте с кодом..

select * 
from rem 
where getdate() >= convert(date, str(year(@data_begin)) + '0101') 
	and getdate() < dateadd(yy, 1, convert(date, str(year(@data_end) + '0101')))

хм.. я понимаю,что придется конверт или каст использовать,но..это гемор,для того,что бы просто вывести данные,которые входят в диапазон нынешнего года.P.S не пойму,зачем надо конвертировать дату в варчар и делать такое... если тип данных везде "date"
25 янв 19, 23:26    [21794627]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
Юлик
alexeyvg
пропущено...

select * 
from rem 
where getdate() >= convert(date, str(year(@data_begin)) + '0101') 
	and getdate() < dateadd(yy, 1, convert(date, str(year(@data_end) + '0101')))

хм.. я понимаю,что придется конверт или каст использовать,но..это гемор,для того,что бы просто вывести данные,которые входят в диапазон нынешнего года.P.S не пойму,зачем надо конвертировать дату в варчар и делать такое... если тип данных везде "date" ? или ,по ходу надо уже везде всё в варчар вести? P.S то,что я предложил,я не проверял,это так.. на бумаге,а в реале может выйти другое. Посоветуйте правильно решение найти входящие в диапазон нынешнего года P.S конечно,если это такой запрос для моей задачи..это жесть
25 янв 19, 23:31    [21794630]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
Юлик
Юлик
пропущено...

хм.. я понимаю,что придется конверт или каст использовать,но..это гемор,для того,что бы просто вывести данные,которые входят в диапазон нынешнего года.P.S не пойму,зачем надо конвертировать дату в варчар и делать такое... если тип данных везде "date" ? или ,по ходу надо уже везде всё в варчар вести? P.S то,что я предложил,я не проверял,это так.. на бумаге,а в реале может выйти другое. Посоветуйте правильно решение найти входящие в диапазон нынешнего года P.S конечно,если это такой запрос для моей задачи..это жесть P.P.S интересно,по планам запроса в SSMS это как будет выглядеть? не думаю,что быстрее будет с преобразованиями
25 янв 19, 23:36    [21794631]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
Юлик
alexeyvg
пропущено...

select * 
from rem 
where getdate() >= convert(date, str(year(@data_begin)) + '0101') 
	and getdate() < dateadd(yy, 1, convert(date, str(year(@data_end) + '0101')))


спасибо,проверю по свободке,так как это сейчас на "горит",но,реальный дебилизм преобразовывать,так как по плану запросов сервак сделает по своему. P.S не проверял еще все варианты(которые сам думал),просто другие "задачи" по другим задачам не в этой сфере поставлены,а так,просто, интересовался...
25 янв 19, 23:52    [21794634]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
Юлик,

но , всё же.. то,что я привёл сам в раздумье,это не значит,что это правильно. Задача простая,есть ,скажем,нынешний год и надо вывести все ремонты,которые попадают в этот период ( а период может быть любой,но,когда дата окончания меньше чем нынешний год) .
26 янв 19, 00:18    [21794642]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
Юлик
Юлик,

но , всё же.. то,что я привёл сам в раздумье(когда начало года сравнивается с.. и т.д),это не значит,что это правильно. P.S понятно,что дело надо с конвертами и кастами,но а на план запросов ,думаю,это тоже повлияет? Или,как вы считаете?.
26 янв 19, 00:26    [21794651]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
PizzaPizza
Member

Откуда:
Сообщений: 309
dermama
WHERE p.date <> CAST(DATEPART(year, '2017-01-01') as varchar(20));


однако последний вариант выводит мне все значения, в том числе и те, которые мне не нужны


То есть у вас в таблице дата в виде date eg 2017-01-01
Вы берете целевую дату в формате строки '2017-01-01', вставляете ее в datepart, где происходит неявное преобразование строки в дату и выделение года.
Полученный от datepart год вы опять же преобразуете в строку, причем длиной 20 символов.
И вот эту строку ('2017') теперь сравниваете с date в таблице, которая хранится как 2017-01-01 и при сравнении неявно преобразуется в строку '2017-01-01'

Очевидно строка 2017 не равна строке 2017-хх-хх никогда.
26 янв 19, 01:33    [21794672]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
PizzaPizza
Member

Откуда:
Сообщений: 309
Wow это тут уже новую тему накидали в кучу
26 янв 19, 01:57    [21794681]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
Юлик
но..это гемор,для того,что бы просто вывести данные,которые входят в диапазон нынешнего года.
Вывести данные, которые входят в диапазон нынешнего года, можно и по другому.

Тут главное, что бы сервер смог воспользоваться зараннее сохранённым деревом диапазонов значений (то есть индексом) для быстрого поиска

Юлик
P.S не пойму,зачем надо конвертировать дату в варчар и делать такое... если тип данных везде "date"
Не обязательно в varchar
Просто один из вариантов выделения года, для ваших полей и условий.

А, у вас же data_begin и data_end - это поля?

Тогда да, неправильно.

Юлик
но , всё же.. то,что я привёл сам в раздумье,это не значит,что это правильно. Задача простая,есть ,скажем,нынешний год и надо вывести все ремонты,которые попадают в этот период ( а период может быть любой,но,когда дата окончания меньше чем нынешний год) .

А дата начала тут важна, или как?
"дата окончания меньше чем нынешний год" - то есть дата окончания в прошлом году?

Вы бы сформулировали задачу поточнее.

Может, так надо?
--  data_end меньше, чем 1 января следующего года
select * 
from rem 
where data_end < dateadd(yy, 1, convert(date, str(year(getdate()) + '0101')))
26 янв 19, 10:31    [21794713]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с датами.  [new]
Юлик
Member

Откуда:
Сообщений: 16
alexeyvg
А дата начала тут важна, или как?
"дата окончания меньше чем нынешний год" - то есть дата окончания в прошлом году?

Вы бы сформулировали задачу поточнее.

Может, так надо?
--  data_end меньше, чем 1 января следующего года
select * 
from rem 
where data_end < dateadd(yy, 1, convert(date, str(year(getdate()) + '0101')))

Вообщем, есть куча оборудования,которое ремонтируется, ремонтировалось( с 2014,скажем года) или у которого запланирован ремонт
даты ремонтов:
1 е оборудование: с 10.10.2015 00:00 по 20.12.2015 00:00
2е оборудование: с 11.01.2017 00:00 по 20.11.2018 00:00
3е оборудование: с 10.07.2018 00:00 по 04.09.2019 00:00
4еоборудование: с 22.03.2017 00:00 по 31.12.2021 00:00
5еоборудование: с 31.12.2018 00:00 по 01.01.2019 10:22

Мне надо отобрать данные, у которых ремонт попадает именно на нынешний год,т.е моем случае,это будут 3 , 4 и 5 оборудование. Правда,если месяц отбора данных будет декабрь ,то брать не нынешний год, а следующий( и соответственно,тогда в список попадет только 4 оборудование)
26 янв 19, 11:48    [21794727]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить