it-swarm-eu.dev

Jednotlivé V / s více databází

Vytvořil jsem tuto webovou aplikaci (php a mysql), která ukládá informace pro různé organizace (v současné době asi 20 klientů).

Aktuální scénář ukládá informace o klientovi do jednotlivých databází, takže existuje 20 klientských databází a 1 hlavní databáze.

Jednou z hlavních výhod je to, že jak je každý klient db izolován, číslování klientských artefaktů (zprávy, audity) atd. Je sekvenováno; dávat našim klientům pocit bezpečí.

Každá databáze má zhruba 15 tabulek a nejvíce řádků v tabulce je asi 2000. Očekává se, že bude naražen na maximálně 5 000 záznamů.

Správa jediné změny na úrovni db znamená změnu 20 databází, ale ve výjimečných případech, kdy potřebuji provést takovou změnu, používám skript, který to provádí při jediném volání funkce.

Jsme na dohodě o společném hostování a náš poskytovatel internetových služeb nám dodává omezené číslo. databází; a to mě vedlo k přemýšlení o centralizaci databáze; takže VŠECHNY klientská data mohou být uložena v hlavní databázi.

Samozřejmě některé důležité problémy, které se objevují, jsou:

a. Udržování sekvence artefaktů (to by bylo možné řešit vytvořením dalšího referenčního klíče) b. Rychlost a výkon (v takovém případě mohu vytvořit indexy pro urychlení věcí) c. Zabezpečení: Toto bude spravováno jako každý dotaz, který vyvolá informace o klientovi. bude také sledovat jejich client_id

V budoucnu možná budeme muset zvážit porovnání datových sad jedné organizace s jinou, ale věřím, že toho lze dosáhnout i na centralizovaném db. Jsem poněkud nakloněn (z důvodů výkonu a údržby) k přechodu do centralizované databáze.

Myslíte si, že přechod do centralizované databáze má větší smysl, než zůstat v současné podobě (v jednotlivých databázích)?

Díky za radu.

17
Narayan

Oba systémy mají zděděná rizika a výhody. Pracoval jsem pro finanční firmu, která podporovala zhruba 40 klientů (národních bank) v 1 databázi. Poté jsme zakoupili další společnost, která prodávala podobný software a která šla s 1 databází na klienta. Nakonec společnost zkrachovala a my jsme museli exportovat všechna uživatelská data. Zde jsou lidé, se kterými jsem spolupracoval, a našel jsem:

Pro's of Single DB:

  1. Aktualizace softwaru a opravy chyb jsou snazší.
  2. Snadná správa a hlášení všech klientských dat.
  3. Aktualizace dat je snazší.
  4. Snadné vytvoření modulární funkce, kterou chce 1 klient, vypněte, pokud je vypnuta pro ostatní klienty, a poté ji vypněte, když si to budou přát.

Con's of Single DB:

  1. Integrita dat - Měli jsme 2 nebo 3 případy, kdy uživatelé jedné banky viděli data jiné banky. To byla noční můra. Obzvláště proto, že uživatelé webu nebyli jen zaměstnanci banky, ale skutečnými klienty banky, kteří drželi účet! Toto je zdaleka největší problém s 1 databází
  2. Export klientských dat - Když jsme k tomu museli, obvykle to nebyl velký problém. Skončíte s 1 tabulkou, která obsahuje všechny klienty a od této tabulky odejdete, abyste získali konkrétní údaje o vašem klientovi.

Pro je z více DB:

  1. Neexistuje žádná obava z kontaminace nebo narušení dat mezi klienty
  2. Export dat klientů je snadný.

Con's of více DB:

  1. Aktualizace a opravy chyb - To byla skutečná noční můra. Pokud máte 20 klientů ve 20 různých databázích, rychle narazíte na případ, kdy 1 klient chce opravit chybu a další si myslí, že chyba je funkce nebo nechce riskovat aktualizaci. Dále budete mít případy, kdy 1 klient chce vylepšení hry, ale ostatní ne. Když k tomu dojde, databáze se začnou lišit. Najednou budete muset aktualizovat klienty 1-15 s 1 skriptem 16-19 s jiným a 20 s třetinou. Viděli jsme, že se to stalo takovým problémem, že oprava chyby by trvala 15 až 20krát déle pro společnost, kterou jsme zakoupili, než pro nás, protože museli provést všechny testy pro každého klienta a zabývat se zvláštním kódem každého klienta. Ve skutečnosti potřebovali pro každého nového klienta novou podpůrnou osobu, zatímco mateřská společnost potřebovala jednu pro každých 5 až 10 klientů.
  2. Správa DB - Když se dostanete k velkému počtu klientů, správa všech databází se stane skutečným problémem. Budete bezpochyby potřebovat více času DBA pro jejich správu.

