[es] - Razdvojene baze ili sve u jednoj

magrinjo

Član broj: 337536
Poruke: 143
*.dynamic.sbb.rs.

+1 Profil

Razdvojene baze ili sve u jednoj - best practice

^{12.12.2020. u 15:23 - pre 45 meseci}

Pozdrav svima,

Uzmimo za primer da mi je cilj aplikacija koja sluzi za registraciju automobila sa jedinstvenom bazom vozila za sve agencije.
Dizajn baze je napravljen cisto radi primera, da bih lakse objasnio na sta mislim.

Tabele:

[Vozila]

- Id
- Broj sasije

[Agencija]

- Id
- Ime agencije za registraciju

[Registracija_podaci]

- Id
- Uspesna registracija [bool]

[Agencija_Vozila_assoc]

- Id
- AgencijaId
- VoziloId
- RegistracijaPodaciId

Ako kazemo da ce svaka agencija da ima svoj profil, i da ukoliko agencija X u bazu podataka (Vozila tabelu) ubaci vozilo Y, agencija XY ce takodje imati taj podatak kao i celu istoriju njegove registracije (agencija_vozila_assoc).
Ako sve ovo ubacim u jednu bazu, kada bude 1000+ agencija, assoc tabela ce biti prepuna podataka i sve vise vremena ce trebati aplikaciji da iscita podatke iz nje jer se ne ticu samo agencije koja proverava podatke vec i istorije svih registracija.

Kako bi ovo bilo pametno odraditi? Koji je 'best practice' u ovom slucaju?

Hvala puno.

_{[Ovu poruku je menjao magrinjo dana 12.12.2020. u 16:43 GMT+1]}

Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12867

+4787 Profil

Re: Razdvojene baze ili sve u jednoj - best practice

^{12.12.2020. u 16:09 - pre 45 meseci}

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

Nebojsa Milanovic: Što se tiče Trumpa, smatram ga vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu.
Nebojsa Milanovic: Rusija ne laže, ne vodi osvajačke ratove
Nebojsa Milanovic: Trump je svetla tačka u USA blatu.

Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6305

Sajt: pedja.supurovic.net

+1574 Profil

Re: Razdvojene baze ili sve u jednoj - best practice

^{12.12.2020. u 17:36 - pre 45 meseci}

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.

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.

+1064 Profil

Re: Razdvojene baze ili sve u jednoj - best practice

^{12.12.2020. u 18:18 - pre 45 meseci}

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.

Odgovor na temu

magrinjo

Član broj: 337536
Poruke: 143
*.dynamic.sbb.rs.

+1 Profil

Re: Razdvojene baze ili sve u jednoj - best practice

^{13.12.2020. u 00:04 - pre 45 meseci}

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.

Odgovor na temu

plague
Software Developer
Auckland, NZ

Član broj: 46734
Poruke: 623
..5.69.111.static.snap.net.nz.

+373 Profil

Re: Razdvojene baze ili sve u jednoj - best practice

^{14.12.2020. u 00:04 - pre 45 meseci}

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.

Odgovor na temu