Комментарии 9
select distinct tt.supplier as supplier
from test_supply tt
union all
select 'total_sum'
order by supplierЭто неправильный вариант, т.к. после сортировки total_sum может оказаться в любом месте списка. Необходимо делать отдельную сортировку по supplier в подзапросе запроса стоящего перед union all.
А еще использование int8 для сумм вместо bigint — очень сомнительное решение.
Да, вы правы (я поменял оба пункта в статье). На счет типа данных: для этих тестовых данных достаточно int8 (хотя на практике действительно почти всегда будет нужен bigint).
Bigint и int8 — это ведь одно и то же. Или в какой-то базе это не так?
Выражусь точнее: для тестов всё равно. Но naming convention в PosgreSQL (о котором шла речь) предполагает использование именно bigint, поэтому на практике лучше всегда писать именно так
Просто чуть выше автор топил отказ от использования вендор-специфичных фич (filter в postgresql/sqlite, хотя, честно говоря, он удобен своей выразительностью и не вижу причин не использовать его в проектах, завязанных на PostgreSQL, в которых БД — не просто хранилище), а тут использует int8 вместо стандартного bigint.
Кстати, само название типов в postgresql по количеству байт (а не бит, как принято в большинстве ЯП) мне кажется сомнительным решением. Я первоначально перепутал, чем был вызван слишком категоричный тон замечания про int8.
Кстати, само название типов в postgresql по количеству байт (а не бит, как принято в большинстве ЯП) мне кажется сомнительным решением. Я первоначально перепутал, чем был вызван слишком категоричный тон замечания про int8.
На редкость приятная и полезная статья!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сводные таблицы в SQL