MSSQL Server mit 100 Clients

[jobo]

Zitat von egentur:

Wenn der ReplikationsDienst einen Datensatz übertragen soll, sucht und löscht er diesen anhand des PK (GUID) und schreibt dann den Datensatz neu in die Ziel DB.

Das ist jetzt aus Sicht MSSQL Server > Oracle Client DB?
Oder umgekehrt?

Wichtig bei diesen Problemen ist tatsächlich, wie es im Detail abläuft (Verfahren wie beschrieben z.B. "suchen,löschen, neuschreiben") und die Technik dafür (Siehe meine Fragen zuvor).
Wenn es tatsächlich auf Lock Escalation Effekte hinausläuft, ist natürlich auch die Frage, welche Datenmengen / Stückzahlen übertragen werden von den (bereits bekannten) 100 Clients.

Zurück zum Zitat:
Delete ist verhältnismäßig sehr teuer. Moderne DB können entsprechend konfiguriert werden, dass gewisse Aktionen quasi bevorzugt werden. Das ist in Standardkonfigurationen NICHT "delete". Hier spielen dann auch Fragen wie Anzahl von Indizes, Ref constraints und Cascade Constraints Regeln z.B. "on delete cascade" eine Rolle.
Kurz, man will vielleicht kein Delete sondern eher ein Update.
Oder nicht mal ein Update, sondern nur ein Insert mit nachführung eines "Aktiv" oder "Last" Flag.

Grundsätzlich bei Messwertaufnahme geht es ja in Richtung Big Data. Da wird nicht unbedingt filigran gearbeitet, sondern stumpf geschrieben. "Schau mal, ob es das schon gibt und dann lösch das und trag es schick neu ein." ist je nach Lastsituation / Ausstatung nicht das, was man sich erlauben kann.

Eigentlich wird primär darauf geachtet, keine Daten zu verlieren. Im nächsten Schritt wird dann in einem separaten System gefiltert, aggregiert, ..

[p80286]

Ich verstehe die Vorgehensweise nicht.
Ein Messwert (oder mehrere) wird zu einem Zeitpunkt erfasst und in einer lokalen Datenbank gespeichert. Irgendwann verbindet sich die lokale Datenbank mit der zentralen Datenbank und
löscht den/einen Datensatz und fügt ihn danach in die zentrale Datenbank ein.

Da jeder Datensatz durch die Meßstation und den Zeitpunkt charakterisiert ist, dürfte ein beliebiger Datensatz, der noch nicht übertragen wurde, nicht in der zentralen Datenbank vorhanden sein. Warum also sollte ich den Datensatz löschen wollen?
Will ich z.B. nur die Daten der letzten 24 Stunden auf dem zentralen Server haben, dann kann man unabhängig vom Client bei Gelegenheit die überflüssigen Datensätze löschen.

Gruß
k-H

[jobo]

Zitat von p80286:

Ich verstehe die Vorgehensweise nicht.

Da jeder Datensatz durch die Meßstation und den Zeitpunkt charakterisiert ist, dürfte ein beliebiger Datensatz, der noch nicht übertragen wurde, nicht in der zentralen Datenbank vorhanden sein. Warum also sollte ich den Datensatz löschen wollen?

Ich versteh das "Delete" auch nicht. Wenn es um "klassische" Messwertaufnahme geht, halte ich Deinen Einwand für sehr berechtigt. Daher hab ich ja auch vorgeschlagen, darauf zu verzichten.
Ich verstehe es momentan so: Es ist anhand des Ablaufs anscheinend eben keine reine Messwertaufnahme, was es sonst sein könnte, ist mehr oder weniger Spekulation.

Vielleicht ist es der Versuch einer Umsetzung des BDSG neu, Abschnitt "Datensparsamkeit"

[arnof]

Zitat von Bernhard Geyer:

Zitat von Uwe Raabe:

Ein Sperren des Datensatzes zur Bearbeitung würde ich persönlich nicht realisieren. Das bringt mehr Probleme als es löst.

Es wird immer auf dem Anwendungsfall ankommen.
Wenn es normal ist das z.B. 1 Stunde auf einen Datensatz gearbeitet wird, wird man sich keine Freude machen, wenn der User erst nach 1 Stunde mitbekommt das seine Arbeit "für die Katz ist".
Ein Mergen der Änderungen wird für die meisten Nutzer zu komplex sein um Sie praktikabel zu Nutzen.

Man sollte es auch so einstellen, das nur die geänderten Felder gespeichert werden und auch nur hier nach einem Konflikt geschaut wird. D.h. in der Praxis können mehrere Personen den gleichen Datensatz bearbeiten. Einer macht den Katalogtext, der andere die Preise, der nächste vielleicht Bilder.

So kann man den Mehrbenutzerzugriff auch realisieren. Wenn natürlich mehrere User das gleiche Feld bearbeiten (z.B. Preis) und auch noch was unterschiedliches reinschreiben, dann ist das natürlich Sinnfrei .....

Ansonsten muss man das aus vom Datenbankaufbau berücksichtigen: z.B. Bemerkungen, hier könnten gleichzeitig mehrer Benutzer was reinschreiben wollen, dann muss man den aufbau z.B. über eine 1zun Beziehung machen ......