Baci pogled na ovo - https://vladmihalcea.com/database-multitenancy/

Ovo ako si zamislio je ok. Obezbeđuje izveštaje kakvi su traženi. Ako će da bude mnogo podataka, bože moj, takvi su izveštaji. Onda se traži način da se optimizuje rad sa bazom da je to ne opterećuje (mada ne učekuj da će to da bude previše)

Usput, gledajući tvoj model, meni se nešto čini da bi mogao da spojiš tabele Registracija_podaci i Agencija_Vozila_assoc u jednu. Ne vidim šta dobijaš time što su razdvojene, osim komplikovanijih upita i verovatno malo usporenja.

Da, ovo sa registracijom verovatno moze da se ponavlja.
No, izracuna se kolko je to rekorda. Danas komp ima 4GB rama pa moze ogromne baze sve da cita iz rama a tu su i SSD-ovi ako sve ne moze da stane u RAM.

Da Pedja, u pravu si, imam tabelu viska, sasvim nepotrebno :)


U slucaju da ta assos tabela bude imala 1M podataka, da li to znaci da kada budem hteo da izvucem za AgencijaId == 5, da ce on proci kroz svih 1M i isfiltrirati ili postoji nacin da se to odradi da gadja nekako ' u glavu ' te upise? Tacnije, da li bi pomoglo indeksiranje da se to ubrza ili postoji i bolji nacin.

Da, index je obavezan.
Mada mislim da ti fali i neko vreme jer sumnjam da ima smisla uvek vracati sve rekorde za agenciju.
Pogledaj i kako se radi particionisanje tabele. To je najcesce prvi korak kada stvari krenu da rastu.
https://docs.microsoft.com/en-...-indexes?view=sql-server-ver15

Problem je sto vecina strategija (sem geografskih mada i to moze biti problematicno ako imas cross-region feature) zavisi od toga sta tvoja aplikacija radi.

Da li ces imati veliki broj transakcija?
Da li ti je bitan strong ili eventual consistency?
Da li ti treba fuzzy search i pritom imas milione rekorda?
Da li ti treba millisecond vreme za vracanje specificnog recorda i pritom ce biti hiljade upita u sekundi?

Ne postoji magicni put koji ce resiti sve. Pocni od dizajna aplikacija, vidi kakav ce biti usage pattern, gde ocekujes rast i onda vidi sta ti odgovara.