#sql #firebird
Вопрос:
У меня есть логическая проблема для вычисления конечного значения этой таблицы:
https://i.stack.imgur.com/YPXXX.png
Мне нужно рассчитать для каждой строки со столбцом TIPO
, имеющим значение «E» 1, и для «S» -1, группируя по столбцам Codigo
и Configuracao
.
В принципе, мне нужен простой контроль запасов, столбцы Codigo
и Configuracao
контроль столбцов продукта, а TIPO
также тип перемещения, S = ВЫХОД и E = ВХОД
Кто-нибудь может дать мне прикурить?
Ответ №1:
непроверено, но, может быть, это
select SUM(t1.TipoNumeric), t1.CODIGO, t1.CONFIGURACAO from (
select
case (TIPO)
when 'E' then 1
when 'S' then -1
else 0
end as TipoNumeric,
CODIGO,
CONFIGURACAO
from MyTable
) as t1
group by t1.CODIGO, t1.CONFIGURACAO
Комментарии:
1. Удивительный Ранд Рэндом, много чего за помощь
2. Нет необходимости в производной таблице: вы можете переместить
CASE
ее вSUM
.3. @MarkRotteveel — не был уверен в этом, думал, что он будет жаловаться, что ТИПО нужно быть в групповом предложении.
4. Нет, потому
TIPO
что внутриSUM
этого не должно произойти.
Ответ №2:
Просто добавьте этот столбец 1/-1, возможно?
alter table MyTable
add tipo_val computed by
(
decode( upper(TIPO), 'E', 1, 'S', -1 )
)
- https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref25/firebird-25-language-reference.html#fblangref25-ddl-tbl
- https://www.firebirdsql.org/refdocs/langrefupd21-intfunc-decode.html
И затем:
Select * from MyTable;
Select SUM(tipo_val), CODIGO, CONFIGURACAO
From MyTable
Group by 2, 3
P.S. не используйте фотографии для отображения ваших данных.
Вместо этого поставьте их на http://dbfiddle.uk/?rdbms=firebird_3.0 в качестве сценария, а затем используйте экспорт Markdown, чтобы скопировать данные и гиперссылку в текст вашего вопроса.
P. P. S. Я считаю, что весь ваш подход здесь неправильный, если «нужен простой контроль запасов».
- https://en.wikipedia.org/wiki/Double-entry_bookkeeping
- https://medium.com/@RobertKhou/double-entry-accounting-in-a-relational-database-2b7838a5d7f8
Я думаю, что в вашей таблице должны быть такие столбцы:
- идентификатор суррогатной строки,
primary key
, автоматически увеличивающееся целое число, 32-разрядное или 64-разрядное - столбцы, идентифицирующие ваш товар, обычно это, опять же, один суррогатный целочисленный артикул (Единица хранения запасов), ссылающийся (см. — Внешние ключи) на другую «таблицу словаря». В вашем случае это, похоже, две колонки
Codigo
,Configuracao
но это также означает, что вы не можете добавлять дополнительную информацию («атрибуты») о ваших товарах, например, цену или фотографию (читай: нормализация базы данных). Это также усложняет группировку для движка Firebird, чем использование одного целого столбца. Кроме того, вы создалиindex
столбец(столбцы), идентифицирующие элементы, не так ли? Каков ваш план запроса для этих выборок, используют ли они индекс наCodigo
иConfiguracao
или вместо этого специальная внешняя сортировка? - операции
timestamp
, которая автоматически устанавливается сервером Firebirdcurrent_timestamp
, чтобы вы всегда знали, когда именно была вставлена эта строка. Индексируется, конечно. - пользователь компьютера, который добавил эту строку, снова автоматически устанавливает сервером Firebird
current_user
идентификатор пользователя в какой-либоstock_workers
таблице, которую вы создадите. Конечно, индексируется тоже. - какое-нибудь описание операции, например номер контракта или имя продавца, все, что поможет вам позже вспомнить, какое событие в реальном мире даже описывается в этой строке. Будучи текстом в свободной форме, он, вероятно, не будет проиндексирован. Но, может быть, вы в конечном итоге создадите какую
contracts
sellers
-нибудь таблицу или и добавите целочисленные ссылки (идентификаторы FK) в эти таблицы? Это зависит от того, какие именно данные будут повторяться достаточно часто, чтобы их стоило извлекать в дополнительные индексированные столбцы. - может быть, единица измерения, может быть, все ваши единицы навсегда будут измеряться только в единицах, в целых количествах. Но, может быть, там были бы какие-то предметы, измеряемые в килограммах, метрах, литрах и т. Д.?
- наконец , два целых (или плавающих?) столбца типа
Qty_Income
иQty_Outcome
, в которых вы бы записали, сколько элементов было добавлено или взято из вашего хранилища. Не было бы этой колонки E/S! Там будет два целых столбца, в которые вы вставите число в один или другой. Почему? прочитайте статьи о бухгалтерии выше!
В такой схеме базы данных ваш запрос, наконец, будет выглядеть так:
select Sum(s.Qty_Income) as Credit, Sum(s.Qty_Outcome) as Debit,
Sum(s.Qty_Income) - Sum(s.Qty_Outcome) as Saldo,
min(g.Codigo), min(g.Configuracao)
from stock_movements s
join known_goods g on g.ID = s.SKU_ID
group by s.SKU_ID
И вы также сможете гибко составлять аналогичные запросы, группируя их по работникам, датам или количествам (например, заботясь только о КРУПНЫХ событиях, таких как 1000 или более элементов, добавленных за одну операцию), или о чем угодно.