Allgemeine Frage ERP Entwicklung

[johndoe049]

Also, ich habe heute noch jemanden beim Kunden erreicht. Eigentlich haben die bis Januar Betriebsferien.

Scheinbar ist die Datenspeicherung in zwei Punkten das Problem, warum keine ERP bisher gepasst hat.

In meinen Programmen verwende ich zwei verschiedene Datenbankserver, die synchron vom Client bedient werden D.h. der Client schreibt auf beide Datenbankserver und beim Lesen wird der Inhalt von einem Server mit dem anderen verglichen. Beim Ausfall eines Servers wird direkt auf den anderen umgeschaltet und über eine Serveranwendung werden die beiden Datenbankserver nach Reaktivierung des ausgefallenen Servers später wieder synchronisiert.

Das andere ist die von mir verwendete Signaturtechnik, mit der jede Datenzeile auf Echtheit und korrekte Speicherung bestätigt wird.

Wegen dem Tätigkeitsbereich verlangen die das jetzt auch in der ERP Software. Alle anderen Anforderungen sind diskutabel, nur die Datenspeicherung wird als nicht diskutabel eingestuft.

[michaelg]

Zitat von johndoe049:

Also, ich habe heute noch jemanden beim Kunden erreicht. Eigentlich haben die bis Januar Betriebsferien.

Scheinbar ist die Datenspeicherung in zwei Punkten das Problem, warum keine ERP bisher gepasst hat.

In meinen Programmen verwende ich zwei verschiedene Datenbankserver, die synchron vom Client bedient werden D.h. der Client schreibt auf beide Datenbankserver und beim Lesen wird der Inhalt von einem Server mit dem anderen verglichen. Beim Ausfall eines Servers wird direkt auf den anderen umgeschaltet und über eine Serveranwendung werden die beiden Datenbankserver nach Reaktivierung des ausgefallenen Servers später wieder synchronisiert.

Übernimmt z. B. MySQL nicht solche Aufgaben mit replizierten Servern?

[johndoe049]

Zitat von michaelg:

Zitat von johndoe049:

Also, ich habe heute noch jemanden beim Kunden erreicht. Eigentlich haben die bis Januar Betriebsferien.

Scheinbar ist die Datenspeicherung in zwei Punkten das Problem, warum keine ERP bisher gepasst hat.

In meinen Programmen verwende ich zwei verschiedene Datenbankserver, die synchron vom Client bedient werden D.h. der Client schreibt auf beide Datenbankserver und beim Lesen wird der Inhalt von einem Server mit dem anderen verglichen. Beim Ausfall eines Servers wird direkt auf den anderen umgeschaltet und über eine Serveranwendung werden die beiden Datenbankserver nach Reaktivierung des ausgefallenen Servers später wieder synchronisiert.

Übernimmt z. B. MySQL nicht solche Aufgaben mit replizierten Servern?

Zwei verschiedene Datenbankserver heisst in meinem Fall z.B. MySQL und Postgresql.

[Delphi.Narium]

Das Betonung auf "verschiedene Datenbankserver" liegt also nicht in der Menge der Datenbankserver, sondern auf "unterschiedliche Datenbanksysteme auf unterschiedlichen Servern"?

[johndoe049]

Zitat von Delphi.Narium:

Das Betonung auf "verschiedene Datenbankserver" liegt also nicht in der Menge der Datenbankserver, sondern auf "unterschiedliche Datenbanksysteme auf unterschiedlichen Servern"?

Richtig.

[TigerLilly]

Dann würde ich MSSQL und ORACLE nehmen, spiegeln und serverbasiertes Logging auf Zeileneben machen.

Aber ganz ehrlich und das soll nicht respektlos klingen: Wenn es solche Sicherheitsanforderungen gibt ist das Entwickeln einer so umfangreichen Software durch eine "kleine Quetschn" oder gar ein EPU doch eher ein NoGo. Da müsste doch ein Backup für den/die ProjektleiterIn und die Key-EntwicklerInnen gefordert sein, Zugriff auf den Source-Code und und und. Das ist ist für ehrlicherweise (ich hab auch schon mal was anderes behauptet) nicht zu stemmen.

[jobo]

Mmh, das ist natürlich auch eine Möglichkeit, ein Vendor Login zu vermeiden.

Dass der Client direkt in 2 Systeme schreibt, ist m.E. etwas exotisch. Das würde eher ein zentraler Wrapper machen. Aber letztlich ist man mit solch einem Vorgehen auch sehr nahe an einem online/offline System. Praktisch: der Client speichert so lange lokal, bis er eine online Connection findet. Ist natürlich eine Frage, wie flexibel die Clienttechnik zum Speichern/Lesen/Abgleichen ist.

[fisipjm]

Zitat von johndoe049:

