Flera databaser eller en stor?
 

Hej! Jag har ett projekt på gång som kan mynna till flertalet kunder under delad scriptbas. Jag undrar dock, bör jag lägga allt i en stor databas, eller ska man dela upp det i flera databaser? En per kund alltså med tabeller för inställningar, kunder, data, osv.

Här är vad jag tror.

Flera databaser:
- Större säkerhet (?) i att en kund inte påverkar en annan, att data kommer på vift, eller att scriptfel inte kan påverka andra kunder
- Färre relationstabeller att hålla reda på
- Enklare SQL-queries = snabbare sajt

Endast 1 databas:
- Långsammare över tid ju mer data som det fylls på med? Förstås beroende på väl optimerade queries och indexar, dock ej expert på det området.
- Alla tabeller och script måste hålla reda på klient-ID för att få ut rätt data (troligen fler rader kod, och risker att tabba sig. Man vill ju inte att en kund ska se en annans data osv...)
- Uppdateringar av databaser, mer avancerat / mer jobb

Kom gärna med åsikter! Idel öra! :)

Förstår inte riktigt slutprodukten, kan du förklara lite mer? Vad är det du ska bygga upp?

Bokningssystem för ett företags kunder.

Jag tror du måste förklara lite mer än så, eller så är jag väldigt trött i skallen. Är tanken att databasen skall innehålla kunddata, inställningar för kunden osv? Isåfall tycker jag du kör på 1 databas. Det blir inte så speciellt mycket svårare queries, bara att säkerställa att varje query körs mot det kundID som är aktuellt.

Tänk på om du gör en ändring när du har 100 kunder och måste ändra alla dessa 100 databaserna?
Hade lätt kört på 1 databas.

Kanske går att abstrahera koden/arkitektur så du slipper hantera klientID för varje fråga, om du kör på 1 DB.

Jag rekommenderar 1 databas. Sedan om du ska skapa nya tabeller för varje kund eller ha få jättestora tabeller beror lite på.

Använder CodeIgniter och utnyttjar Active Record fullt ut så långt det går.

Just nu i utvecklingen så bygger jag sajten för 1 företag enbart. Det var lite så det började, men nu ser jag möjligheten att sälja det till fler, då det börjar bli väldigt bra. Det är inte tänkt att bli någon mainstream-produkt med sikte på storföretag, utan för mindre företag.

En stor nackdel med flera databaser är ju självklart att det blir mycket att underhålla. Men det är liksom bara ett par rader kod, att byta mellan databaser per kund (styrt av domäninloggningen).

Så att implementera att många ska röra sig i 1 databas är i det här skedet ett mycket större jobb än att välja att utgå från en ny databas med en grundsetup. Dock, är det ju inte alltid så bra att välja enklaste utvägen, om än att den är lockande just nu. :) Funderar på att bygga färdigt sajten till 99% (nog 60-70%) just nu. Det är många saker jag vill få klart först innan jag släpper för att bygga om själva koden.

CodeIgniter stödjer migrering, så det bör ju inte vara ett omöjligt jobb att i ett svep uppdatera flera databaser. Det handlar ju (förhoppningsvis) oftast bara om nya kolumner, och eventuellt flytta på lite data från ett ställe till ett annat. Om ens det.

Visst, ett alternativ vore ju flera tabeller. En per kund osv. Men då snackar vi ju en gigantisk tabelllista. Och jag hatar scrolla, haha!

Då ser jag det nästan enklare och smidigare att ha flera databaser. Det är ju nästan samma sak som att sprida upp det i många tabeller.

Jag hade nog också valt en databas. Det går att skala upp om behovet skulle uppstå och du kan dessutom lägga till lager mellan databas och kund.

Absolut en databas, korrekt strukturerad.

Oj! Tror jag bör lyssna i med att alla säger samma sak! :)

Kan ni ge lite erfarenheter och tipsa som jag kan ta med från första början när jag ska börja ombyggnationen för att hantera många kunder i en och samma databas? Vill gärna spara onödiga timmar och huvudvärk!

Jag skulle nog välja flera db som du beskriver ditt nuläge. Snabbare tid att komma igång.
Det är så WordPress MU sätter upp allt om jag inte missminner mig.
Det är inte så svårt att göra schema ändringar i alla db på en gång.

