Google Sheets zu SQL migrieren: E-Commerce-Demo mit 1.686 Datensätzen
Eine vollständige Migrationsdemo mit 1.686 Datensätzen und 12 absichtlich eingebauten Fehlern – von Google Sheets zu einer relationalen Datenbank.
Ein fiktiver Spezialitätenkaffeehändler – „Roast & Ritual Coffee Co.“ – läuft vollständig Vorgang in einer Google Sheets-Arbeitsmappe mit 10 Registerkarten: Katalog, Varianten, Inventar, Bestellungen, Bestellpositionen, Kunden, Lieferanten, Bestellungen, Lagerbestände, Aktivitätsprotokoll. Die vollständige Migration dieser Arbeitsmappe in eine normalisierte SQL-Datenbank, einschließlich Fehlern, ist öffentlich und erforschbar unter demo.kamensky.dev.
TL;DR
| Das Problem | Einzelhandelsabläufe in Google Sheets scheitern vorhersehbar: doppelte Kunden, schwankende Lagerbestände, überschriebene historische Preise, kein Prüfpfad. |
| Was ist die Demo | Eine deterministische, 100 % reproduzierbare Migration: 10 Tabellenkalkulationsregisterkarten → 12 saubere, verknüpfte Tabellen, mit einem Bericht, der jede Reinigungsentscheidung dokumentiert. |
| Die wichtigsten Zahlen | 1.686 Quelldatensätze → 1.634 importiert · 16 Duplikate aufgelöst · 18 Werte normalisiert · 3 Zeilen unter Quarantäne gestellt · 8 Bestandskorrekturen · 435 Prüfereignisse. |
| Die schwierigen Teile | Es gibt zwei Möglichkeiten, denselben eingegebenen Kunden zusammenzuführen (die Historie der 12 Bestellungen wird wieder vereint); Beibehaltung eines Aktionspreises von 54 $, während im Katalog 59 $ angegeben sind; Neuberechnung des Bestands aus Bewegungen, wenn auf dem Blatt 45 steht, in der Mathematik aber 35. |
| Das Muster | Analysieren → Zuordnen → Bereinigen → Validieren → Importieren, ausgeführt als ein Alles-oder-Nichts-Import – entweder vollständig erfolgreich oder vollständig rückgängig gemacht. |
| Schlüssel zum Mitnehmen | Eine Tabellenkalkulationsmigration ist kein Kopier-Einfüge-Auftrag; es ist eine Prüfung. Wenn Ihr Migrationsbericht nicht jede Zeile berücksichtigen kann, haben Sie nicht migriert, sondern das Chaos verschoben. |
Sie werden sehen, was tatsächlich kaputt geht, wenn ein Unternehmen über Sheets hinauswächst, und zwar wie jede Fehlerklasse wird mit genauen Zählungen und den daraus resultierenden Vorgängen erkannt und gelöst sieht aus wie. Wenn Sie früher auf der Reise sind, beginnen Sie mit Wenn Google Sheets die Skalierung stoppt; wenn du es bist Wenn Sie eine Produktionsdatenbankmigration planen, koppeln Sie diese mit dem Fallstudie: AppSheet zu SQL.
Das Problem
Die Demo-Arbeitsmappe ist bewusst realistisch gestaltet, da jedes Unternehmen mit Tabellenkalkulationen arbeitet konvergiert in den gleichen vier Fehlermodi:
- Kundenfragmentierung. Derselbe Kunde wird unter verschiedenen eingetragen
Schreibweisen über Bestellungen hinweg –
Marcus Vancein einer Registerkarte,Marcus V.in einer anderen. Lifetime-Wert und Bestellhistorie spalten sich in zwei Identitäten, und keine davon ist richtig. - Abweichung der Bestandsnachzählung. Eine statische Registerkarte „Inventar“ ist ein Foto, kein Foto Hauptbuch. Verkäufe und Wiederauffüllungen landen in getrennten Tabs; Jemand vergisst das Update der Graf; Das Blatt weicht von der Realität ab, eine verpasste Bearbeitung nach der anderen.
- Historische Fakten werden überschrieben. Wenn sich ein Katalogpreis ändert, ist das naiv sync „korrigiert“ alte Auftragszeilen entsprechend und schreibt Ihre Buchhaltung stillschweigend neu.
- Keine Audit-Transparenz. Sheets kann nicht antworten, wer diesen Preis wann geändert hat Hat die letzte Nachzählung stattgefunden und warum?
Die Migration, Stufe für Stufe
Die Pipeline durchläuft fünf Phasen, und – das ist wichtig – der Import wird als eine Phase ausgeführt Alles-oder-Nichts-Schritt. Es gibt keinen Staat, in dem die Hälfte der Arbeitsmappe migriert ist:
| Bühne | Was es tut |
|---|---|
| 1. Analysieren | Prüft Blattformen, Nullbarkeit und erkennt verunreinigte Anomalien, bevor etwas berührt wird. |
| 2. Karte | Wendet explizite Spalten-zu-Entitäts-Zuordnungen an – durch Vibes wird nichts abgeleitet. |
| 3. Sauber | Führt die Reinigungsregeln mit genauer Zählverfolgung aus: Jedes Duplikat, jede Normalisierung und jede Quarantäne wird gezählt. |
| 4. Validieren | Stellt Rekordzahlverträge, Linkintegrität und sechs „Heldenfakten“ sicher, die die Migration wörtlich überstehen müssen. |
| 5. Importieren | Einzeltransaktionslast; erstellt das Bestandsbewegungsbuch und das Aktivitätsprotokoll. |
| Metrisch | Zählen |
|---|---|
| Quelldatensätze | 1.686 |
| Erfolgreich importiert | 1.634 |
| Duplikate behoben | 16 (14 Kunden, 1 Lieferant, 1 Bestellposition) |
| Werte normalisiert | 18 (7 SKUs, 6 Varianten, 5 E-Mails) |
| Zur Überprüfung unter Quarantäne gestellt | 3 (mehrdeutige Befehle – nie stillschweigend fallen gelassen) |
| Bestandskorrekturen | 8 (Handbuchblatt ≠ Bewegungsbuch) |
| Historische Preise erhalten | 1 |
| Aktivitätsereignisse importiert | 435 |
Die 12 Fehler, die bei jeder Migration auftreten
Das Arbeitsbuch wird mit zwölf gepflanzten Fehlern (E1–E12) geliefert, die jeweils einem echten entnommen sind Migration. Ein Beispiel dafür, was die Pipeline auffangen muss:
| ID | Legacy-Status | Regel angewendet | Ergebnis |
|---|---|---|---|
| E1 | Marcus Vance (C-023) und Marcus V. (C-071), gleiche E-Mail | Zusammenführen per normalisierter E-Mail; den längsten offiziellen Namen behalten; Bestellungen neu verknüpfen | Ein Kunde mit einer Lebenszeithistorie von 12 Bestellungen |
| E3 | In der Zeile ORD-1042 steht 54 $, im Katalog steht 59 $ | order_items.unit_price als historische Tatsache bewahren | Aktionspreis beibehalten; Katalog unberührt – zwei Zahlen, beide wahr |
| E4 | Auf dem Inventarblatt stehen 45 Einheiten der Flaggschiff-SKU | Bestand aus Bewegungen neu berechnen: +120 gekauft, −85 verkauft | Der Viehbestand beträgt 35; das Blatt war um +10 |
| E9 | Lieferant eingegeben als „Horzion Coffee Importers“ | Alias/Fuzzy-Auflösung zum kanonischen Lieferanten | Auffüllen mit der richtigen Entität verknüpft |
| E12 | Leere Telefone, leere reservierte Zellen | Leere Werte bleiben wirklich leer, niemals Dummy-Nullen | Ehrliche Daten, keine gefälschten Platzhalter |
Die restlichen sieben beziehen sich auf SKU-Tippfehler (ETH-yir-wb-1000), neu eingegebene Produktnamen wo
Eine SKU-Referenz sollte lauten: fehlende E-Mails von Laufkunden, Gehäusechaos
(WHOLE BEAN / 1KG vs. ground / 250g), eine doppelt eingefügte Werbebuchung und a
Nicht mehr lieferbare SKU, die Jahre später bestellt wurde – importiert und markiert, weil gelöscht
Geschichte ist schlimmer als sie zu behalten.
Der E4-Fall verdient eine Erwähnung, denn er ist derjenige, der die Leute überrascht: der Die Tabellenkalkulation war an dem Tag, an dem sie geschrieben wurde, nicht falsch. Es driftete. Drei Kauf Eingegangene Bestellungen (+120 Säcke) und fünfzehn ausgehende Bestellungen (−85), der tatsächliche Bestand beträgt 35 – die Blatt 45 ist der Rest verpasster manueller Aktualisierungen. Deshalb die Zielstruktur speichert Bewegungen, keine Zählungen: Der Lagerbestand wird immer berechnet, niemals von Hand eingegeben.
Entdecken Sie die Live-Demo
Alles oben Genannte kann unter demo.kamensky.dev durchsucht werden — eine voll funktionsfähige Betriebs-App, die auf der migrierten Datenbank ausgeführt wird (nicht schreibgeschützt):
- Dashboard & Analytics – KPIs, die aus den sauberen, verknüpften Tabellen berechnet und nicht aus einem Blatt eingefügt werden.
- Dateneingabe und Berechtigungen – authentifizierte Benutzerrollen mit detaillierten Berechtigungsbeschränkungen und Live-Dateneingabe.
- Bestandsbuch – aus dem Bewegungsbuch berechneter Bestand mit dem Gekaufte/verkaufte/berechnete Mathematik pro SKU sichtbar.
- Customer 360 – Marcus Vance öffnen: 12 Bestellungen über beide Legacy-Identitäten hinweg, in einer Zeitleiste zusammengeführt.
- Bestellungen, Produkte, Lieferanten, Einkäufe – vollständige Verzeichnisse mit Detailseiten pro Bestellung, SKU und Lieferant.
- Benachrichtigungen und Integrationen – automatisierte Betriebswarnungen und bereit für externe Integrationen.
- Migrationsbericht – die genaue Prüftabelle oben, gerendert aus dem Lauf.
Die Daten sind fiktiv (es ist eine Demo), aber deterministisch: Jede Regeneration beginnt aus denselben festen Quelldaten – dieselben 12 Fehler, dieselben 1.686 Datensätze, jedes Mal. Das macht die Migration eher nachweisbar als „wahrscheinlich in Ordnung“.
Ist Ihre Arbeitsmappe gefährdet?
Die Demo-Mängel werden gepflanzt; Ihres hat sich organisch angesammelt. Dieser Rechner punktet wie nah Ihre Arbeitsmappe an den oben genannten Fehlermodi ist – tragen Sie Ihre eigenen Zahlen ein:
Interaktiver Risiko- und ROI-Assessor für Google Sheets
Bewerten Sie Tabellenzustand und geschätzte wöchentlich verlorene Zeit.
Führen Sie Ihren Shop aus einer Tabellenkalkulation heraus?Die Demo verwendet SQLite (eine eingebettete Datenbank), um eigenständig zu bleiben – das gleiche Pipeline-Muster verwende ich
Migrieren Sie Produktionsunternehmen auf strukturierte relationale Datenbanken, mit Schattenläufen und ohne Ausfallzeiten Umstellung. Wenn Ihre Arbeitsmappe die Zeichen zeigt, ist das das Gespräch, das Sie führen sollten.
Einen Entdeckungsanruf buchen →
Mehr dazu: die verwandten Google-Sheets-Artikel und Fallstudie zur Migration von AppSheet zu SQL und Wenn Google Sheets die Skalierung stoppt.