Felles database for mange kunder/bedrifter..

[nilsh]

Heisann!

 

Skal utvikle en web-basert(php,mysql) tjeneste for mange bedrifter..

Står mellom valget å ha en database for hver bedrift kontra en felles for alle bedrifter. Blir vel mindre vedlikeholdsarbeid og lettere administrasjon i den sistenevnte løsningen.

 

Jeg lurer på hva som er vanlig praksis på dette med felles database for mange kunder/bedrifter.. Hvis jeg har 500 kunder/bedrifter som igjen har 2000 kunder hver som igjen har i gjennomsnitt 2 produkter hver. I kundetabellen blir det da 1 million kunder, mens i produkttabellen 2 millioner produkter.. Skilles bedriftenes kunder og kundenes produkter til de forskjellige bedriftene ganske enkelt med en kolonne i hver tabell som heter "bedriftId" f.eks..?

Endret 1. desember 2009 av nilsh

[MikkelRev]

Så du tenker å ha samme fysiske produktdatabase for både Rema, Hennes & Mauritz og Peugeot? Hvorfor egentlig? For å spare tid?

Ser for meg at du på sikt gjør deg en bjørnetjeneste...

[quantum]

Så du tenker å ha samme fysiske produktdatabase for både Rema, Hennes & Mauritz og Peugeot? Hvorfor egentlig? For å spare tid?

Ser for meg at du på sikt gjør deg en bjørnetjeneste...

Ser for meg at han på sikt gjør seg selv en helt vanlig tjeneste på det viset, jeg da.

 

Men dette er jo bare synsing. Umulig å si hva som er best bare utfra det som er beskrevet.

 

Her er noen argumenter:

 

Å vedlikeholde 500 databaser er en stor jobb i seg selv. Når du f.eks. skal legge til et felt i en tabell med flere mill. rader tar det laaaaang tid (MySql). Har du 500 mindre tabeller i 500 databaser å forholde deg til går seff jobben raskere pr. tabell ... meeen, ikke sikker på om det i sum blir noe mer behagelig, nei.

 

Dersom du er nødt til å duplisere data (kunder og produkter) i de ulike bedriftsdatabasene så har du ennå en vedlikeholdsoppgave som er større enn den trenger å være.

 

Dersom du lagrer alt i en database så må applikasjonen sørge for at bedriftene ikke får tilgang til hverandres data. Dersom det er ekstremt viktig å overholde dette - f.eks. av personvernshensyn osv - så kan det være et argument for å dele opp, da blir det fysisk umulig å blande korta. På den annen side er dette ikke rocket-science, så dersom det er spørsmål om applikasjonslogikken blir for kompleks når den skal holde orden på alle bedriftene, så ser det vel også mørkt ut for logikken som skal passe på at kundene ikke får blanda sammen produktene sine også? Det er akkurat samme problemstilling ... og den må håndteres uansett.

 

Oracle har svjv funksjonalitet som løser akkurat dette.

[kaffenils]

Bedrifter er dessuten vekldig glade i sine data, og vil nødig noe som helst pga manglende ACID støtte i DBMS. Hvor godt kjenner du egentlig MySQL siden du tror at det er veldig smart å benytte MySQL til dette. Hvilken storage engine tenkte du egentlig på. Du kan fort få noen søksmål eller i beste fall VELDIG SURE kunder på nakken hvis du mister data. Private bedrifter leker ikke butikk, og med mindre du har tenkt å benytte deg av MaxDB så bør du kanskje revurdere hele MySQL delen i dette prosjektet.

Endret 1. desember 2009 av kaffenils

[quantum]

Bedrifter er dessuten vekldig glade i sine data, og vil nødig noe som helst pga manglende ACID støtte i DBMS. Hvor godt kjenner du egentlig MySQL siden du tror at det er veldig smart å benytte MySQL til dette. Hvilken storage engine tenkte du egentlig på. Du kan fort få noen søksmål eller i beste fall VELDIG SURE kunder på nakken hvis du mister data. Private bedrifter leker ikke butikk, og med mindre du har tenkt å benytte deg av MaxDB så bør du kanskje revurdere hele MySQL delen i dette prosjektet.

Det kommer igjen *helt* an på hvaslags data vi snakker om her. MySQL m. InnoDB funker til formålet (snakker av erfaring), men ville ihvertfal passa på at jeg var på versjon 5+. *Ideelt sett* ville jeg hverken brukt mysql eller php, men det er vel en annen problemstilling.

[kaffenils]