Säg att du har 2 tabeller, user och bookings

I 'user' har du userID, username, password, premium
userID - användarID - unikt för varje kund
username/password - credentials för varje kund
premium - påhittad kolumn, om kunden har premium-funktion (här kan du alltså ha inställningar)

I 'bookings' har du
bookingID
date
user

Där user är användarID (kundID kanske är bättre ord i detta sammanhang).

För att hämta ut alla bokningar gjord av kund 63, så gör du bara
SELECT * FROM bookings WHERE user=63

Vet ej om du kör på webben eller hur du gör, men du kan exempelvis sätta en global variabel till användarID, så du enkelt kan göra

SELECT * FROM bookings WHERE user='".$userID."'

Och för att installera din produkt hos kunder är allt du behöver göra att ändra i settings-filen för credentials

Yakuzemme, sådant där är inga problem. ;) Jag kan nog mer än jag gett bilden av.

Det jag efterfrågade med exempel var mer om det är problem som man ser bruka uppstå i när man ska skapa en potentiellt gigantisk databas av många företag och dess kunder. Pratar då säkerhet, prestanda, indexering, och kodoptimering m.m.

Danjel, WordPress MU lägger bara till nya tabeller för varje ny sajt. Dock klarar sig WU på 6-7 st tabeller, medan det här systemet jag byggt, redan är uppe i 25 tabeller för att styra allt. Det består då av kunduppgifter, användare, schema, kalendrar, medlemskap, betalssytem och dess loggar.

Själv röstar jag på flera databaser, tänk även på backup/historik, både för din del men även för dina kunder.

Ställ dig frågan om det är möjligt att återskapa enbart en kunds data om all data ligger i en tabell/databas. Troligtvis är det möjligt men hur krångligt är det att enbart ersätta den kundens data och inte röra någon annan data. Det kanske inte spelar någon roll nu i början, men när du har 100 kunder och 1 ringer och behöver återskapa hur det såg ut i fredags kväll, då är det guld värt.

Aha , ok.

Kolla gärna:
http://www.brentozar.com/archive/201...ent-databases/

Det är ju för övrigt mindre komplex kod och flöden att köra flera db. Annars måste man hela tiden hålla reda på client ID, i varje request och fråga.

Tack! Det där var något jag inte tänkt på än! Bara denna punkt är så pass stor och väger så tungt att det mycket väl blir flera databaser.

Den huvudvärk jag ser framför mig att hantera en återställning av en viss kunds data från en gigantisk databas där andra ligger live och inte ska påverkas... Nej tack!

Så i med CodeIgniter (och även andra MVC-ramverk) har migreringsstöd så är det ju väldigt "enkelt" att hantera uppdatering av databasstrukturen över flera databaser.

Det går givetvis att använda båda varianterna men om du ska sälja din lösning till flera kunder som kanske i slutändan har olika behov så är det en mer långsiktig och flexibel lösning att ha flera databaser.

Varje kund kan ha olika behov av backup-lösningar, en kanske vil ha backup en gång per dag medan en annan kanske vill ha backup en gång i timmen.

Du kanske får förfrågningar om att bygga ut systemet för en kund och då ska det naturligtvis inte påverka de andra kunderna.

Du har även aspekten med att lätta kunna flytta en kund till en störe server vid behov.

Din databasmotor har även begränsningar i sig som du måste ta hänsyn till.

Se dock till att du har en inbyggd service i ditt avtal med kunden om exempelvis uppraderingar till senaste version så du slipper underhålla gamla versioner av din applikation. Detta är viktigt att du har med från start annars kommer vissa kunder att backa och tycka att; "vi har det så bra så vi vill inte uppgradera".


Jag skulle nog rekommendera dig att bygga en lösning för flera olika databaser, om detta är en framkomlig väg.

Tänkte försöka husera alla under samma tak, alltså samma scriptbas. Vill inte hålla på med många olika versioner att hålla uppdaterade. Så för att slippa det här som du säger med att vissa gillar det som det är, eller "det var bättre förr" osv. Så jag ska försöka att göra produkten så färdig som möjligt innan den visas och sen försöka vara sparsam på förändringar.

