Задача для вычисления значений из 1 таблицы с использованием group by в firebird

#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 )
  )
 

И затем:

 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. Я считаю, что весь ваш подход здесь неправильный, если «нужен простой контроль запасов».

Я думаю, что в вашей таблице должны быть такие столбцы:

  • идентификатор суррогатной строки, primary key , автоматически увеличивающееся целое число, 32-разрядное или 64-разрядное
  • столбцы, идентифицирующие ваш товар, обычно это, опять же, один суррогатный целочисленный артикул (Единица хранения запасов), ссылающийся (см. — Внешние ключи) на другую «таблицу словаря». В вашем случае это, похоже, две колонки Codigo , Configuracao но это также означает, что вы не можете добавлять дополнительную информацию («атрибуты») о ваших товарах, например, цену или фотографию (читай: нормализация базы данных). Это также усложняет группировку для движка Firebird, чем использование одного целого столбца. Кроме того, вы создали index столбец(столбцы), идентифицирующие элементы, не так ли? Каков ваш план запроса для этих выборок, используют ли они индекс на Codigo и Configuracao или вместо этого специальная внешняя сортировка?
  • операции timestamp , которая автоматически устанавливается сервером Firebird current_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 или более элементов, добавленных за одну операцию), или о чем угодно.