Warum ERP (Enterprise Resource Planning)-MySQL kein Analytics-Store ist (Warum Erp Mysql Kein Analytics Store Ist)

Write-Wahrheit ≠ Read-Wahrheit

In der Logistik landen Fahrzeuge, Expeditionen und Lagerzeilen oft via internes ERP in MySQL. Gut für Belege — schlecht für PostGIS, Heatmaps und MFE-Reads.

Internal ERP
    ↓ writes
 MySQL (operational)
    ↓ cleanse / ETL
 PostgreSQL + PostGIS (analytics)
    ↓ read APIs
 Map UI / Wait Geofence / MFEs

Diese Serie baut die polyglotte ABC-Logistics-Datenplattform und saubere Read-Verträge für Frontends.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Operational Store
Vom ERP beschriebenes MySQL — gut für Ops, schlecht für Analytics.

📦 Analytics Store
Bereinigtes PostgreSQL/PostGIS für Geo-Queries und Reports.

📦 Telemetry Store
Dokumentenspeicher (MongoDB) für hochfrequente Location-Events.

📦 Search Index
Elasticsearch-Cluster für entity-übergreifende Ops-Suche.

Das Muster lässt sich ohne ERP-Produktnamen oder Schemas lehren.

Warum nicht direkt MySQL

Analytische Map-Queries verlängern ERP-Locks.

Bereinigung ist Pflicht

Null-Geometrie, Doppelkennzeichen, Zeitzonen — ETL vor PostGIS.

Frontend-Vertrag

Wait-Geofence und Expeditionsmaps sehen nur Clean-Read-APIs.

Frontend ↛ MySQL
Frontend → Analysis API → PostGIS/Mongo/ES

Die am häufigsten verwechselten Zuordnungen

❌ ERP-DB = BI-DB
✓ ERP ist Write-Store; BI/GIS sind getrennt

❌ Map per JDBC auf MySQL
✓ SPA sieht nie die Operational-DB

❌ Bereinigung optional
✓ Schmutzige Geometrie bricht Geofences

Checkliste zur Prüfung des eigenen Systems

1. Welche Tabellen joinen noch ‘für Reports’ auf MySQL?
2. Wo sind Geo-Felder Pflicht?
3. Erste API-Schicht fürs Frontend?
4. Wie wird ETL-Lag gezeigt?
5. Wo wird PII maskiert?

Was aus diesem Teil bleiben sollte

1. Operational MySQL von Analytics-PostGIS trennen.
2. Frontends nur Clean-Read-Models.
3. Geofence/Heatmaps brauchen keine schmutzigen ERP-Zeilen.

ERP als Analytics zu behandeln heißt, die Kasse für ein Mikroskop zu halten.