Det kommer igjen *helt* an på hvaslags data vi snakker om her. MySQL m. InnoDB funker til formålet (snakker av erfaring), men ville ihvertfal passa på at jeg var på versjon 5+. *Ideelt sett* ville jeg hverken brukt mysql eller php, men det er vel en annen problemstilling.

Trådstarter nevner kunderegister og produktregister. Slike data må være HELT trygge (lagringsmessig). InnoDB fungerer ikke tilfredsstillende til dette ut av boksen da det ikke garanterer full ACID (garanterer ikke Durability).

Ref:

http://dev.mysql.com/doc/refman/5.1/en/binary-log.html

By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost.

 

 

MyISAM nevner vi selvfølgelig ikke i dette prosjektet.

[quantum]

Det kommer igjen *helt* an på hvaslags data vi snakker om her. MySQL m. InnoDB funker til formålet (snakker av erfaring), men ville ihvertfal passa på at jeg var på versjon 5+. *Ideelt sett* ville jeg hverken brukt mysql eller php, men det er vel en annen problemstilling.

Trådstarter nevner kunderegister og produktregister. Slike data må være HELT trygge (lagringsmessig). InnoDB fungerer ikke tilfredsstillende til dette ut av boksen da det ikke garanterer full ACID (garanterer ikke Durability).

Ref:

http://dev.mysql.com/doc/refman/5.1/en/binary-log.html

By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost.

 

 

MyISAM nevner vi selvfølgelig ikke i dette prosjektet.

 

Fortsatt enig i at MySQL ikke er drømmedatabasen, men ... out of the box, skriver du? Du ville vel ikke bruke en out-of-the-box-versjon av *noen* database til et prosjekt med så viktige data som du snakker om?

 

Binærloggen til MySQL kan - iflg. manualen du viser til - gjerne være i sync ... med filsystemet ... som kanskje er i sync med disken, det blir et spørsmål om konfigurasjon av database og os ... uansett.

 

Det viktigste å få på plass er kundens krav til oppetid og data-integrietet og sikkerhet, samt avtaler om hva applikasjonen skal klare på disse områdene.

 

MySQL kan fint holde styr på trusebeholdningen til H&M, men det er nok en grunn til at det er Oracle som kjører i banken. Det koster penger å miste data, det koster penger å kjøre Oracle, spørsmålet er bare hva kunden vil betale. Mange vil ikke betale så mye ... og de fleste får sine behov tilfredsstillt likevel.

 

(innlegget er redigert)

Endret 1. desember 2009 av quantum

[kaffenils]

Det har kanskje ikke falt deg inn at man kan miste *hele* binærloggen og for ikke å snakke om databasen, konsistens eller ikke, dersom maskin og disk krasjer. Man må uansett til med redundans, og selvsagt backup, for å være sikker-som-banken. Antar sitatet du viser til reflekterer et valg man har gjort for å øke ytelsen på databasen. Hva om binærloggen blir synkronisert ved hver skriveoperasjon, og disken krasjer under denne synkroniseringen da? Da er du vel igrunnen fukad da også, selv om det er mindre sannsynlighet for at dette skal skje?

Selvfølgelig kan alt gå på trynet hvis hardware ryker, og en må restore fra backup.

Men MySQL er veldig sårbar for noe så enkelt som strømbrudd, noe Oracle og SQL Server ikke er.

 

Hvis en har tenkt til å bruke masse penger på dyr hardware for å oppnå optimal redundans, så skjønner jeg ikke hvorfor en ikke like godt dropper MySQL velger ett DBMS som faktisk er ACID, f.eks. Oracle eller SQL Server.

 

Det er selvfølgelig en fordel å jobbe med f.eks. Oracle isteden, men det *er* altså mulig å få det rimelig brukbart med MySQL også. Dette er *fullstendig* avhengig av kravene som kunden stiller og hvilke avtaler om stabilitet og sikkerhet man gjør, det koster penger å miste data, det koster penger å bruke Oracle.

Hvis kunden aksepterer faren for datatap så for all del, lek videre med MySQL, men jeg tror neppe du finner bedrifter som synes det er greit med datatap. Man kan selvfølgelig aldri sikre seg 100%, men det første en bør gjøre er å kvitte seg med MySQL.

[quantum]

Hvis kunden aksepterer faren for datatap så for all del, lek videre med MySQL, men jeg tror neppe du finner bedrifter som synes det er greit med datatap. Man kan selvfølgelig aldri sikre seg 100%, men det første en bør gjøre er å kvitte seg med MySQL.

 

