[DB] Allgemeine Frage zur Strukturierung

mercsen

Lt. Commander
Registriert
Apr. 2010
Beiträge
1.676
Moin moin liebe CB Gemeinde.

Ich habe eine frage zur allgemeinen Strukturierung meiner Datenbank.
Folgendes muss umgesetzt werden:

Ich arbeite an einem Programm mit dem man Projekte verwalten kann, den Projekten kann man Schichten und Mitarbeiter zuordnen etc. pp. eig uninteressant.
Das problem ist das verschiedene Niederlassungen dieses Programm benutzen können, z.b. eine in Hamburg und eine in Berlin. Keine Niederlassung darf auf die Daten der anderen zugreifen.
Die einfachste und für mich logischste Möglichkeit wäre es für jede Niederlassung eine eigene datenbank zu erstellen. So wären alle Daten schön säuberlich getrennt.
Zweite Möglichkeit wäre eine datenbank für alle Daten und einfach alle Tables zu kopieren und dem entsprechenden Präfix zu versehen. Z.B. hamburg_projekte, berlin_projekte, XXX_projekte.
Dann sind die Daten auch schön getrennt und alles läuft über eine einzige Zentrale DB.
Die dritte Möglichkeit wäre alles in eine DB zu quetschen und über Rechte den Zugriff auf die Daten zu limitieren. Allerdings habe ich da Bedenken das die Datenbank einfach zu schnell zu groß wird und die Abfragen irgendwann zu lange dauern weil zu viele Unwichtige Daten durchsucht werden müssen.

Was sind eure Erfahrungen ? Was wäre eurer Meinung nach die beste Lösung oder nehmen sich die 3 Varianten nicht viel ?
Ich würde die erste Methode vorziehen, allerdings erhöht das den Wartungsaufwand, denn sollte sich die DB STrucktur mal ändern muss man jede DB anpassen, das gleiche problem bei Möglichkeit 2. Allerdings ziehe ich eine strickte Datentrennung vor und bin deswegen von der 3. Möglichkeit wenig begeistert und weiß nicht weiter :(

Im voraus schon einmal ein Danke :)
 
hallo,

also ich bin jetzt kein profi in sachen DB, aber ich denke um es sauber und ordentlich zu trennen, würde ich schon deine 1. variante nehmen.

Bei der 2. Variante denke ich, dass es schwieriger wird, da jede Niederlassung auf der selben DB zugreifen, nur verschiedene Tables, da denke ich dass es auch zu hohe auslasstung kommt der DB? Weiss ja nicht genau wieviele auf der DB zugreifen pro Niederlassung und bei ausfällen der DB sind dann alle niederlassungen betroffen (wovon man ja nicht ausgeht *g)...

also ich denke 1. Variante wäre sinnvoller :)

MfG
 
Zuletzt bearbeitet: (rechtschreibfehler :P)
Das einzigst sinnvolle ist es über Rechte zu machen ... d.h. für jede Zeile gibst du an welche Niederlassung welchen Zugriff hat ... darauf baust du nun für jede Niederlassung eine View auf (falls dir das nix sagt .. nachlesen!).

Wegen der Performance -> Indexstrukturen (Wegweißer Strukturen) einbauen .. dann performen auch Mega Datenbanken ... auch mehrere Millionen / Milliarden Datensätze sind dann kein Problem.

Mehere Datenbanken pflegen ist .. sorry ... idiotisch ...
 
Ja das gibt es schon => Microsoft. Benutze MS Access und in wenigen Stunden hast du ein ausgereiftes Programm:
Hauptprogi für Aufnahme der Filialen
gesammtübersicht der einzelnen Filialen
%-Gegenüberstellung der Filialen
%-arbeitsleistung der Arbeiter und Projekte und und
Wünsche dir gutes gelingen.
 
