A rendelési adatbázis önmagában 30 000 Ft árbevételt mutat, a terméksorokkal összekapcsolt riport mégis 80 000 Ft-ot ad. Ez gyakran a táblák eltérő részletezettségéből következik. Egy rendeléshez több tétel tartozik, ezért az összekapcsolás után a rendelés szintű végösszeg több soron ismétlődik.
A hiba nem feltétlenül hibás SQL-szintaxis. A lekérdezés szabályosan végrehajtódhat, miközben az üzleti mutató rossz szinten összegződik. Először ezért azt kell leírni, mit jelent egy sor a forrástáblában és az összekapcsolás után.
Két rendelésből öt riport sor lesz
Az első rendelés végösszege 10 000 Ft, és két terméktételt tartalmaz. A második rendelés 20 000 Ft, három terméktétellel. A rendelési táblában két sor van, végösszegük 30 000 Ft.
A rendelésazonosító szerinti összekapcsolás a tételtáblával öt sort eredményez. Az első rendelés 10 000 Ft-os végösszege kétszer, a második 20 000 Ft-os végösszege háromszor szerepel. Ezek összege 2 × 10 000 + 3 × 20 000 = 80 000 Ft.
A PostgreSQL táblakifejezésekről szóló dokumentációja pontosan leírja, hogy a kapcsolási feltételhez illeszkedő sorpárokból hogyan jön létre az eredmény. A fenti összegek saját tesztadatok; bármely hasonló egy-a-többhöz kapcsolásnál érdemes ugyanilyen kis ellenpéldát készíteni.
A mutatóhoz tartozó szinten összegezz
A teljes rendelési árbevételhez a rendelési táblában minden rendelés egyszer számítson. Ha csak azok a rendelések kellenek, amelyekben egy bizonyos termék szerepel, először a megfelelő rendelésazonosítók egyedi halmazát állítsd elő. Ezután kapcsolódjon hozzájuk a rendelés szintű összeg.
Más feladat a termékenkénti értékesítés. Ott az adott terméksor saját, megfelelően értelmezett összege lehet az összesítés alapja. A szállítási díj, a rendelési kedvezmény vagy egy összesített jóváírás felosztása további üzleti szabályt kíván. Ezeket nem lehet a rendelési végösszeg minden sorra másolásával helyesen kezelni.
A SQL-formázó az áttekinthetőséget segíti. A formázott lekérdezés helyességét a kapcsolatok, a csoportosítás és az ellenőrző adatsor bizonyítja; a rendezett tördelés önmagában kevés.
Az eltérő összegek kiválasztása nem általános javítás
Csábító ötlet csak a különböző rendelési összegeket összeadni. A két első rendelésnél a 10 000 és 20 000 Ft valóban 30 000 Ft-ot adna. Ettől a módszer még hibás marad.
Adj hozzá egy harmadik, külön azonosítójú rendelést 10 000 Ft-tal. A helyes árbevétel most 40 000 Ft. A különböző összegértékek halmaza továbbra is csak 10 000 és 20 000 Ft, így a módszer 30 000 Ft-ra jutna.
A megőrzendő egyediség tehát a rendelés azonosítójához tartozik. Két külön rendelésnek teljesen szabályosan lehet azonos végösszege. Az összeg szerinti duplikációszűrés valódi bevételt is eltüntethet.
Készíts egyeztethető ellenőrző sorokat
A riport mellé kerüljön a forrásrendelések száma, az egyedi rendelésazonosítók száma és a kapcsolás utáni sorszám. A saját példában ezek rendre kettő, kettő és öt. A harmadik rendelés hozzáadása után a rendelésdarabszámnak háromra kell nőnie.
Tesztelj tétel nélküli rendelést is: belső kapcsolásnál kieshet, külső kapcsolásnál más kezelést kap. Azt, hogy üzletileg melyik szükséges, a riport célja dönti el. Az ismeretlen azonosítójú tételeket külön hibalistára célszerű tenni, és a kapcsolási kulcsok egyediségét a forrásban ellenőrizni.
Gyakori kérdések
A több riport sor önmagában adatduplikáció?
Nem feltétlenül. Tételszintű riportban természetes, hogy egy rendeléshez több sor tartozik. A rendelési végösszeg ismételt összeadása a probléma.
Az összes sor törlése egy kivételével megoldás?
Csak akkor, ha az adott mutató valóban rendelési szintű, és a választás rendelésazonosító szerint történik. Termékriportnál ezzel valódi tételeket veszíthetsz el.
Mit ellenőrizzek a végösszegen kívül?
Az egyedi kulcsokat, a sorok részletezettségét, a kieső rekordokat és a kapcsolás előtti-utáni darabszámokat. Ezek együtt mutatják meg a hiba helyét.