Jag driftar även detta på en egen dedikerad server jag har för mina företagskunder jag har idag. Och blir det tungt, så köper jag in en ny server bara som blir dedikerad för bokningssystemet. Men jag tror det kommer klara sig utmärkt på en "delad" resurs upp till 10-20 kunder iaf. Det är ju endast bokningsdelen och inte hela hemsidorna för dessa företag.

Vad tänkte du förresten på angående begränsningar på det val av databasmotor jag har?

Jag kan se fördelar med olika databaser. Du kan fördela lasten och ha dedikerade maskiner per kund exempelvis. Du kanske har en kund som vill köra det själv etc.

Det går att låta scriptet automatiskt uppdatera databasen också utan större problem.

Ett annat alternativ man kan diskutera är att ha en databas men dela upp kunderna i separata namespaces.

Och med namespaces menar jag förstås scheman. Man kan på sätt och vis se scheman som databasernas motsvarighet till namespaces vilket förklarar att det slank igenom.

Beror helt på, är det samma grund applikation är det smidigare med 1 databas.

Men är det flera separat uppsättningar av applikation kan man lika väl köra separata DB, då får man vissa fördelar för anpassa unikt för 1 kund.

Men är det i grunden samma baskod/applikation för alla kunder känns det väldigt dåligt köra flera DB.

Idag går det skala DB väldigt kraftig, idag kan du köpa servrar med 4 x 16 core CPU och över 2TB ram. Känns inte precis problem med bygga en framtidssäker lösning där även med alla i 1 DB.

Som någon var inne på tidigare beror det väldigt mycket på om du vill kunna sälja specialanpassningar och/eller sälja licenser så att företag kan hosta sin lösning själva. Vill du bara sälja en standardiserad tjänst med lite enkla moduler eller adons är det förmodligen enklare med en databas.
Men om du vill kunna sälja mer specialanpassade system för vissa kunder kan det vara bra att separera både databas och kodbas.
Se bara till att du har en core-kod som är samma på alla varianter. Den här core-koden bör du sedan versionshantera med exempelvis git så att du kan pusha eller pulla uppdateringar till kundernas core-branches. Ovanpå detta kan du sedan ha submoduler som kan vara helt olika för varje kund.

Skala kan man göra utan problem oavsett lösning som patrikweb sa. Man kan även skala en MySQL databas horisontellt(flera servrar) med ett NDB-cluster även om det bara är en enda databas. Det är inte jättekomplicerat att sätta upp.

Det är mer jobb med flera Databaser men absolut ett bättre val.
Som flera varit inne på ur backup/restore, kundanpassning med mera.

Visst kan man skala upphårdvaran, men varför göra det om det inte behövs?
Självklart tar det längre tid att söka fram en bokning om du har 100 kunder med 20 användare och varje användare har 1000 bokningar efter några år (=2 000 000 poster i tabellen) jämfört med 100 databaser med 20 000 poster i tabellen samt att du slipper filtreringen på kundid. Det kommer gå åt mer prestanda för ett gemensamt system vilket gör behovet att skala upp hårdvaran kommer tidigare.

Då man som seriös utvecklare ändå har en testmiljö och färdiga produktionssättnignsscript går det lika lätt att köra de scripten på flera databaser som på ett enda. Du får desutom fördelen att kunna låta olika kunder betala serviceavtal för att alltid få senaste versionen medan andra kunder får stanna kvar på det gamla och efter några år betala klart högre uppdateringskostnad för att få alla uppdateringarna.

Lägger man sen till asopekten hur många hårddiskar det går åt för att ställa upp en ny MSSQL server enligt best practise e det klart billigare att behålla prestandan på en server och eventuellt komplettera emd någon enstaka disk.
Du kan dessutom öka prestandan massor genom att köra renodlat store procedures och även utnyttja CTE-tekniken och temptabeller på rätt sätt.
Själv hade jag en fråga (på typ 20 A4 sidor utskrivet) som byggde upp min slutkunds sortiment (Flera tusen kunder, hundra tusentals artiklar och alla har olika in och utpriser beroende på tidpunkter) som kördes varje natt och tog 4 timmar att köra. Efter två veckors finputsning av all SQL på exakt samma amskin och samma grunddata tar den körningen enbart 2 minuter idag. Ändå anser jag mig inte vara en expert på SQL, utan vill påvisa att man kan komma mycket långt enbart med att optimera sina egna saker...