MySql Osztás és SUM majd INNER JOIN probléma
2021-11-24T22:06:53+01:00
2021-11-25T12:51:13+01:00
2022-08-12T05:50:28+02:00
Kicsizann
Sziasztok,

Belefutottam egy olyan problémába amit nem tudok megoldani.

Egy számolás és egy szűrés SQL-be.

Csak két részletbe tudtam "megoldani".

orders
order_primary_id
delivered_time
completed

logistic_table
order_id
total_price
logistic_fee

Van egy lekérdezésem, ami kiszámolja az adott sorokban az áfával csökkentett árat.
total_price = A termék bruttó ára az adott sorban. ( integer )
logistic_fee = A termék áfája (float, 1.27;1.18;1.05)

SELECT order_id,total_price, total_price / logistic_fee FROM `logistic_table`, ( SELECT SUM(total_price) FROM `logistic_table` ) sq
Ezzel szépen ki is számítottam a nettót elemenként. A gond csak az, hogy a vásárlások ( orders ) táblában vannak és itt van rögzítve a kiszállítás ideje is, amely kap egy completed=2 státuszt.

Az előző sql lekérdezésbe szeretnék belerakni egy inner joint:

$start = timestamp, az adott év első napja.
$last = timestamp, az adott év utolsó napja.

INNER JOIN orders ON logistic_table.order_id = orders.order_primary_id WHERE delivered_time BETWEEN $start AND $last AND completed='2'
A kérdéseim a következőek:

1. Össze hozható e ez a két feltétel? Próbálkozásaim során, ámbár szintaktikailag elfogadta de nem jelenítette meg a másik tábla adatait. Rengeteg variációt kipróbáltam de egyik sem hozta meg a várva várt eredményt.

2. Érdemes lenne e kerekítenem a netto értéket elemenként, hogy pontosabb eredményt kapjak a vásárlásokról vagy csak a legvégén miután összeadtam az egészet? ( sok tizedes sokra megy és pár forinttal szerintem eltolja a végeredményt)

Valamint ha ez nem jön össze, már csak az az egy opció maradt számomra ,hogy felcímkézem a logistic_table tábla elemeit is a  delivered_time-al, amikor a completed=2 -re vált.

A végső összeadást szerintem ciklusban végzem php val, mert ha még ebbe belerakok még egy szintet SUM ra, akkor már végképp nem fogom érteni az egészet hogy mi történik. :)

A segítségeteket előre is köszönöm.

