Hvordan vælges database ud fra login oplysninger

Hvorfor overhovedet bruge forskellige databaser?

hvilken server ligger det på?

du har vel én bruger på serveren pr. virksomhed.

hos mange webhoteller har man kun én database til rådighed, men går ud fra at du bruger noget andet end one.com, uoeuro og alle de andre "billige" hoteller?

Måske er det bare mig.. men jeg syntes at der er en større sikkerhed i at man ikke har et hav af tabeller med et virvar af navne. Derfor ønsket om en database pr virksomhed, med en ensartet tabelstruktur.

Det kan være at jeg selv opstiller en server i et datacenter for at opnå den fleksibilitet jeg ønsker.

Det er bare dig - det du skaber er bare 'security through obscurity' hvilket som oftest bare bider forfatteren i røven.

Du skal huske på at den bedste sikkerhed konsekvent vil være ikke at have tillid til dine brugeren - valider altid input - uanset anvendelse. Du kan dele dine tabeller op i nok så mange databaser; hvis nogen finder en vej ind er tilgængeligheden for dem den samme som for dig.

repox - foreslår du så at der oprettes et sæt tabeller for hver virksomhed, eller bare de samme tabeller og så en tabel der fortæller hvilke felter i tabellerne den enkelte virksomhed har adgang til??

Normalisering af databasen - altså, det sidste.
Du opretter tabeller der fortæller hvilke entries der tilhører hvilken virksomhed.

Ja.. det lyder som den løsning jeg havde håbet på at undgå.. Det kommer til at betyde en masse snask i mine queries.

Tak for hjælpen repox!

Jeg er lidt nysgerrig efter hvad du mener med 'snask'? Personligt ville jeg kun adskille databaserne, såfremt databaserne tjente forskellige formål. Men det er jo en og samme applikation du snakker om?

Forestil dig at skulle vedligeholde databasen for x antal kunder når du videreudvikler (videreudvikling er trods alt grundstenen i at beholde kunderne) - en ændring i en tabel (tilføjelse, rettelse eller lignende at et felt eller flere) ville betyde du skulle gøre det for hver af databaserne.

Jeg har en løsning med omkring 15 kunder - de bruger den samme database til denne applikation; disse kunder har endda logins til deres egne ansatte/brugere i samme løsning. Jeg skal kun rette et sted når jeg videreudvikler features.

I samme omgang, på arbejdet, har vi en løsning der hoster omkring 100 kunder. Denne løsning er fordelt på 5 databaser.
Hver af databaserne er fordelt henover nogle forskellige funktionaliter og muligheder; men her er det også nødvendigt at have udvikling på forskellige niveauer for at kunne videreudvikle.

Klart én database.

Du slipper ikke for "snask" i dine queries, bare fordi du isolerer kunderne i hver dares database.
- husk at langt det meste "datakriminalitet" er inside-jobs ~ Sælgere der "låner" hinandens kunder.

Jeg bøvler selv med et web-system der tilbyder funktionalitet til organisationer, og indenfor hver af disse, en bunke brugere.

Min løsning:
Når en person logger ind, lægger jeg to id'er i $_SESSION: OiD og UiD (meget store integers)

Og inden jeg foretager mig NOGET i databasen, sikrer jeg at de to id'er "hører sammen".

Derudover har jeg en "adgangs-tabel" med kun 2 felter: Ressource og iD (OiD / UiD)
- er det en OiD har alle tilhørende UiD'er adgang.

Og endelig 5 adgangsniveauer (for hver "ressource"):
Admin - Må ændre på brugeradgang - og er ellers Editor
Editor - Må oprette/ændre/slette alt
Author - Må oprette men kun ændre/slette egenoprettede
Reader - Må læse alt indenfor ORG (som ikke har specifik læse-adgang)
Poster - Må oprette nyt men ikke læse/ændre/slette (medmindre de har specifik læse-adgang)

Og for lige at sætte trumf på: brugergrupper - så man kan give adgang til mange på én gang.
- og fjerne alle sjoverens rettigheder ved at slette en enkelt flueben.

Ja, gu' det svært, men men der ER ingen let (og praktisk) vej udenom sikkerhed.
Måden at holde det ud på, er at benytte en håndfuld (testede) functions med meningsfyldte navne..

Jeg kan godt se jeres pointe!
Det jeg mener med 'snask' :-) er at man skal tjekke/skrive i en tabel der fortæller hvordan alt er kædet sammen med en virksomhed, hver gang noget skal gøres.
Det er da heller ikke skræmmende, men jeg havde håbet på at undgå det, nu hvor systemet virker til en virksomhed.

En virksomheds brugere har også adgang til at tilføje samarbejdspartnere med adgang til dele af systemet og de sager det indeholder.