Først, jeg redigerte beklageligvis innlegget mitt etter at du quota det, men poengene våre er stort sett de samme likevel.

 

Kunden gjør en kost-nytte-vurdering og velger løsning utfra behov, hvis han har vett i panna. Mener du seriøst at all verdens jalla-webshoper burde kjøre på Oracle? Det hadde selvfølgelig ikke vært meg i mot (og jeg er ikke engang oracle-partner), men jeg har ikke tenkt å holde pusten mens jeg venter på at det skal skje, for å si det sånn. Og i mellomtiden går verden videre, ikke minst ... vi *har* riktig nok en finanskrise, men den skyldes neppe utstrakt bruk av MySQL.

 

Hovedpoenget må være at om man ikke har noen anelse om hvordan man skal forholde seg til disse problemstillignene i det heletatt, så hjelper det lite med Oracle eller SQL Server.

[kaffenils]

Kunden gjør en kost-nytte-vurdering og velger løsning utfra behov, hvis han har vett i panna. Mener du seriøst at all verdens jalla-webshoper burde kjøre på Oracle? Det hadde selvfølgelig ikke vært meg i mot (og jeg er ikke engang oracle-partner), men jeg har ikke tenkt å holde pusten mens jeg venter på at det skal skje, for å si det sånn. Og i mellomtiden går verden videre, ikke minst ... vi *har* riktig nok en finanskrise, men den skyldes neppe utstrakt bruk av MySQL.

Hvis en jalla-webshop synes det er greit å miste/ødelegge bestillinger så må de gjerne det for meg, men jeg er ikke kunde hos noen som roter med slikt. En feil, og jeg er ikke kunde hos dem lenger.

 

Hovedpoenget må være at om man ikke har noen anelse om hvordan man skal forholde seg til disse problemstillignene i det heletatt, så hjelper det lite med Oracle eller SQL Server.

Jo, for Oracle og SQL Server har full ACID støtte by default, ikke "wannabe" ACID støtte slik som InnoDB. Jeg er nemlig agnske overbevist om at veldig mange som bruker MySQL tror at når de har COMMITet så er data trygt skrevet til disk.

[nilsh]

Hei igjen, og takk for innspill!

 

Er klar over at mysql og php ikke er det sikreste valget.. Det er bare det at det først var kun en bedrift som ønsket seg dette, og da var det ikke særlig problem. Systemet er stort sett ferdig til bruk. Tenkte derfor å bare videreutvikle det til å gjelde for flere bedrifter.

 

Bedriftene det er snakk om har ikke stor forstand på IT for å si det sånn. Så de er ikke i stand til å sette krav på tekniske aspekter. Informasjonen som blir lagret er ikke veldig sensitiv sett bort i fra at det kan være konkurrerende bedrifter som har kundene sine lagret. Verste som kan skje er vel at de stjeler serviceoppdrag til hverandre, hehe!

 

MikkelRev, hvorfor mener du jeg gjør med en bjørnetjeneste ved å klaske alle bedriftene sammen..?

Endret 1. desember 2009 av nilsh

[kaffenils]

Bedriftene det er snakk om har ikke stor forstand på IT for å si det sånn. Så de er ikke i stand til å sette krav på tekniske aspekter.

Jeg synes ikke det er noe argument for å "lure" dem til å lagre sine data i MySQL. Du må da "senke" deg til kundens nivå og diskutere krav og forventninger på dette nivået. Dessuten synes jeg ACID er et krav som kun kan fravikes hvis kunden eksplisitt tillater det.

[cruzader]

Hvis en jalla-webshop synes det er greit å miste/ødelegge bestillinger så må de gjerne det for meg, men jeg er ikke kunde hos noen som roter med slikt. En feil, og jeg er ikke kunde hos dem lenger.

ser ikke helt sammenhengen mellom miste/ødelegge bestillinger og bruke mysql?

jeg har ihvertfal ikke fått med meg det kravet i mysql at du ikke kan ha noe datasikkerhet for og bruke deres system....

[nilsh]

Bedriftene det er snakk om har ikke stor forstand på IT for å si det sånn. Så de er ikke i stand til å sette krav på tekniske aspekter.

Jeg synes ikke det er noe argument for å "lure" dem til å lagre sine data i MySQL. Du må da "senke" deg til kundens nivå og diskutere krav og forventninger på dette nivået. Dessuten synes jeg ACID er et krav som kun kan fravikes hvis kunden eksplisitt tillater det.

 

Det ble formulert litt dumt av meg.

