Eine eigene Comic-Datenbank aufzubauen bedeutet, ein konsistentes Feldschema zu definieren (Serien-ID, Volume, Heftnummer, Kreative, Zustand, Wert), zwischen einem flachen Format wie Excel oder einem relationalen Multi-Tabellen-Modell zu wählen und dann Indizes auf die am häufigsten abgefragten Spalten (Serie, Kreativer, Datum) zu legen, um auch jenseits von 1.000 Einträgen schnelle Suchen zu gewährleisten. Der Rest sind Architekturentscheidungen, die sich erst zehn Jahre später rächen — oder auszahlen.
Eine Comic-Sammlung, die 300 Hefte überschreitet, ist kein Inventar mehr, sondern eine Datenbank. Nur merken die meisten Sammler das zu spät, wenn die Excel-Datei bei jeder Sortierung ruckelt oder die Suche nach einem Wolverine-Variant drei Minuten dauert. Die Ursache liegt fast nie am Volumen, sondern am Schema: schlecht durchdachte Felder, uneinheitliche Einheiten, keine Fremdschlüssel, kein Index. Dieser Artikel beschreibt, wie man eine persönliche Comic-Datenbank entwirft, die der Zeit standhält — egal ob du sie in einer Tabellenkalkulation, in Notion, in Airtable oder in einer spezialisierten Anwendung pflegst. Es geht um Kernfelder, erweiterte Felder, die Debatte flaches Schema gegen relationales Schema und die Bedeutung von Indizes für die Suche.
Warum von Datenbank statt von Inventar sprechen
Das Wort Inventar suggeriert eine starre Liste. Eine Comic-Datenbank hingegen ist darauf ausgelegt, Fragen zu beantworten: Wie viele Detective Comics zwischen den Heften 400 und 500 besitze ich im Zustand VF oder besser? Welche Frank-Miller-Ausgaben besitze ich als Hardcover? Wie hoch ist der Gesamtbetrag, den ich 2024 für Variants bezahlt habe? Eine Liste kann das nicht beantworten, eine Datenbank schon.
Der Unterschied zeigt sich auf drei Ebenen. Zunächst die Granularität: Ein Inventar vermischt oft Serie und Heft, während eine Datenbank Serie, Volume, Heftnummer und physisches Exemplar trennt. Dann die Normalisierung: Ein Kreativer wird nur einmal erfasst und mit den Comics verknüpft, statt in 800 Zellen erneut eingetippt zu werden. Schließlich die Abfragbarkeit: Die Datenbank erlaubt komplexe Abfragen, gekreuzte Filter, statistische Aggregate.
Konkret zeigt eine flache Tabelle sobald eine Sammlung 500 Einträge überschreitet erste Grenzen: langsame Suchen, Duplikate bei Kreativen-Namen (Steve McNiven, Steve Mc Niven, S. McNiven), Uneinheitlichkeiten bei Zuständen (NM, Near Mint, 9.4, 9.2). Der Übergang zu einem als Datenbank gedachten Modell — selbst wenn es in Google Sheets oder Airtable gehostet wird — verändert die Entwicklung der Sammlung grundlegend. Für den sanften Übergang beschreibt der Artikel Comic-Sammlung katalogisieren: Methoden im Vergleich die Zwischenwerkzeuge zwischen Excel und dedizierter Anwendung.
Die Kernfelder, die man nicht diskutiert
Ein minimales Schema enthält rund zehn Felder, ohne die die Datenbank nutzlos ist. Sie beschreiben die Identität des Comics (wer, wann, was) und seinen Status in der Sammlung (Zustand, Wert, Standort).
Die 10 Kernfelder einer Comic-Datenbank
- id_serie: eindeutige Kennung der Serie (kurzer Text oder Zahl), z. B. asm für Amazing Spider-Man.
- titre_serie: vollständige Bezeichnung (Amazing Spider-Man, Detective Comics).
- volume: Volume-Nummer (1, 2, 3) — entscheidend, um Neustarts der Serie zu unterscheiden.
- issue: Heftnummer, Ganzzahl oder Text (#700.1, #-1, #1000000).
- date_publication: Datum im ISO-Format (YYYY-MM oder YYYY-MM-DD).
- editeur: Marvel, DC, Image, Dark Horse, IDW usw.
- createurs: mindestens Autor und Hauptzeichner.
- etat: normierter Grad (Poor 0.5 bis Mint 10.0) oder Kurzlabel (NM, VF, FN, VG).
- valeur: numerischer Betrag in einer einzigen Währung, mit Datum.
- date_acquisition: wann der Comic in die Sammlung aufgenommen wurde.
Die klassische Falle besteht darin, Volume und Heftnummer in einem einzigen Feld zu vermischen (Amazing Spider-Man vol.3 #4). Damit verliert man die Möglichkeit, innerhalb eines Volumes nach Heftnummer zu sortieren, einen vollständigen Run zu berechnen oder eine Wunschliste per Differenzbildung zu erzeugen. Trenne diese Felder immer. Beim Zustand wähle eine einheitliche Konvention: entweder die numerische Skala 0.5–10.0 (kompatibel mit CGC) oder Textlabels (Mint, Near Mint, VF, FN, VG, GD, FR, PR). Beides in derselben Spalte ist die Garantie für Kopfzerbrechen beim Sortieren.
Die erweiterten Felder für alle, die es genau wissen wollen
Über den Kern hinaus fügen ernsthafte Sammler eine Ebene von Metadaten hinzu, die eine feinere Auswertung ermöglicht: Variants, Drittanbieter-Bewertung, physischer Standort, finanzielle Nachverfolgbarkeit.
Nützliche erweiterte Felder
- variant_cover: Cover A/B/C, Verhältnis (1:25, 1:100), Name des Variant-Künstlers.
- cgc_tier: Universal, Signature Series, Restored, Qualified, Conservation.
- cgc_grade: exakte Note (0.5 bis 10.0) mit zwei Dezimalstellen.
- cgc_cert: zehnstellige Zertifizierungsnummer.
- lieu_stockage: Box/Regal/Long Box (z. B. LB-03 / Slot 12).
- prix_paye: Kaufbetrag, getrennt vom aktuellen Wert.
- source_achat: eBay, Comic-Shop, Convention, Privatperson.
Diese Felder werden entscheidend bei einer Versicherung, einer Begutachtung oder einem Erbfall. Ein Detective Comics #27 ohne Zertifizierungsnummer ist zum Marktpreis unverkäuflich. Eine Long Box ohne Feld lieu_stockage bedeutet drei Stunden Durchsuchen bei jedem Verleihwunsch. Für die physische Dimension beschreibt der Artikel eine Sammlung von 500+ Comics organisieren die Nomenklatur der Long Boxes und den Abgleich mit der Datenbank.
Bei Variants ist Vorsicht geboten, damit nichts durcheinandergerät: Ein Walking Dead #1 Cover A in Schwarz-Weiß ist nicht dasselbe wie ein Cover B in Farbe, und ein Amazing Spider-Man #300 als Newsstand-Ausgabe hat einen ganz anderen Preis als die Direct-Edition-Version. Drei Unterfelder (cover_letter, edition_type, ratio) lösen das Problem für Jahrzehnte.
Flaches Schema gegen relationales Schema
Das ist die strukturprägende Entscheidung. Das flache Schema legt alles in eine einzige große Tabelle: eine Zeile = ein Comic, alle Spalten nebeneinander. Excel, Google Sheets und die meisten CSV-Dateien funktionieren so. Das relationale Schema zerlegt die Information in mehrere Tabellen, die über Schlüssel verknüpft sind: Tabelle Serien, Tabelle Hefte, Tabelle Kreative, Tabelle Exemplare, Tabelle Erwerbungen. Das ist das Modell dedizierter Anwendungen und von SQL-Datenbanken.
Das flache Schema hat einen Vorzug: sofortige Lesbarkeit. Du öffnest die Datei und siehst alles. Für 200 Comics ist das ausreichend. Darüber hinaus explodieren die Nachteile. Eine Namensänderung des Verlags (Marvel wird zu Marvel Comics Group, dann zu Marvel Worldwide) zwingt dazu, Tausende Zellen zu ändern. Ein an drei Stellen unterschiedlich geschriebener Kreativer verunreinigt die Filter. Eine Wertaktualisierung über einen gesamten Run erfordert enormen manuellen Aufwand.
Das relationale Schema löst diese Probleme durch Normalisierung. Der Kreative Frank Miller existiert nur einmal in der Tabelle Kreative, mit eigener ID. Alle Comics, die ihn nennen, verweisen auf diese ID. Frank Miller in Frank Miller Sr. umzubenennen geschieht in einer einzigen Zelle, mit automatischer Übernahme überall. Dasselbe gilt für Serien, Verlage, Status.
Wann was wählen
- Weniger als 300 Comics, statische Sammlung: flach (Excel, Google Sheets). Relationaler Mehraufwand nicht gerechtfertigt.
- 300 bis 1.000 Comics, langsames Wachstum: flach, angereichert mit kontrollierten Dropdown-Listen, oder Airtable im Hybrid-Modus.
- Mehr als 1.000 Comics oder Sammlung mit mehreren Nutzern: relational zwingend, sei es über eine dedizierte Anwendung, ein gut strukturiertes Airtable oder ein lokales SQLite.
- Mehrere Exemplare desselben Hefts (Lese-Exemplar + Slab): relational nahezu zwingend, sonst massive Duplizierung.
Der Vergleich Comic-Sammlungs-App für Einsteiger greift dieses Dilemma mit konkreten Beispielen für die Migration aus Excel auf.
Die Modellierung über Tabellen, ein konkretes Beispiel
Stellen wir uns ein minimales relationales Schema mit fünf Tabellen vor. Diese Architektur deckt 90 % der Bedürfnisse einer ambitionierten Sammlung ab, bis hin zu mehreren tausend Einträgen.
Schema mit 5 Tabellen
- series (id, titre, editeur, volume, annee_debut, annee_fin, statut).
- issues (id, serie_id ↗, numero, date_publication, page_count, story_arc).
- createurs (id, nom, role_principal, bio_courte).
- issue_createurs (issue_id ↗, createur_id ↗, role) — Verknüpfungstabelle.
- exemplaires (id, issue_id ↗, etat, cgc_grade, cgc_cert, prix_paye, date_acquisition, lieu_stockage, valeur_courante).
Der entscheidende Punkt ist die Trennung zwischen Heft (die Ausgabe, wie sie veröffentlicht wurde, identisch für alle Sammler) und Exemplar (das konkrete physische Comic, das du besitzt). Genau diese Unterscheidung erlaubt es, zwei Amazing Spider-Man #300 in der Sammlung zu haben, ohne Duplizierung: eine Zeile in exemplaires mit Zustand 9.4, eine weitere mit Zustand 6.0, beide verweisen auf dieselbe Heft-ID.
Die Tabelle issue_createurs ist eine Many-to-many-Verknüpfungstabelle: Ein Comic hat mehrere Kreative, ein Kreativer hat an mehreren Comics mitgewirkt. Sie ermöglicht eine Abfrage wie „alle Comics, bei denen Chris Claremont Autor und John Byrne Zeichner ist", ohne Namen in Dutzenden von Spalten duplizieren zu müssen.
Für die praktische Umsetzung ohne Programmieren genügen Airtable, Notion oder sogar Google Sheets mit mehreren Tabs und VLOOKUP/INDEX-MATCH. Der Wechsel zu SQLite oder PostgreSQL lohnt sich erst jenseits von 10.000 Comics oder für eine gemeinsam genutzte Sammlung mit mehreren Nutzern. Der Artikel digitale und physische Comic-Bibliothek verwalten behandelt die Verbindung zwischen Papier- und Digitalexemplaren.
Index, schnelle Suche und Performance
Ein Index ist eine sekundäre Tabelle, die auf die Zeilen einer Spalte verweist, um die Suche nahezu augenblicklich zu machen. Ohne Index durchsucht die Engine bei jeder Abfrage die gesamte Tabelle. Mit Index springt sie direkt zu den relevanten Zeilen. Bei 200 Comics ist der Unterschied kaum spürbar. Bei 5.000 sind es 30 Sekunden gegenüber 0,2 Sekunden.
Die Spalten, die einen Index in einer Comic-Datenbank verdienen, sind vorhersehbar: id_serie, titre_serie, createur, date_publication, cgc_grade. Das sind jene, nach denen du mehrmals pro Woche filterst oder sortierst. Die Nebenspalten (Kreativen-Bio, Seitenzahl, Story-Arc) können unindiziert bleiben.
In einer Tabellenkalkulation nimmt der „manuelle" Index die Form eines eigenen Referenzblatts plus einer kurzen numerischen Schlüsselspalte an. In Airtable und Notion wirken gefilterte Ansichten wie logische Indizes. In einer nativen Anwendung oder einem SQLite erledigt der Befehl CREATE INDEX die Arbeit in einer Zeile.
Ein Index hat einen Preis: Er verbraucht Speicherplatz und verlangsamt Schreibvorgänge leicht. Bei einer Sammlung ist dieser Preis im Vergleich zum Lesegewinn vernachlässigbar. Eine einfache Regel: indiziere, was du suchst, kümmere dich nicht um den Rest.
Der zweite Performance-Hebel ist die kontrollierte Denormalisierung. Den Seriennamen im Klartext in der Tabelle exemplaires zu speichern (zusätzlich zur ID) verdoppelt den benötigten Platz, erspart aber bei jedem Export einen Join. Für eine persönliche Datenbank ist das ein akzeptabler Kompromiss. Für mehr zur geräteübergreifenden Dimension siehe Comic-Sammlung geräteübergreifend synchronisieren.
Import, Export und Austauschformate
Eine Datenbank, die nichts exportiert, ist ein Gefängnis. Der Reflex, den man ab Tag 1 haben sollte: ein standardisiertes Austauschformat wählen und alle sechs Monate einen Round-Trip (Export, dann Reimport) testen. Wenn der Reimport denselben Zustand wie der Export ergibt, ist dein Schema gesund. Gibt es Verluste (falsch formatierte Daten, kaputte Umlaute, mit Trennzeichen verwechselte Kommas), korrigiere das, bevor die Sammlung weiterwächst.
Drei Formate dominieren. CSV bleibt das universellste: eine Zeile pro Comic, Trennzeichen Komma oder Semikolon, UTF-8-Kodierung zwingend für Sonderzeichen und typografische Zeichen. JSON eignet sich besser für relationale Schemas, da es verschachtelte Strukturen handhabt (ein Comic kann ein Array von Kreativen enthalten). SQLite, eine einzige .db-Datei, ist ideal für ein vollständiges Backup oder das Teilen mit einem anderen Sammler in derselben App.
Best Practices für Import/Export
- Immer in UTF-8 arbeiten, niemals in ISO-8859-1, sonst gibt es beim nächsten Öffnen kaputte Umlaute.
- Daten im ISO-Format (YYYY-MM-DD), niemals im lokalen Format (12.06.2024 vs. 06.12.2024 = garantierte Mehrdeutigkeit).
- Numerische Felder in angelsächsischer Notation für Portabilität (1500.50 statt 1.500,50).
- Mindestens alle drei Monate ein CSV- oder JSON-Backup, in der Cloud gespeichert (Dropbox, Google Drive, iCloud).
- Das Schema in einer README neben der Datei dokumentieren: Dein Ich von 2030 wird es dir danken.
Der Artikel Comic-Sammlung in eine Anwendung importieren beschreibt die Schritte einer Migration von Excel zur Anwendung und geht auf die klassischen Fallstricke ein (nicht erkannte Variants, mehrdeutige Kreative, Duplikate).
Wartung und Weiterentwicklung des Schemas im Lauf der Zeit
Eine Comic-Datenbank entwickelt sich weiter. Du startest mit 8 Feldern, fügst in zwei Jahren 15 weitere hinzu. Das ist normal und sogar wünschenswert. Die Falle besteht darin, das Schema ohne Plan zu ändern: hier eine Spalte hinzufügen, dort eine andere löschen, ohne Dokumentation. Nach fünf Jahren weiß niemand mehr, was flag_b3 bedeutet.
Die minimale Disziplin: ein Schema-Changelog führen. Eine einfache datierte Textdatei, die Ergänzungen und Streichungen von Feldern mit ihrer Bedeutung auflistet. So lassen sich alte Exporte später wieder verstehen und aufbereiten.
Zur Weiterentwicklung gelten zwei Prinzipien. Erstens: Lösche niemals eine Spalte, archiviere sie in einer parallelen Tabelle. Du weißt nicht mehr, was das Feld note_personnelle von 2021 enthält? Wahrscheinlich eine wertvolle Erinnerung an einen geschenkten Comic. Behalte es. Zweitens: Bevorzuge das Hinzufügen eines neuen Feldes gegenüber der Umdeutung eines alten. Wenn du anfängst, auch die Rückseite der Cover zu notieren, erstelle cover_back_artist, verwende nicht variant_cover für zwei unterschiedliche Bedeutungen weiter.
Jenseits von 1.000 Comics wird die Weiterentwicklung des Schemas zu einem eigenen Projekt. Die meisten Sammler wechseln an diesem Punkt zu einer dedizierten Anwendung, die die Schema-Wartung für sie übernimmt, mit transparenten Migrationen bei jedem Update. Der Artikel Comic-App für große Sammlungen 1000+ behandelt genau diesen Übergang. Für die Offline-Dimension, unverzichtbar, wenn du auf einer Convention ohne Netz katalogisierst, siehe Comic-App im Offline-Modus.
FAQ
Was ist der Unterschied zwischen einer Datenbank und einem Inventar?
Ein Inventar ist eine starre Liste, die eine Frage beantwortet: Was besitze ich? Eine Datenbank ist eine abfragbare Struktur, die Dutzende gekreuzte Fragen beantwortet: wie viele, wann, von wem, zu welchem Preis, in welchem Zustand. Der Übergang vom einen zum anderen erfolgt durch die Normalisierung der Felder und das Hinzufügen von Beziehungen zwischen Entitäten (Serien, Kreative, Exemplare).
Wie viele Felder sollte ich zu Beginn einplanen?
Rund zehn Kernfelder reichen zum Start (id_serie, titre, volume, issue, date, editeur, createurs, etat, valeur, date_acquisition). Füge erweiterte Felder erst hinzu, wenn du sie wirklich nutzt. Besser eine einfache, gut gepflegte Datenbank als ein Schema mit 40 Spalten, von denen 30 leer bleiben.
Muss ich unter 1.000 Comics wirklich auf relational umsteigen?
Nicht zwingend. Eine statische Sammlung von 500 Comics mit wenigen Variants lässt sich gut flach verwalten. Aber sobald es mehrere Exemplare desselben Hefts, wiederkehrende Kreative oder schnelles Wachstum gibt, rechnet sich das relationale Modell. Der Schmerz des flachen Modells wird ab 800 Einträgen spürbar und wird bei 2.000 kritisch.
Welches Tool eignet sich, um ohne Programmieren eine relationale Datenbank zu starten?
Airtable ist der häufigste Kompromiss: verknüpfte Tabellen, gefilterte Ansichten, Formeln, Integration mit Notion oder Make. Notion eignet sich für mittelgroße Sammlungen mit persönlicher Nutzung. Für sehr umfangreiche Sammlungen oder fortgeschrittene Anforderungen bringt eine dedizierte Anwendung wie My Comics Collection das Schema bereits vorgefertigt mit.
Wie geht man mit Variants im Schema um?
Drei Unterfelder lösen die meisten Fälle: cover_letter (A/B/C/D), edition_type (regular, newsstand, direct, variant) und ratio (1:25, 1:50, 1:100). Für Sketch-Cover oder Signaturen vermeidet ein eigenes freies Textfeld, dass andere Spalten verunreinigt werden. Vermische niemals Variant und Haupt-Cover-Künstler.
Welche Indizes sollte ich vorrangig anlegen?
Die Spalten, die du am häufigsten abfragst: id_serie oder titre_serie, Name des Kreativen, Veröffentlichungsdatum, CGC-Grad. Sie müssen in wenigen Millisekunden antworten. Die Nebenspalten (Seitenzahl, Story-Arc, Kreativen-Bio) können ohne spürbaren Nachteil unindiziert bleiben.
Welches Format sollte ich für Backups wählen?
CSV für universelle Portabilität, JSON zur Erhaltung verschachtelter Strukturen (mehrere Kreative, Variant-Listen), SQLite für einen kompletten Snapshot der Datenbank. Die Minimalregel: mindestens alle drei Monate ein Backup, in der Cloud gespeichert, sowie ein jährlicher Test-Round-Trip (Export, dann Reimport in eine leere Datei).
Wie lange dauert der Aufbau einer Datenbank mit 500 Comics?
Rechne mit 10 bis 20 Stunden manueller Erfassung von Grund auf, mit 1 bis 2 Stunden bei einer Anwendung, die Barcodes scannt und Metadaten automatisch importiert. Die Ersterfassung ist eine hohe, aber einmalige Investition: Danach dauert das Hinzufügen eines neuen Comics 30 Sekunden. Zur Beschleunigung siehe Comic-Barcodes mit dem iPhone scannen und Comic-Barcodes mit Android scannen.