Scheinbar ist die Datenspeicherung in zwei Punkten das Problem, warum keine ERP bisher gepasst hat.
Wegen dem Tätigkeitsbereich verlangen die das jetzt auch in der ERP Software. Alle anderen Anforderungen sind diskutabel, nur die Datenspeicherung wird als nicht diskutabel eingestuft.

Dann ist die Software in meinem vorherigen Post wahrscheinlich auch raus.

Was ist der Mehrwert dieser Vorgabe? Ohne jemand zu nahe treten zu wollen, aber die Entscheidung ist für mich absolut nicht nachvolziehbar, bringt keinen erkennbaren Vorteil/Mehrwert. Das normale Vorgehen für High Availability Systeme ist die bereits angesprochene DB synchronisation oder Spiegelung. Welcher Mehrwert ergibt sich aus 2 unterschiedlichen DB Systemen gleichzeitig? Außer faktor 2 in Wartung- und Entwicklungsaufwand, sowie 2 DB Systeme die je nach Anforderungen auch noch gegeneinander arbeitende Hardwareanforderungen mitbringen und für beide Systeme expertiese in Konfiguration, Backup und Performance optimierung erfordern?

Bin gerne lern bereit, aktuell sehe ich den Mehrwert noch nicht.

[johndoe049]

Zitat von fisipjm:

Zitat von johndoe049:

Scheinbar ist die Datenspeicherung in zwei Punkten das Problem, warum keine ERP bisher gepasst hat.
Wegen dem Tätigkeitsbereich verlangen die das jetzt auch in der ERP Software. Alle anderen Anforderungen sind diskutabel, nur die Datenspeicherung wird als nicht diskutabel eingestuft.

Dann ist die Software in meinem vorherigen Post wahrscheinlich auch raus.

Was ist der Mehrwert dieser Vorgabe? Ohne jemand zu nahe treten zu wollen, aber die Entscheidung ist für mich absolut nicht nachvolziehbar, bringt keinen erkennbaren Vorteil/Mehrwert. Das normale Vorgehen für High Availability Systeme ist die bereits angesprochene DB synchronisation oder Spiegelung. Welcher Mehrwert ergibt sich aus 2 unterschiedlichen DB Systemen gleichzeitig? Außer faktor 2 in Wartung- und Entwicklungsaufwand, sowie 2 DB Systeme die je nach Anforderungen auch noch gegeneinander arbeitende Hardwareanforderungen mitbringen und für beide Systeme expertiese in Konfiguration, Backup und Performance optimierung erfordern?

Bin gerne lern bereit, aktuell sehe ich den Mehrwert noch nicht.

Es geht nicht um HA. Es geht um die Authentizität der Daten. Im Kritis Bereich ist das von Vorteil.

Ein klassischen HA System mit 2x identischem Server hat das Problem, dass ein Programmfehler im Datenbankserver nicht wirklich auffällt. Bei verschiedenen Systemen fällt dies in der Theorie schneller auf. Veränderungen von Daten ausserhalb der Software erfordern ebenfalls mehr Aufwand in der gleichzeitigen Datenbearbeitung. Daher auch eine Signatur für alle Datensätze.

Entwicklung ist zwar teurer und aufwendiger, dafür aber lt. meinem Kunden leichter im Kritis Bereich zu zertifizieren.

Am Markt würde ich mal schätzen, dass ca. 0,5-1 % aller Firmen diesen Aufwand finanzieren würden. Ob mein Kunde das in der ERP benötigt kann ich nicht abschätzen. Bei den anderen Datenbanken, die ich bei dem programmiert habe, dürfte es angemessen sein, ansonsten hätte er das garantiert nicht gezahlt.

[himitsu]

Jo, einmal haben viele DBMS irgendwo eine (Zusatz)Funktion für eine Replizierung.

Und selbst wenn nicht, dann kann man das auch selber in der DB (Trigger) erledigen
und bei den Abrufen (SELECTs) über einen View bzw. WritableView, der parallel auf die andere DB zugreift und vergleicht, bzw. die Signatur prüft.



Tja, bei uns würde auch nur noch so Kleinkram, wie die eine Sprache oder z.B. das Fax fehlen (*1)
und ich denke mal, dass von den Anforderungen nicht soooo exotisch ist, als dass es die meisten ERPs nicht bieten könnten.

1) Abgesehn von dem Teil mit der Replizierung/Verifizierung, welchen ich jetzt aber nicht, wie schon gesagt, in die Software integrieren würde ... in der DB würde sich sowas bei vielen ERP bestimmt "leichter" nachrüsten lassen.
Wobei wir eh fast alle komponenten abgeleitet haben und sich somit in jede Datasource eine zweite mit integrieren ließe, welche parallel speichert und vergleicht. (natürlich würde das nur Fehler in der DB, welche eigentlich eher seltener sein sollten, abfangen ... gegenüber Fehlern im ERP)