2016-03-23 7 views
0

Я работаю над самостоятельным подключением к YoY, чтобы видеть продажи продаж в этом году и в прошлом году в бок о бок в одной таблице.dateadd в Redshift не компенсирует високосный год

Запрос выглядит следующим образом:

Select a.date_column, a.sales_column as ty_sales, b.sales_column as ly_sales 

from sales_table a 

left join sales_table b 

on (dateadd(year, -1, a.date_column)) = b.date_column 

Это в теории должно быть хорошо, проблема заключается в том, что 2016-02-29 записи присоединяются к 2015-03-01 записи, которая вызывает число для выхода на 02-2016.

Это известная проблема с красным смещением/постгревом?

Дайте мне знать, если я могу предоставить дополнительную ясность.

+0

Почему вы отметили этот wih mysql, sql и postgresql, когда он не имеет ничего общего с ними? –

+0

Это вопрос, связанный с SQL, синтаксис postgresql довольно синоним красного смещения и MySQL для видимости. Поскольку есть вероятность, что человек знаком с MySQL, он, вероятно, знаком с postgres/redshift. – masdawg

+0

@masdawg. , , Тег «sql» обеспечивает видимость. Вы должны только тегировать с базой данных, которую вы фактически используете, а не посторонними базами данных. –

ответ

1

Я бы не сказал, что это «известная проблема», так они решили справиться с високосными годами. Когда вы сравниваете 2/29 для YoY, в какой день вы хотели бы сравнить его? Если вы сравните его с 2/28, вы также собираетесь сравнить 2/28 этого года с 2/28 прошлого года? Теперь вы сравниваете два дня с тем же днем. Затем вы должны учитывать возможность двойного подсчета этих продаж с прошлого года, когда вы суммируете все.

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