Database design - flere?

Tags:    php

Hej folkens.

Jeg arbejder på et system, hvor hver kunde skal have "deres egen" applikation - altså kunderne skal kun se deres egne data. Systemet indeholder fortrolig information som arbejdstimer, noter, ordre, kunder osv.

Jeg overvejer hvordan jeg skal designe databasen, til at kunne håndtere "separate" kunder. Jeg har overvejet at lave en database til authentication (brugernavne, passwords og reference til egen database), og derudover skal hver kunde have sin egen database. Grund til at jeg overvejer dette er for at opveje sikkerheden, for at minimere riskoen for fejl i systemet, kan bevirke at fortrolige informationer bliver offentliggjort?. En anden grund til at jeg overvejer denne løsning er for at mindske kunne indexere mest optimalt - Alternativt kunne man jo have et felt i hver tabel: agreement_id ?

Hvordan ville i bygge en sådan database op ? (hver kunde kan sagtens have +30.000 records)



8 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 7 karma
Sorter efter stemmer Sorter efter dato
Jeg ville så vidt muligt nøjes med at have 1 database. Det kan være en meget stor administrativ byrde at vedligeholde en masse seperate databaser. Hver gang der skal laves databaseændringer skal man sørge for at ændringerne udføres korrekt på alle databaser.

Det burde ikke være et meget stort problem at have flere kunders fortrolige data i samme database. Men det kræver selvfølgelig at man er opmærksom på hvem der må se hvilke data igennem hele udviklingsprocessen og sørge for at teste det ordenligt. Nogle automatiserede tests er nok en god ide.

Ofte behøver man ikke have et "agteement_id" på alle tabeller, kun de aller mest centrale. Ofte viser det sig, at der er mange tabeller, som bare har en fremmednøgle til en tabel der har et "agreement_id" og derfor er det ikke nødvendigt at have feltet på disse tabeller.

30.000 records * 1000 kunder er kun 30.000.000 records. Det er ikke noget problem for en fornuftig server.




En fremmednøgle er vist nok bare et id der relaterer til en id i en anden tabel. Som jeg har forstået det er det ikke noget sjældent syn i databaser.

F.eks. du har en tabel over kunder, hver kunde har en id blandt andet.

Du har også en tabel med ordrer. Hver ordre har en ide. Men samtidig har hver ordre måske og en fremmednøgle til tabellen over kunderne. Dvs. din tabel med ordrer har en kolonne hvor der id'et på den pågældende kunde står. Så hvis du vil have fat i kundeinformationen om en bestemt ordre finder du ordren og bruger denne fremmednøgle til at finde kunden.

En eller anden, korrekter mig hvis jeg er forkert på den.



Indlæg senest redigeret d. 26.10.2009 17:08 af Bruger #14645
Okay, tak for din respons.

Du taler om en fremmednøgle til en tabel? hvordan skal dette forstås? - det lyder interresandt? vil du måske uddybe din tanke?

Serveren er en EQ4 fra hetzner, der hoster ganske få andre sites (meget små), og regner skam ikke med at have flere end 10-100 kunder som start ;)



Hvad Søren skriver lyder meget rigtigt. En foreign key er en reference til en anden tabel. Fx. hvis du har en Agreement tabel med et id og en tabel Orders med et felt agreement_id, så er feltet agreement_id en reference (eller fremmednøgle) til tabellen Agreement. Hvis opsat korrekt, sørger fremmednøglen for at de records som Orders refererer via agreement_id eksisterer i tabellen Agreement. Det sikrer en god datakvalitet.

Se evt http://en.wikipedia.org/wiki/Foreign_key

Hvilken type database vil du bruge (MySQL, Postgres, MSSQL, Oracle mv.)?



MySQL - ja har selv været inde og læse om det, og er også kommet frem til foreign key idéen.. Det lyder meget interresandt. Jeg bygger systemet oven på Zend Framework 1,9.. Søger rundt for, at se hvordan det bruges af andre :) der er allerede kommet et par Aha oplevelser :)

Er der noget specifikt med MySQL du tænker på?



Du skal være opmærksom på at for at bruge foreign keys i MySQL, skal du oprette alle dine tabeller som InnoDB-tabeller.



Okay tak, Kim - det havde jeg ikke lige spottet.

Er det simpelthen muligt at definere "relations" direkte i databasen?

Sidder på nuværende tidspunkt og tænker over hvordan jeg bedst mulig indtaster information, som har relationer: eksempel:

Tabel: agreements
Tabel: orders (har foreign key: agreement_id)
Tabel: orderhours (har foreign key: order_id)
Tabel: orderfiles (har foreign key: order_id)
osv.

Jeg sidder jo som beskrevet på MVC platform (ZF1.9) - har fået lavet modellerne, sådan de hænger sammen, og dette går fint, når der skal trækkes data ud.. Men når jeg så skal "dybdeindsætte" en record i tabellen orderhours, begynder den at knibe? (men dette er self. ZF relevant.) -

Jeg takker i hvert fald, for den info i allerede har givet mig.!




For at indsætte rækker i orderhours er der nødt til at være mindst én række i orders som orderhours kan pege på. Ellers hænger databasen ikke sammen. Hvis man har mange led i sine relationer, kan det desværre blive svært at sætte realistiske data op i forbindelse med test.

Hvis du gerne vil have at jeg kigger på noget af din kode og kommer med gode råd, så er du velkommen til at skrive til mig på e-mail. (jeg går ud fra man kan se min e-mail-adresse ved at klikke på mit navn).



t