PSD-Tutorials.de
Forum für Design, Fotografie & Bildbearbeitung
Tutkit
Agentur
Hilfe
Kontakt
Start
Forum
Aktuelles
Besonderer Inhalt
Foren durchsuchen
Tutorials
News
Anmelden
Kostenlos registrieren
Aktuelles
Suche
Suche
Nur Titel durchsuchen
Von:
Menü
Anmelden
Kostenlos registrieren
App installieren
Installieren
JavaScript ist deaktiviert. Für eine bessere Darstellung aktiviere bitte JavaScript in deinem Browser, bevor du fortfährst.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen
alternativen Browser
verwenden.
Antworten auf deine Fragen:
Neues Thema erstellen
Start
Forum
Sonstiges
Webdesign, Webentwicklung & Programmierung
PHP, Javascript, jQuery, Ajax, nodeJS, MySQL...
User DatenbankEN ..
Beitrag
<blockquote data-quote="Duddle" data-source="post: 1115751" data-attributes="member: 17775"><p><strong>AW: User DatenbankEN ..</strong></p><p></p><p>Kurze "hör nicht zwingend auf mich"-Erklärung: Folgendes beruht nur auf Instinkt und ersten Ideen, nicht theoretischem oder praktischem Wissen mit einem wie von dir beschriebenen System.</p><p></p><p>Mein erster Kritikpunkt wäre, dass dieses System ab 12k Benutzern (um mal bei den beispielhaften Zahlen zu bleiben) komplizierter zu implementieren wird. Oder willst du aller 3k Benutzer einen neuen Server hinstellen? Wenn nicht, wie willst du es richtig aufteilen? Ist 3k die richtige Grenze, 4k oder doch nur 2k pro Server?</p><p></p><p>Zweitens: was passiert, wenn einer der Server ausfällt? Dann können plötzlich 3k Nutzer nicht mehr das System benutzen. Klar, es gibt Failback- / Ausweichserver, aber dann verdoppelt sich sofort die Anzahl der benötigten Server, Anschlüsse usw.</p><p></p><p>Drittens: das soll sicherlich eine relationale Datenbank werden und es wird sicher Beziehungen zwischen den Entitäten geben. Diese Beziehungen sind aber sehr viel schwieriger einzuhalten wenn die Bezugsdaten (im Beispiel die benutzerbezogenen Daten) auf X Server verteilt sind. Dadurch wirst du, besonders bei komplexeren JOINs, schätzungsweise einiges an Performance verlieren. Ausserdem muss dann auch dein Datenbanksystem diese Teilung unterstützen und ich vermute solch ein größeres Feature hat nicht jedes DBMS.</p><p></p><p>Das sind nur erste Gedanken, die für mich deinen Ansatz schon sehr fragwürdig erscheinen lassen. Sehr gern lasse ich mich aber von erfahreneren Leuten mit ein paar Links oder Hands-On-Erfahrung vom Gegenteil überzeugen.</p><p>Mein absolut aus der Luft gegriffener Vorschlag wären daher zwei replizierte DB-Server (die jeweils ein Hot-Standby haben) und entweder per Load-Balancing oder ortsbezogen ausgewählt werden. Dann haben alle Server die gleichen Daten (lies: Relationen bleiben erhalten), ausfallende Server werden abgefangen und es skaliert besser (mehr Benutzer = mehr RAM einbauen).</p><p></p><p>Insofern: falls du dir unsicher ob deines Entwurfs bist, und deine Frage legt das nah, solltest du dir echtes Fachwissen anlesen oder es dir einkaufen. Wenn dein Projekt wirklich so groß wird wie du es erwartest ist ein DB-Experte sicher im Budget drin.</p><p></p><p></p><p>Duddle</p></blockquote><p></p>
[QUOTE="Duddle, post: 1115751, member: 17775"] [b]AW: User DatenbankEN ..[/b] Kurze "hör nicht zwingend auf mich"-Erklärung: Folgendes beruht nur auf Instinkt und ersten Ideen, nicht theoretischem oder praktischem Wissen mit einem wie von dir beschriebenen System. Mein erster Kritikpunkt wäre, dass dieses System ab 12k Benutzern (um mal bei den beispielhaften Zahlen zu bleiben) komplizierter zu implementieren wird. Oder willst du aller 3k Benutzer einen neuen Server hinstellen? Wenn nicht, wie willst du es richtig aufteilen? Ist 3k die richtige Grenze, 4k oder doch nur 2k pro Server? Zweitens: was passiert, wenn einer der Server ausfällt? Dann können plötzlich 3k Nutzer nicht mehr das System benutzen. Klar, es gibt Failback- / Ausweichserver, aber dann verdoppelt sich sofort die Anzahl der benötigten Server, Anschlüsse usw. Drittens: das soll sicherlich eine relationale Datenbank werden und es wird sicher Beziehungen zwischen den Entitäten geben. Diese Beziehungen sind aber sehr viel schwieriger einzuhalten wenn die Bezugsdaten (im Beispiel die benutzerbezogenen Daten) auf X Server verteilt sind. Dadurch wirst du, besonders bei komplexeren JOINs, schätzungsweise einiges an Performance verlieren. Ausserdem muss dann auch dein Datenbanksystem diese Teilung unterstützen und ich vermute solch ein größeres Feature hat nicht jedes DBMS. Das sind nur erste Gedanken, die für mich deinen Ansatz schon sehr fragwürdig erscheinen lassen. Sehr gern lasse ich mich aber von erfahreneren Leuten mit ein paar Links oder Hands-On-Erfahrung vom Gegenteil überzeugen. Mein absolut aus der Luft gegriffener Vorschlag wären daher zwei replizierte DB-Server (die jeweils ein Hot-Standby haben) und entweder per Load-Balancing oder ortsbezogen ausgewählt werden. Dann haben alle Server die gleichen Daten (lies: Relationen bleiben erhalten), ausfallende Server werden abgefangen und es skaliert besser (mehr Benutzer = mehr RAM einbauen). Insofern: falls du dir unsicher ob deines Entwurfs bist, und deine Frage legt das nah, solltest du dir echtes Fachwissen anlesen oder es dir einkaufen. Wenn dein Projekt wirklich so groß wird wie du es erwartest ist ein DB-Experte sicher im Budget drin. Duddle [/QUOTE]
Bilder bitte
hier hochladen
und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.
Zitate einfügen…
Authentifizierung
Wenn ▲ = 7, ▼ = 3, ◇ = 2 und die Summe von ▲ und ▼ durch ◇ geteilt wird, was ist das Ergebnis?
Antworten
Start
Forum
Sonstiges
Webdesign, Webentwicklung & Programmierung
PHP, Javascript, jQuery, Ajax, nodeJS, MySQL...
User DatenbankEN ..
Oben