[Holmgren]

Absolut en databas, korrekt strukturerad.

[Johnny Viking]

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!

[danjel]

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.

[yakuzaemme]

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

[Johnny Viking]

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.

[najk]

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.

[danjel]

Ursprungligen postat av Johnny Viking

Danjel, WordPress MU lägger bara till nya tabeller för varje ny sajt..

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.

[Johnny Viking]

Ursprungligen postat av najk

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.

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.

[Conny Westh]

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.

[Johnny Viking]

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?