Dotaz: ako spravne uchovavat historiu v sql

[frufru]

zdravim, potreboval by som poradit ako riesit nasledujuci problem.

mam
tabulku zaznamy kde su stlpce id, datum, kusy, operacia_id
tabulku operacie kde su stlpce id, nazov, sadzba_id
tabulka sadzby kde su stlpce id, hodnota_sadzby, platna_od, platna_do

sadzba sa moze v case menit - ked sa zmeni tak vytvorim novy riadok v tabulke sadzby s rovnakym id a roznou hodnotou sadzby a datumami platnosti.

aky je spravny sposob na ukladanie takychto "historickych" dat?

lebo toto sice funkcne je, ale nepripada mi to ako spravny navrh. navyse takychto stlpcov, kde sa data casovo menia a chcem mat aj ich historiu mam v realnej db viac. vysledny select potom musi okrem spojovacej podmienky, pridat aj podmienku na vyber spravnej sadzby pre dany datum.

SELECT
  *
FROM
  zaznamy z
    LEFT JOIN
      operacie o ON o.id = z.operacia_id
    LEFT JOIN
      sadzba s ON s.id = o.sadzba_id
        AND
      z.datum BETWEEN s.platna_od AND s.platna_do

vopred dakume kazdemu, kto mi pomoze vybrat sa spravnym smerom

Odpovědi

[BoneFlute]

Je nějaký důvod, proč evidovat platnost pro každý sloupec extra?

Pokud máš splněno, že tě zajímá jen aktuálně platný záznam, nebo naopak historický, tak je možné historické záznamy odlifrovat do extra tabulky (něco jako sadzba_history).

Přijde mi celkem pochopitelné, že když mám historické záznamy, tak musím uvést pro jaké období záznamy chci.

[frufru]

dovod preco evidovat platnost pre kazdy stlpce extra moze byt napr. pri udajoch o zamestnancoch. zamestnanec moze mat pracovnu poziciu, pracuje na urcitom oddeleni, ma veduceho,atd. moze napr. zmenit iba pracovnu poziciu a ostava na rovnakom oddeleni pod rovnakym veducim, preto kazdy takyto stlpec by mal mat extra evidovanu platnost.

[BoneFlute]

Rozumím. V takovém případě bych to dělal přes řádku a nepáral bych se s tím.

[AraxoN]

Dôvod to môže mať. Napríklad vo fakturačnom systéme. Majme cenu, ktorá sa mení k 1.1., ale v decembri sa fakturuje predpokladaná spotreba v januári, zároveň s vyúčtovaním za december. Vtedy sa môžu rôzne ceny za to isté stretnúť dokonca aj na jednej a tej istej faktúre.

[frufru]

este podotazka...

mal by som pre tabulku sadzby pouzit unikatny index ktory bude zlozeny z id, platna_od, platna_do za predpokladu, ze hodnota sadzby ktora sa bude v priebehu casu menit a moze byt teoreticky v roznych obdobiach aj rovnaka a zaroven datumy platnosti sa nebudu nikdy prekryvat?

dik za odpovede.

[z_sk]

Ako riešiš zľavu pre VIP klientov?

[z_sk]

Ako chceš riešiť zľavu pri väčšom množstve?

[Filip Jirsák]

Pokud s těmi historickými hodnotami potřebujete běžně pracovat, pak to ukládejte tak, jak píšete. Pokud obvykle pracujete s aktuální hodnotou a jenom občas potřebujete zjistit historické údaje, je lepší mít v hlavní tabulce jen aktuální záznam a vedle mít tabulku s historií.

platnost_od a platnost_do budou v tabulce jen jednou, přičemž ničemu nevadí, pokud v záznamech pro různá období budou některé hodnoty stejné. Pokud se ale ty hodnoty mění úplně nezávisle na sobě, pak určitě nepatří do jedné tabulky, takže nebudete mít problém s více platnost_od a platnost_do v jedné tabulce.

[Superexpert_na_databazy]

V nasej aplikacii historiu udrziavame pomocou views. Mame jednu tabulku so vsetkymi cenami, ktore sa menia v case, cennik(id, datum, schvalovatel, tovar_kategoria_id, tovar_id, cena, dph). Nad touto tabulkou mame porobene views, ktore aplikacii serviruju vzdy poslednu aktualnu cenu. Tak isto cez views robime prehlady, statistiky a reporty.