Black Friday Black Friday
Black Friday výprodej! Až 80 % extra bodů zdarma! Více informací zde

Diskuze: Návrh SQL databázového modelu pro Multitenancy

Ostatní jazyky SQL SQL a databáze Návrh SQL databázového modelu pro Multitenancy

Aktivity (1)
Avatar
Daniel Vodák:23. dubna 18:44

Ahoj,
budu rád za každý názor a připomínky k návrhu této databáze.

Vytvářím webovou aplikaci v asp.net mvc, která bude mít přístup k databázi, ve které se budou shromažďovat data o jednotlivých zakázkách (objednávkách).

K databázi bude mít přístup přibližně 5 zákazníku, kteří budou vytvářet objednávky.

Bude se jednat vždy o výrobek, který bude mít specifické parametry (produkty), které si vybere zákazník.

Dále bude k dané objednávce několik Events (poznámky, nahraný SW, servisní zásahy, dokumentace, apod.)

Mám v plánu udělat tuhle webovou aplikaci Multitenancy, tzn. databázový model rozšířím o tbl. Tenant.

Má otázka zní, je tento model dobře navržený?

Všem moc děkuji.

 
Odpovědět 23. dubna 18:44
Avatar
Marian Benčat
Redaktor
Avatar
Marian Benčat:23. dubna 23:09

Upřímně, pokud nemáš hodně dobrý duovd pro to to udělat jinak, tak udělej 1tenant = 1 databáze.. Přináší to spoustu výhod a jednotky nevýhod, které se většinou neprojeví.

Nahoru Odpovědět 23. dubna 23:09
Totalitní admini..
Avatar
Odpovídá na Marian Benčat
Daniel Vodák:23. dubna 23:57

Můžeš mi prosít stručně popsat proč by 1 tenant = 1 databáze (single tenancy), mělo být lepší než multitenancy?

Mé plánované řešení je to, že výše uvedený databázový model rozšířím o tabulku Tenant, kde pak následně rozšířím všechny potřebné tabulky o TenantId sloupec.

Předpokládá se, že objednávek bude zhruba 50 za rok a tudíž mi přišlo více komplikované řešit to jako single tenancy.

Děkuji.

 
Nahoru Odpovědět 23. dubna 23:57
Avatar
Marian Benčat
Redaktor
Avatar
Odpovídá na Daniel Vodák
Marian Benčat:24. dubna 2:48

1 databáze = 1 tenant neni single tenancy..tenantnost neříká nic o způsobu uložení.

Zítra možná napíši více

Nahoru Odpovědět 24. dubna 2:48
Totalitní admini..
Avatar
Marian Benčat
Redaktor
Avatar
Marian Benčat:24. dubna 8:27
  1. extrémní zjednodušení celého systému - nikde nemusíš uvažovat, že existuje více tenantu, jen na základě něčeho v requestu udelas konkrétní connection do databáze. Nikde v logice nemusíš tedy nic jako tenanty řešit, poresis to naturalne selectem db
  2. bezpečnost a gdpr - máš odděleně data pro každého tenanta, tedy i každý má jiný heslo do db,.nemůže se ti nikdy stát že někde zapomenes do podmínky přidat scope tenanta..
  3. škálovatelnost - je velmi pravděpodobné, že jeden tenant bude mít mnohem více dat než jiný, proč zbytečně dělat sharding třeba pro polomrtve tenanty?
  4. variabilnost - dost často chceš mít nějakou.exkluzivní věc pro určitého tenanta, ten může mít tedy nějaké třeba fieldy navíc...
  5. migrace a zálohování - velmi jednoduchá migrace a zálohování dat konkrétního tenanta
Nahoru Odpovědět 24. dubna 8:27
Totalitní admini..
Avatar
Marian Benčat
Redaktor
Avatar
Marian Benčat:24. dubna 8:30

Jsou u toho dvě nevýhody:

  1. multi tenant dotazy - třeba pro statistiky,.když se potřebuješ ptát mezi více tenanty.. Ale všechny SQL stroje umí dotazy mezi více databazemi a dokonce i mezi více stroji
  2. db konzistence - musíš scripty pouštět nad.více db
Nahoru Odpovědět 24. dubna 8:30
Totalitní admini..
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 6 zpráv z 6.