Oto oświadczenie Oracle, które przygotowałem, zanim napisałeś, że korzystasz z SQL-Servera, ale to może dać ci kilka pomysłów, ale będziesz musiał uruchom własną funkcję analityczną ratio_to_report przy użyciu CTE i self-join. Obliczamy skumulowaną proporcję każdego rodzaju w tabelach produktów i trasach klienta i wykonujemy non equi-join na pasujących pasmach proporcji. Przykładowe dane, które wykorzystałem, mają pewne zaokrąglenia, ale zmniejszą się w przypadku większych zestawów danych.
Oto konfiguracja:
create table products (id int not null primary key, "type" int not null, route varchar (20) null);
create table clienttable ("type" int not null, percent number (10, 2) not null, route varchar (20) not null);
insert into clienttable ("type", percent, route) values (1, 0.4, 'A');
insert into clienttable ("type", percent, route) values (1, 0.4, 'B');
insert into clienttable ("type", percent, route) values (1, 0.2, 'C');
insert into clienttable ("type", percent, route) values (2, 0.5, 'A');
insert into clienttable ("type", percent, route) values (2, 0.5, 'B');
insert into clienttable ("type", percent, route) values (3, 1.0, 'C');
insert into products (id, "type", route) values (1, 1, null);
insert into products (id, "type", route) values (2, 1, null);
insert into products (id, "type", route) values (3, 1, null);
insert into products (id, "type", route) values (4, 1, null);
insert into products (id, "type", route) values (5, 1, null);
insert into products (id, "type", route) values (6, 1, null);
insert into products (id, "type", route) values (7, 1, null);
-- 7 rows for product type 1 so we will expect 3 of route A, 3 of route B, 1 of route C (rounded)
insert into products (id, "type", route) values (8, 2, null);
insert into products (id, "type", route) values (9, 2, null);
insert into products (id, "type", route) values (10, 2, null);
insert into products (id, "type", route) values (11, 2, null);
insert into products (id, "type", route) values (12, 2, null);
-- 5 rows for product type 2 so we will expect 3 of route A and 2 of route B (rounded)
insert into products (id, "type", route) values (13, 3, null);
insert into products (id, "type", route) values (14, 3, null);
-- 2 rows for product type 3 so we will expect 2 of route C
i oto oświadczenie
select prods.id, prods."type", client.route cr from
(
select
p.id,
p."type",
row_number() over (partition by p."type" order by p.id)/count (*) over (partition by p."type") cum_ratio
from
products p
) prods
inner join
(
select "type", route, nvl (lag (cum_ratio, 1) over (partition by "type" order by route), 0) ratio_start, cum_ratio ratio_end from
(select "type", route, sum (rr) over (partition by "type" order by route) cum_ratio
from (select c."type", c.route, ratio_to_report (c.percent) over (partition by "type") rr from clienttable c))) client
on prods."type" = client."type"
and prods.cum_ratio >= client.ratio_start and prods.cum_ratio < client.ratio_end
To daje następujący wynik: -
+----+------+----+
| ID | type | CR |
+----+------+----+
| 1 | 1 | A |
| 2 | 1 | A |
| 3 | 1 | B |
| 4 | 1 | B |
| 5 | 1 | B |
| 6 | 1 | C |
| 8 | 2 | A |
| 9 | 2 | A |
| 10 | 2 | B |
| 11 | 2 | B |
| 13 | 3 | C |
+----+------+----+
"procent" na liście jest raczej wprowadzanie w błąd, jeśli liczba, która następuje, nie jest w rzeczywistości procentem . –
Którego DBMS używasz? Czy możesz też opublikować kod lub pseudokod bieżącego rozwiązania? –
SQL Server 2008. A jak to 0,4 nie jest procesem? Czy 40.0 jest lepsze? Zakładam, że 0.4 jest lepsze, ponieważ 0,4 * liczba (*) to liczba wierszy do zaktualizowania. – powlette