Nakonec moje doporučení, které jsem viděl a udělal, je mít "disciplínu"! Myslím, že volba multi-db je o něco lepší, protože vás chrání, ale nemůžete nikdy nechat klienty, aby si vybrali, že způsobí, že přidáte funkčnost pouze těm, nebo se ocitnete na cestě k selhání.

13
Ben Hoffman

Mám samostatnou databázi pro samostatné klienty. Klient to může vyžadovat z bezpečnostních důvodů - tj. Pouze jejich web má přístup k jejich datům. To také znamená, že pokud si klient přeje přesunout svá data, bude to mnohem mnohem snadnější správa.

To také znamená, že pokud existuje problém s databází jednoho klienta, neovlivní to všechny ostatní.

Pokud chcete porovnat data mezi klienty, měli byste to udělat samostatně.

Pokud vám dochází databáze, které můžete mít, možná byste měli zvážit změnu poskytovatele hostitele.

13
ChrisF

Chcete-li přidat dosud uvedené profilové/koncové položky:

Pro z více databází:

  1. Problémy se zamykáním jsou vyloučeny; máme databáze, kde klienti mohou na některých tabulkách vyvolat změny DDL. U větších tabulek (> 2m záznamy) to tabulku zamkne po značnou dobu. Jedinou znevýhodněnou osobou jsou jejich vlastní uživatelé, takže je to docela přijatelné.

  2. Flexibilita - někteří klienti mají konkrétní přání týkající se dat, která chtějí uložit; multi-databáze nám umožnila flexibilitu specificky změnit jejich databázi, aniž by bylo nutné zaplnit datový model pro ostatní klienty.

Nevýhody:

  1. Hlavní kon: Připojení k jiným stolům je mnohem těžkopádnější. Máme hlavní databázi, která obsahuje nejvíce metadat. Uživatelé databáze specifické pro klienta nemají přístup k této databázi, takže všechna spojení mezi tabulkami v této databázi a klientem specifickou se zpracovávají v aplikaci namísto v databázi. To by se dalo vyřešit poskytnutím přístupu konkrétním klientům do hlavní databáze, ale pak by aplikace mohla/mohla znovu vytéct informace.

Hodně štěstí při výběru!

0
kander

Vím, že jste již vybrali odpověď, ale vypadá to, že existuje jiné řešení, které nebylo navrženo:

Přesuňte vše do jedné databáze, ale vytvořte tabulky pro každého zákazníka pomocí předpony, jako je tato:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Je to druh nejlepšího z obou světů.

  • Je velmi snadné přejít z aktuálního nastavení do nového nastavení.
  • Můžete vytvořit 1 uživatele na klienta a omezit jeho oprávnění na tabulky jeho společnosti a nic jiného
  • V případě potřeby můžete vytvořit superuživatel a snadno agregovat data.
  • Použijte pouze jednu databázi
0
Sylver

Jediný důvod, proč bych neměl individuální databázi pro každého klienta, je, pokud budete mít 100s nebo 1000s klientů/databází. To by mohlo být opravdu chlupaté na správu, včetně provádění změn databáze nebo dělat něco napříč všemi databázemi. Akce, ke kterým dochází ve velkém počtu více databází, mohou být také pomalé, protože musíte otevřít (a proto zavřít) tolik tabulek.

Ale kromě tohoto případu si myslím, že více databází je lepší.

Jednou výhodou, která nemusí být důležitá, ale může být užitečná, je to, že každý klient dostane své vlastní sekvenční ID (namísto možného přeskakování banda, protože další klienti přidali záznamy).

Více databází také umožňuje snadné přizpůsobení dílčích tabulek (jako je typ telefonu) na klienta bez potřeby ID nadřazeného záznamu v těchto tabulkách.

0
Darryl Hein

Nejprve sekvenování artefaktů. Předpokládám, že k tomu používáte celé primární klíče. Opravdu byste měli mít samostatný sloupec „číslo artefaktu“. PK by měly být PK a nic jiného. Lidé mluví o „přírodních klíčích“ a podobně a já se krču. Kdykoli se spoléháte na to, že PK je více než identifikátor, vrátí se, aby vás kouslo. Pokud chcete znát posloupnost něčeho, uložte datum nebo pořadové číslo.

Myslím, že ve vašem případě by vás konfigurace konfigurace zavedla do jediné databáze. Podívejte se, co vás stojí za údržbu a upgrade databází. Jaké náklady jsou spojeny s každým vydáním softwaru? Také přemýšlejte o nákladech, když získáte nového zákazníka a musíte si vytvořit DB a nakonfigurovat pro ni aplikaci. Automaticky je možné cokoli, otázkou je, bude to za to, když budete mít 100 databází?

Po silnici je snazší škálovat (dělení, hardware, sharding atd.) Jednu databázi, než to udělat pro 100 databází.

Myslím, že ostatní plakáty přinesly několik vynikajících bodů, takže jsem je nechtěl překonat.

0