Remélem minden szükséges adat megvan.
Mutasd a teljes hozzászólást!

  • SELECT order_id,total_price, total_price / logistic_fee FROM `logistic_table`, ( SELECT SUM(total_price) FROM `logistic_table` ) sq
    Ebben hol használod az `sq`-ból származó értéket? Ilyesmire gondolnék:

    SELECT sq.grand_total,order_id,total_price, total_price / logistic_fee FROM `logistic_table`, ( SELECT SUM(total_price) grand_total FROM `logistic_table` ) sq
    Mutasd a teljes hozzászólást!
  • Szia!

    Amit nagyon fontos lenne tudni:

    az orders és logistic_table között 1-1 vagy 1-N kapcsolat van?
    Ha 1-1 akkor nincs szükség semmilyen summra nem?
    Hacsak nem rendelésenkén, hanem időszakra akarsz összegezni.

    Mivel a lekérdezésedben ott van a order_id és a másik táblára sum-olni akarsz, 
    így feltételezem hogy 1-N kapcsolat van.
    Viszont akkor a mező név félrevezető a másik táblában (total_price)

    Amit szeretnél megvalósítható.

    Az hogy egy táblát join-olsz nem igényel where-t.

    A WHERE az egész lekérdezésre vonatkozik JOIN esetén.

    Más apróságok:

    Ha osztani akarsz elötte nézd meg hogy az osztó nem nulla, (tudom, mindenki rávágja elsőre hogy az nem lehet nulla, aztán majd jön a probléma mikor mégis az lesz.)

    Az hogy join-al hozzáfűzöl egy másik táblát vagy 10-et, nem jelenti azt hogy bármi is megjelenik ezekből a táblákból.
    Csak akkor ha a SELECT rész tartalmaz bármit is ebből a táblából.

    Kerekítés:
    Ha vannak tételek, azok forintra vannak általában kerekítve.
    Maga a tétel egységára szokott néha tört forint lenni.
    A számla végén így nincs mit kerekítni, csak a kp-t bizonylatoknál a fizetendő összeg 5 forintra. De ezt a részt mondja meg a pénzügy, vagy a könyvelés, hogyan szeretnék :)

    A végső összadás mire vonatkozna?
    Csak nem az éves forgalmat akarod kiszámolni?
    Akkor a selectbe semmiképp nem kell order_id
    Mutasd a teljes hozzászólást!
  • Szia,

    1-1 kapcsolat van ha jól értettem a kérdést, mivel az orders csak a rendelés összesítését tartalmazza beleértve a kiszállítás napját.

    Így a logistic_table minden bejegyzéséhez társítanám, hogy melyik megrendeléshez tartozik. Érdemes lenne fordítva?

    A logistic_table tételesen tartalmazza a rendelés elemeit. ( pl 25dkg sajt, 2db, darabja 500 ft, összesen brutto 1000ft, adó 18%) Ez azért lenne fontos nekem, mert termékenként eltérő áfa is lehetséges.  

    Igen éves összesített áfát szeretnék számolni és ehhez kell nekem tételesen a bruttó értékeket osztanom az áfa értékével ( pl: 1.27), kerekítenem, majd összesítenem mert ha a végén kerekekítek pontatlan lesz.
    1000/1,18 = 847,457627118644068. kerekítve 847. Itt azért félforintok módosíthatják a a legvégét.


    Ha megvan a tényleges netto, kivonom az áfás bevételből és kijön az összesített áfám...

    Mondjuk eléggé háttúlról közelítettem meg a dolgot. :D 

    Igen az osztó nem lehet nulla, de csodák mindig léteznek, pl nem állítottak be áfát a termékhez.
    Erre gondolsz? 

    logistic_fee FLOAT NOT NULL
    Meg ahogy kicsit gondolkodtam a fő SELECT-ben határozzam meg az INNER joinolt elemeket is? 

    pl, Select logistic_table.order_id, ....

    Az INNER JOIN hoz meg azért kell nekem a where mert ott határozom meg ,  hogy kiszállítva és mikor. ( Adott éven belül, ez később kell majd nekem havira is azért így csináltam)
    Mutasd a teljes hozzászólást!
  • Szia,

    Köszönöm, hogy felhívtad rá a figyelmemet, leginkább elvitt magával a nettó kiszámolása és annak törtjei. Így lényegében kimaradt a grand total.
    Mutasd a teljes hozzászólást!
  • Köszi. Még azt is megkérdezhetném, hogy az `áfakulcs/100+1` érték az miért `raktározási díj`, de ne legyünk szőrszhasogatók, inkább arra kérlek azt a konkrét lekérdezést idézd be, amivel a gond van.
    Mutasd a teljes hozzászólást!
  • 1-1 kapcsolat van ha jól értettem a kérdést, 

    A logistic_table tételesen tartalmazza a rendelés elemeit.

    Vagyis még sem érted jól a kérdést.
    Ez 1-N kapcsolat, hiszen egy rendeléshez tartozik több tétel.

    Ezek szerint a táblák definicióját is hiányosan adtad meg, hiszen ott pl sehol nem szerepel mennyiség, csak rendelés_id, összeg, áfa.
    Hol a többi? Találjuk ki?
    Mit is tartalmaz a total price? a tétel összértékét bruttóban?


    Ha lekerekíted a nettó értéket, újra kiszámolva lehet más lesz a bruttó.
    Mármint ha azt is kerekíted...
    A legtöbb programban pont ezért nem spórolnak ezzel és tárolján a nettó bruttó áfa összegeket 3 mezőben... amit tudnak kódból szükség esetén korrekciózni.

    Meg ahogy kicsit gondolkodtam a fő SELECT-ben határozzam meg az INNER joinolt elemeket is?

    Szeretnéd látni a kimenetben? Igen? Akkor hol máshol határoznád meg?
    A SELECT pont azt teszi hogy meghatározza a kimenet mezőit...
    Ha valami nincs benne, nem is fogod látni a kimenetben.

    logistic_fee FLOAT NOT NULL

    Ez kevés.
    Ha nem null attól még lehet nulla.
    Másképp:
    nulll != 0
    a null nem egyenértékű a matematikai nullával.
    a null kb a semmit jelenti.

    Az inner joinban csak az on kell.
    Hogy mi alapján köti össze a két táblát.
    A join nem tartalmaz WHERE záradékot sehol.
    Lásd a dokumentációban:

    MySQL :: MySQL 8.0 Reference Manual :: 13.2.10.2 JOIN Clause

    A WHERE záradékban sorold fel az összes táblára az összes feltételedet.
    A WHERE-nek ez a feladata.
    A JOIN-nek meg csak a táblák összekapcsolása
    Mutasd a teljes hozzászólást!
  • Amúgy csak kiváncsiságból:

    Az orders táblák mellett nincs pénzügyi bizonylat tábla?
    Pl számlák, nyugták .....

    Mert ha már éves áfát akarsz számolni, annak megvan a pénzügyi bizonylata is gondolom.
    Az sokkal  "hitelesebb" mint a tárolt rendelésekből számolni akármit is.
    + gondolom áfabontásban is kellenek az áfa összegek, nem összesítve csak.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd