Szerintem egyáltalán nem érdemes ragaszkodnod a 'nincsenek redundanciák az adatbázisban' követelményhez.

Hadd hozzak egy egyszerűsített példát. Tekintsünk egy fórumot, ahol vannak topicok, és a topicokon belül üzenetek. A topicok listázásakor szeretnénk kiírni az bennük levő üzenetek számát.

Ha egyáltalán nem tűrünk redundanciát, akkor az alábbi adatmodellt alkalmazzuk:

üzenetek: üzenet_id, topic_id, szöveg
topicok: topic_id, topic_neve

ilyenkor viszont kénytelenek vagyunk a topicok listázásakor minden alkalommal minden kilistázott topichoz az üzenetek táblából aggregálni kell (jelen esetben össze kell számolni) a hozzá tartozó üzeneteket - ez futásidő szempontjából rendkívül pazarló eljárás.

Nem vesztünk sokat a redundanciából, ha módosítunk, így:

üzenetek: üzenet_id, topic_id, szöveg
topicok: topic_id, topic_neve, üzenetek_száma

ilyenkor új üzenet érkezésekor (vagy üzenet törlésekor) ugyan két műveletet kell végezni, mert módosítani kell az adott topic üzenetszámlálóját (célszerűen triggerből) is, viszont utána a topicok listázásakor aggregáció nélkül rögtön ott a kért aggregált adat.

Ha várható, hogy lekérdezésből lesz több, és nem üzenetmozgásból (vagy mondjuk úgy, nem lesz nagyságrendekkel több mozgás, mint lekérdezés), akkor ebben az esetben egy kis redundancia árán megvásároltunk egy jelentős teljesítménynövekedést.

A te konkrét alkalmazásod esetén általában mennyi mozgás, és ehhez képest mennyi lekérés van?

Mit jelent, hogy 'Egy adott anyag összes tétele időrendben összesen illetve egy adott raktárra.'?