Tenker på det økonomiske også, hva vil det koste meg å bruke f.eks. oracle..? Det er et forholdsvis lite system, maks 10 tabeller vil jeg tro.

[kaffenils]

ser ikke helt sammenhengen mellom miste/ødelegge bestillinger og bruke mysql?

jeg har ihvertfal ikke fått med meg det kravet i mysql at du ikke kan ha noe datasikkerhet for og bruke deres system....

At nesten ingen har fått det med seg betyr ikke at problemet ikke finnes. Det står svart på hvitt i dokumentasjonen:

By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost.

La oss se på hva dette betyr i webshop eksempelet ditt:

Jeg lager en bestilling, klikker bekreft bestilling og får en bekreftelse på at bestillingen en godkjent/bekreftet/lagret. Gode greier tenker jeg og lukker siden. Det jeg ikke vet er at 1 sekund etter at jeg ble videresendt til websiden med bekreftelse så krasjet mysql-servicen hos leverandøren og min COMMIT var ikke skrevet til transaksjonsloggen og heller ikke var endringene skrevet til tabellene. Min bestillingsbekreftelse er derfor sporløst forsvunnet. Jeg får ikke vite om det, og sannsynligvis får heller aldri leverandøren vite om det.

Det finnes mange ting som kan gå galt i dette scenarioet. Så lenge MySQL ikke logger hver eneste skriveoperasjon i det de skjer, så står du i fare for å miste data ved eventuell krasj.

[kaffenils]

Det ble formulert litt dumt av meg.

Tenker på det økonomiske også, hva vil det koste meg å bruke f.eks. oracle..? Det er et forholdsvis lite system, maks 10 tabeller vil jeg tro.

Er kunden(e) klar over hvordan valget du har gjort kan påvirke konsistensen for deres data? Og er i så fall det greit for dem? Jeg synes de har krav på å vite hvilke konsekvenser dine tekniske valg kan ha for dem.

[cruzader]

eller i et mer realistisk eksempel:

ordren ble ikke skrevet til hoveddatabasen men ligger fortsatt trygt i database nr2 (evnt nr3 ettersom hvor høyt feilterskelen skal settes), samt en kopi ligger i inboxen til butikken.

ordren din blir så desverre en dag forsinket før sendt og du får gjerne noen kroner avslag på neste ordre.

 

selv de mest jalla gratis butikkscriptene lar deg skrive mot flere databaser samt sende ordren rett i printspool eller mail for kopi.

Endret 1. desember 2009 av cruzader

[kaffenils]

eller i et mer realistisk eksempel:

ordren ble ikke skrevet til hoveddatabasen men ligger fortsatt trygt i database nr2 (evnt nr3 ettersom hvor høyt feilterskelen skal settes), samt en kopi ligger i inboxen til butikken.

ordren din blir så desverre en dag forsinket før sendt og du får gjerne noen kroner avslag på neste ordre.

Denne har jeg hørt før, og synes den er fantastisk morsom. Det du sier er at i stedet for å velge et DBMS som garanterer full ACID så skal du sette opp et komplisert og ressurskrevende system for speiling av databasen. Hvordan vet du at databasene er i sync med master? Eller hadde du tenkt at min "Bekreft bestilling" skulle åpne connection og skrive til flere servere? For skikkelig å bekrefte MySQLs "styrke" så foreslår du at vi bruker SMTP for å quadruppellagre informasjonen som vi ikke stoler på at MySQL kan ta seg av. WhaM bam thank you mam! MySQL ROCKS!!!

 

Ville det ikke være billigere å benytte seg et skikkelig DBMS?

[cruzader]

bra du synest den er morsom da, så slapp du kjede deg i hele dag!

jeg tenkte mer i forhold til jalla butikker som var nevnt over enn hva jeg ville valgt, at det ikke er optimalt skjønner vel alle.

mysql er gratis og ganske universalt støttet av hosts, de scripts jeg har testet av mysql for webbutikker dumper ordrene i 1-2backup databaser i tilfelle problemer med første så kontrolleres det daglig om der er noen ordre ikke i hoveddatabasen så importerer om mangler.

 

om du har forslag til like "universalt støttet" og gratis system så kan du vel opplyse folket om noen evnt leser tråden i ettertid på jakt etter det

Endret 1. desember 2009 av cruzader

[nilsh]

Med servere med 99,95 % oppetid.. er dette i realiten et problem..?

 

Men uansett, Noen som vet hva det vil koste meg å opprette og drifte dette i f.eks. oracle..?