MS Access ist nicht gerade der Performance bringer ... schau dir eine 'gescheite' Datenbank an wie die DB2 oder Oracle (PostgreSQL ist auch nicht schlecht ..)
 
kanal108 schrieb:
Das einzigst sinnvolle ist es über Rechte zu machen ... d.h. für jede Zeile gibst du an welche Niederlassung welchen Zugriff hat ... darauf baust du nun für jede Niederlassung eine View auf (falls dir das nix sagt .. nachlesen!).

Wegen der Performance -> Indexstrukturen (Wegweißer Strukturen) einbauen .. dann performen auch Mega Datenbanken ... auch mehrere Millionen / Milliarden Datensätze sind dann kein Problem.

Mehere Datenbanken pflegen ist .. sorry ... idiotisch ...

Ich denke die Variante ist die Beste von den bisher hier im Thread vorgeschlagenen!
 
ich qäre auch für die letzte genantn verfahren.

Dies geht aber glaube ich nicht bei MySQL, wenn es daher OS DB sein soll
musst du auf pgsql zurück greifen.
 
Ich habe mal Tools für eine DB entwickelt, da waren Daten von ca. 7 Firmen drin gespeichert. Und alle durften nicht die Daten der anderen sehen.
Sie haben kurzerhand überall, wo es wichtig war, eine Spalte MandantenID eingefügt, anhand derer man unterschieden hat, welche Tupel zu welcher Firma gehören.
 
Bitte nicht nach dem "Golden-Hammer"-Prinzip arbeiten und versuchen alles mit Access zu lösen. Access ist sobald es an größere Datenmengen und Multi-User Zugriff geht eine Krankheit keines gleichen!

Ich kann mich nur kanal108 und laurin anschließen. Für jeden Datensatz eine Spalte zu spendieren wäre denkbar. Man könnte alternativ auch über die Vergabe der IDs einen Hash-Algo anwenden. Fraglich ist in welchem Rahmen an Datensätzen man sich hier bewegt. Die Hash-Variante ist eher für kleinere Mengen an Daten was und das eingeschränkt auf wenige Tabellen, sonst bekommst du evtl. mit der referenziellen Datenintegrität Probleme, da die Berechnung des Hashs nicht mehr zuverlässig funktioniert.
 
Hallo.
Man, man, man, ich habe solange nicht mehr mit Datenbanken gearbeitet das ich die views total vergessen habe !
Muss leider mit MySql arbeiten, liegt aber zum Glück bereits in Version 5 vor, welche views unterstützt.

Allerdings erhöht das nun ein wenig den Programmier Aufwand, da Rechnungen ja z.B. immer eine Fortlaufende Nummer brauchen, das kann man nun nicht mehr über AI machen sondern muss das selber verwalten, es sei denn man macht für Rechnungen eigne tables / Niederlassung.
Aber das werde ich mir noch überlegen. Danke erstmal für diese rege Beteiligung :)
 
views an sich sind auch weniger dsa problem,
das problem sind updates und insert auf diese views,
da ist es mir nicht bekannt das es geht.
 
Nein das geht leider nicht, ist aber nicht ganz so wild da ich eh alles über eine eigne Klasse in die DB hämmere.
Dort wird aufgrund der information des eingeloggten Users entschieden zu welcher Niederlassung das gehört.

Schade das man keine constraints einbauen kann :(
 
AlbertLast schrieb:
views an sich sind auch weniger dsa problem,
das problem sind updates und insert auf diese views,
da ist es mir nicht bekannt das es geht.
auch views lassen sich updaten, einfach mal ins Manual schauen, geht aber nur unter bestimmten Vorraussetzungen ;)

AlbertLast schrieb:
klar kannst du nimm einfach innodb und nicht myisam
Du kannst in MySQL zwar Constraints in den SQL-Querys definieren (SQL-Keyword), das wird aber ignoriert, auch InnoDB hat keine Unterstützung für Constraints, bzw. nur für FK-Constraints.
 
Zurück
Oben