Notion Datenbanken statt Seiten: So findest du endlich alles wieder

Notion Datenbanken statt Seiten: So findest du endlich alles wieder

Warum die meisten Notion-Strukturen scheitern und was stattdessen funktioniert

Übersicht

Es fängt an wie bei fast allen. Du baust dir einen Notion-Workspace auf: Seiten in Seiten, alles ordentlich verschachtelt, alles hat seinen Platz. Es fühlt sich gut an. Drei Monate später findest du nichts mehr wieder.

Updates sind über zehn verschiedene Seiten verstreut. Dein Team fragt ständig: „Wo hatten wir das nochmal abgelegt?" Du verbringst mehr Zeit mit Suchen als mit Arbeiten.

Das Problem bist nicht du. Das Problem ist, dass du in Seiten denkst, obwohl du in Datenbanken denken solltest.

Diese Verschiebung – von seitenbasiertem Denken zur datenbankorientierten Struktur – entscheidet darüber, ob dein Notion-Workspace unter Druck zusammenbricht oder mit deinem Business mitwächst.

In diesem Artikel erfährst du:

  • Warum seitenbasierte Strukturen bei Wachstum scheitern
  • Was Datenbanken anders machen und warum sie skalieren
  • Wie du das mentale Modell von Datenbanken entwickelst
  • Wann du eine Datenbank statt einer Seite brauchst
  • Welche Fehler fast alle beim Datenbankaufbau machen
Das Wichtigste auf einen Blick:
  1. Seiten sind statische Container für einmalige Inhalte. Datenbanken strukturieren wiederkehrende Information.
  2. Wenn du dieselbe Art von Information mehrfach anlegst, brauchst du eine Datenbank, keine Seiten.
  3. Datenbanken ermöglichen Filterung, Sortierung und Verknüpfung. Seiten können das nicht.
  4. Das Single-Source-of-Truth-Prinzip eliminiert Dopplungen und veraltete Daten.
  5. Die Frage „Werde ich jemals noch eins davon brauchen?" entscheidet zwischen Seite und Datenbank.

Warum funktioniert seitenbasiertes Denken nicht mehr?

Die meisten starten mit Notion wie mit einem digitalen Ordnerschrank. Eine Seite für Projekt Alpha. Eine für Projekt Beta. Eine für die Meeting-Notizen vom letzten Dienstag.

Das fühlt sich vertraut an, weil wir Dokumente schon immer so organisiert haben.

Aber hier liegt die Falle: Seiten sind statische Container. Sie sind dafür gemacht, einzigartige, einmalige Information zu halten. Wenn du sie nutzt, um Information zu speichern, die aktualisiert, verglichen oder mit anderer Information verknüpft werden muss, baust du ein Kartenhaus.

Überleg mal: Wenn deine Projekt-Updates über einzelne Seiten verstreut sind, wie beantwortest du dann einfache Fragen wie „Welche Projekte liegen hinter dem Zeitplan?" oder „Was haben wir dieses Quartal geschafft?"

Du kannst es nicht. Nicht ohne Dutzende Seiten zu öffnen und die Information manuell zusammenzutragen.

Kurz gesagt: Seiten zwingen dich zum Suchen. Datenbanken liefern Antworten.

Warum wachsen Unternehmen aus seitenbasierten Strukturen heraus?

Wenn dein Business wächst, produzierst du mehr Daten. Mehr Kundinnen. Mehr Projekte. Mehr Teammitglieder, die auf dieselbe Information zugreifen müssen.

Eine seitenbasierte Struktur zwingt dich dazu, entweder:

  • Endlose verschachtelte Hierarchien zu bauen, in denen niemand mehr durchblickt
  • Information über mehrere Seiten zu duplizieren (und dann nie wieder synchron zu halten)
  • Jedes Mal manuell durch Seiten zu suchen, wenn du etwas finden musst

Letzte Woche saß ich mit einer Kundin am Bildschirm. Sie suchte die Kontaktdaten einer Interessentin. Erst in der Projekt-Seite. Dann in den Meeting-Notizen. Dann im Angebots-Ordner. Nach 8 Minuten fanden wir sie in einer vierten Seite. Ich hab mitgezählt: Sie hatte dieselbe E-Mail-Adresse an fünf verschiedenen Stellen gespeichert, drei davon mit unterschiedlichen Schreibweisen des Namens.

Das ist kein Produktivitätssystem. Das ist Produktivitätstheater.

Der Moment, in dem du dieselbe Art von Information kopierst und in mehrere Seiten einfügst, ist der Moment, in dem du über seitenbasiertes Denken hinausgewachsen bist.

Kurz gesagt: Wachstum entlarvt die Grenzen von Seiten. Datenbanken halten mit.

Was ist der Unterschied zwischen Seiten und Datenbanken in Notion?

Eine Seite ist genau das: eine leere Fläche, auf der du schreiben, Medien einbetten und Inhalte erstellen kannst. Denk daran wie an ein Dokument.

Seiten funktionieren gut für einzigartige, narrative Inhalte, die nicht gefiltert, sortiert oder mit ähnlichen Einträgen verglichen werden müssen.

Das Schlüsselwort hier ist einzigartig. Wenn die Information, die du erstellst, einmalig ist und nicht in ähnlichem Format an anderer Stelle auftaucht, macht eine Seite Sinn.

Eine Datenbank ist eine Sammlung strukturierter Einträge, die dieselben Eigenschaften teilen. Statt für jede Kundin eine eigene Seite anzulegen, erstellst du eine Datenbank, in der jede Kundin eine Zeile oder Karte ist mit einheitlichen Feldern: Kontaktdaten, Projektstatus, Vertragswert, nächster Schritt.

Das ist transformativ, weil Datenbanken dir geben:

  • Flexibilität beim Betrachten: Sieh dieselbe Information als Tabelle, Board, Kalender, Galerie oder Timeline – je nachdem, was für die Aufgabe Sinn macht.
  • Filter und Sortierung: Zeig sofort alle aktiven Kundinnen, alle überfälligen Aufgaben oder alle für nächste Woche geplanten Inhalte.
  • Verknüpfungen zwischen Information: Verbinde deine Kundinnen-Datenbank mit deiner Projekte-Datenbank, sodass du alle Projekte pro Kundin siehst und umgekehrt.
  • Konsistenz: Jeder Eintrag hat dieselbe Struktur, wodurch es unmöglich wird, wichtige Information zu vergessen.

Der fundamentale Unterschied: Seiten verlangen, dass du dich erinnerst, wo du etwas abgelegt hast. Datenbanken lassen dich Fragen an deine Information stellen und liefern sofort Antworten.

Kurz gesagt: Seiten speichern Dokumente. Datenbanken strukturieren Systeme.

Wie entwickelst du das mentale Modell für Datenbanken?

Information als strukturierte Daten betrachten

Das Datenbank-Mindset beginnt mit einer einfachen Frage: „Werde ich jemals noch eins davon brauchen?"

Wenn du eine Seite über ein Kundinnen-Meeting erstellst, halt kurz inne und frag dich: Wird es weitere Kundinnen-Meetings geben? Natürlich. Das ist keine Seite, das ist ein Eintrag in einer Meetings-Datenbank.

Du schreibst ein Projekt-Briefing? Du wirst weitere Projekte haben. Datenbank-Eintrag.

Du dokumentierst einen Prozess? Wenn es ein wiederholbarer Prozess ist, gehört er in eine Prozesse-Datenbank, wo du ihn nach Abteilung, Verantwortlicher und Häufigkeit taggen kannst.

Diese mentale Verschiebung – von „Ich erstelle ein Dokument" zu „Ich füge einen Datensatz zu einer strukturierten Sammlung hinzu" – ändert alles.

Du beginnst, Muster in deiner Information zu sehen. Du denkst darüber nach, welche Eigenschaften jede Art von Eintrag haben sollte. Du entwirfst Systeme, die Information von Anfang an konsistent erfassen.

Kurz gesagt: Frage dich nicht „Wo speichere ich das?", sondern „Zu welcher Datenbank gehört das?"

Beziehungen statt Ordner

In der alten Seiten-Welt organisierst du durch Verschachtelung. Projekte gehen in den Projekte-Ordner. Kundinnen in den Kundinnen-Ordner. Aber was passiert, wenn ein Projekt zu einer Kundin gehört? Du duplizierst Information oder erstellst Links, die kaputt gehen, sobald du umstrukturierst.

Datenbanken nutzen Beziehungen statt Ordner. Deine Projekte-Datenbank kann eine Eigenschaft „Kundin" haben, die zur Kundinnen-Datenbank verlinkt. Wenn du jetzt ein Projekt öffnest, siehst du, zu welcher Kundin es gehört. Und wenn du eine Kundin öffnest, siehst du automatisch alle ihre Projekte.

Keine Duplizierung. Keine Ordnerhierarchie, die gepflegt werden muss.

So funktioniert moderne Software. Und so funktioniert auch dein Gehirn. Information ist nicht natürlicherweise hierarchisch, sie ist vernetzt. Datenbanken lassen dich diese Realität abbilden.

Kurz gesagt: Ordner verstecken Zusammenhänge. Beziehungen machen sie sichtbar.

Das Single-Source-of-Truth-Prinzip

Vielleicht der mächtigste Aspekt von Datenbank-Denken: Redundanz eliminieren.

In einem seitenbasierten System hast du vielleicht Kundinnen-Kontaktdaten auf deren Projektseite, auf deren Vertragsseite und auf deiner Kontakte-Seite. Wenn sich die E-Mail ändert, musst du drei Stellen aktualisieren. Und du wirst es vergessen.

Mit Datenbanken speicherst du jede Information genau einmal und referenzierst sie überall, wo du sie brauchst. Ändere die E-Mail einer Kundin in der Kundinnen-Datenbank, und sie aktualisiert sich überall, wo diese Information erscheint.

Das ist das „Single Source of Truth"-Prinzip. Und es ist nicht verhandelbar für verlässliche Systeme.

Kurz gesagt: Eine Wahrheit, überall verfügbar. Keine Dopplungen, keine veralteten Daten.

Die 5 Regeln für datenbankbasiertes Denken in Notion:
  1. Wenn es sich wiederholt, ist es eine Datenbank.
  2. Wenn es sich über Zeit verändert, ist es eine Datenbank.
  3. Wenn du es filtern willst, ist es eine Datenbank.
  4. Wenn es mit anderen Dingen verknüpft ist, ist es eine Datenbank.
  5. Seiten sind für Narrative, Datenbanken für Operationen.

Wann solltest du eine Datenbank statt einer Seite nutzen?

Wiederkehrende Information

Das klarste Signal, dass du eine Datenbank brauchst: Du erstellst dieselbe Art von Inhalt immer wieder.

Erstellst du wöchentliche Statusberichte? Das sind nicht 52 separate Seiten, das sind 52 Einträge in einer Statusberichte-Datenbank mit Eigenschaften für Datum, Highlights, Herausforderungen und nächste Schritte.

Onboardest du neue Mitarbeitende? Jedes Onboarding ist kein einzigartiges Dokument, sondern ein Eintrag in einer Onboarding-Datenbank, die den Fortschritt jeder Person durch deine Standard-Checkliste verfolgt.

Das Muster: Jedes Mal, wenn du ein Template wiederholt nutzt, solltest du stattdessen eine Datenbank verwenden.

Kurz gesagt: Wiederholung ist das Signal für Datenbanken.

Information, die sich über Zeit verändert

Information, die sich entwickelt, braucht eine Datenbankstruktur. Der Status einer Kundin ändert sich von Interessent zu Aktiv zu Abgeschlossen. Eine Aufgabe wandert von Nicht begonnen zu In Bearbeitung zu Erledigt. Ein Content-Stück geht von Idee zu Entwurf zu Veröffentlicht.

Diese Zustandsänderungen bilden Datenbank-Eigenschaften perfekt ab. Mit Status-Eigenschaften kannst du deine Ansicht filtern, um nur aktive Kundinnen oder nur laufende Aufgaben zu zeigen.

Versuch das mit Seiten. Du müsstest jede einzelne manuell durchgehen, um ihren aktuellen Zustand zu prüfen.

Datenbanken geben dir außerdem historisches Tracking. Du siehst, wann sich ein Projektstatus geändert hat, wer ihn verschoben hat und was er vorher war. Diese Änderungshistorie ist bei Seiten unsichtbar.

Kurz gesagt: Wenn Status sich ändert, brauchst du eine Datenbank.

Alles, was du filtern, sortieren oder analysieren willst

Hier ist der Lackmustest: Musst du jemals eine Teilmenge dieser Information nach bestimmten Kriterien sehen?

  • Alle Hochprioritäts-Aufgaben, die Sarah zugewiesen sind
  • Content, der nächsten Monat veröffentlicht wird
  • Kundinnen, die seit 30 Tagen kein Check-in hatten
  • Projekte über Budget

Wenn du deine Information in irgendeiner Weise aufschneiden willst, brauchst du eine Datenbank. Seiten können nicht gefiltert oder sortiert werden. Du musst manuell durch alle scrollen.

In dem Moment, in dem du Erkenntnisse aus deiner Information gewinnen willst, werden Datenbanken unverzichtbar.

Kurz gesagt: Filterung und Analyse erfordern Datenbanken, nicht Seiten.

Welche Fehler machen fast alle beim Datenbankaufbau?

Zu viele kleine Datenbanken

Eine Kundin zeigte mir letztens ihren Workspace: 27 separate Content-Datenbanken. Eine für jeden Monat seit sie angefangen hatte. "Ich wollte sauber zwischen den Zeiträumen trennen", sagte sie.

Das Problem: Sie konnte nicht mehr überblicken, was sie insgesamt produziert hatte. Keine Möglichkeit zu filtern. Keine Übersicht über Themen-Wiederholungen. Jede Monatsplanung bedeutete, 27 Datenbanken zu öffnen.

Das fragmentiert deine Information und macht den Zweck von Datenbanken zunichte.

Statt mehrere kleine Datenbanken zu erstellen, erstelle eine umfassende Datenbank mit Eigenschaften, die filtern und segmentieren. Eine Projekte-Datenbank mit einer „Quartal"-Eigenschaft. Eine Content-Datenbank mit einer „Typ"-Eigenschaft.

Das hält zusammenhängende Information zusammen und gibt dir trotzdem die Möglichkeit, Teilmengen zu sehen, wenn nötig.

Kurz gesagt: Konsolidiere Datenbanken. Nutze Eigenschaften zum Filtern.

Überladene Eigenschaften

Der gegenteilige Fehler: so viele Eigenschaften zu einer Datenbank hinzufügen, dass ihre Nutzung überwältigend wird.

Ich hab selbst Wochen gebraucht, um das zu verstehen. Meine erste Aufgaben-Datenbank hatte 19 Eigenschaften. Priorität, Energie-Level, geschätzte Dauer, tatsächliche Dauer, Kontext, Projekt, Bereich, Tags, Deadline, Start-Datum, Verantwortlich, Delegiert an, Blocker, Abhängigkeiten... und ich habe nie mehr als 6 davon ausgefüllt. Die anderen waren nur visuelle Last.

Eigenschaften sollten einem Zweck dienen. Frag dich: „Werde ich tatsächlich nach dieser Eigenschaft filtern, sortieren oder analysieren? Hilft sie mir, Entscheidungen zu treffen oder zu handeln?" Wenn nicht, weg damit.

Starte minimal. Du kannst später immer Eigenschaften hinzufügen, wenn du merkst, dass du sie brauchst. Aber Eigenschaften zu entfernen, nachdem Leute Zeit damit verbracht haben, sie auszufüllen, erzeugt Reibung und Widerstand.

Kurz gesagt: Weniger Eigenschaften, mehr Klarheit. Erweitere nur bei Bedarf.

Datenbanken wie Ordner behandeln

Nur weil du mehrere Ansichten in einer Datenbank erstellen kannst, heißt das nicht, dass du solltest. Manche Teams erstellen eine Ansicht für jedes Teammitglied, jedes Projekt, jeden Status – Dutzende Ansichten, die die verschachtelte Ordnerstruktur replizieren, der sie eigentlich entkommen wollten.

Das verfehlt den Punkt komplett. Ansichten sollten unterschiedliche Perspektiven auf dieselben Daten darstellen, nicht unterschiedliche Teilmengen, die gefiltert werden könnten.

Nutze Filter, um einzugrenzen, was du siehst, nicht Ansichten.

Kurz gesagt: Ansichten sind Perspektiven, keine Ordner. Filter reduzieren.

Achtung: Der häufigste Fehler ist, Datenbanken als schickere Ordner zu behandeln. Datenbanken sind keine Ablage. Sie sind strukturierte Systeme, die Fragen beantworten.

Wie schalten Datenbanken bessere Dashboards frei?

Ein Dashboard in Notion ist keine spezielle Funktion, sondern einfach eine Seite, auf der du verschiedene Datenbank-Ansichten zusammenstellst. Denk daran wie an deine Kommandozentrale: ein Ort, an dem du alles Wichtige auf einen Blick siehst, ohne zwischen verschiedenen Seiten hin und her springen zu müssen.

Dynamische Ansichten

Sobald deine Information in Datenbanken lebt, verwandeln sich deine Dashboards von statischen Seitensammlungen zu dynamischen Kommandozentralen.

Statt jede Woche manuell ein Projekt-Dashboard zu aktualisieren, erstellst du gefilterte Ansichten, die automatisch zeigen:

  • Gefährdete Projekte (gefiltert nach Status und Deadline)
  • Kürzlich abgeschlossene Erfolge (gefiltert nach Status und Abschlussdatum)
  • Was als Nächstes startet (gefiltert nach Timeline)

Die Information aktualisiert sich selbst, während dein Team arbeitet. Dein Dashboard wird zu einem Echtzeit-Abbild der Realität, nicht zu einem Schnappschuss, der in dem Moment veraltet ist, in dem du ihn erstellst.

Kurz gesagt: Dynamische Dashboards spiegeln Realität in Echtzeit.

Datenbankübergreifende Verknüpfungen

Die wahre Magie passiert, wenn du Datenbanken miteinander verbindest. Ein Projekt-Dashboard, das einzieht:

  • Aktive Projekte aus deiner Projekte-Datenbank
  • Diese Woche fällige Aufgaben aus deiner Aufgaben-Datenbank (gefiltert nach Projekt)
  • Kürzliches Kundinnen-Feedback aus deiner Meetings-Datenbank (gefiltert nach verknüpftem Projekt)
  • Team-Kapazität aus deiner Team-Datenbank

Jedes Informationsstück lebt an seinem richtigen Platz, taucht aber in deinem Dashboard genau dann auf, wenn du es brauchst. Ändere die Fälligkeit einer Aufgabe in deiner Hauptaufgaben-Datenbank, und dein Projekt-Dashboard spiegelt es sofort wider.

Kurz gesagt: Verknüpfte Datenbanken schaffen kontextbezogene Übersicht.

Echtzeit-Business-Transparenz

Hier liefern Datenbanken ROI für Unternehmen. Dein Führungs-Dashboard kann zeigen:

  • Pipeline-Wert (Summe der Deal-Werte, wo Status = „Aktiv")
  • Gefährdete Projekte (Anzahl, wo Status = „Gefährdet")
  • Team-Auslastung (berechnet aus Aufgaben und Zeitschätzungen)
  • Umsatzprognose (Rollup aus verlinkten Deal-Datenbanken)

Kein manuelles Reporting. Kein Spreadsheet-Export. Kein „Lass mich die Daten ziehen und zurückkommen." Die Antworten sind immer aktuell, immer genau, weil sie direkt aus deiner Single Source of Truth kommen.

Kurz gesagt: Datenbanken liefern Geschäftsinformationen ohne manuelles Reporting.

Wie sehen Datenbanken im Business konkret aus?

Aufgaben und Projekte

Eine Selbständige kam zu mir mit dem Problem: "Ich weiß nie, was mein Team gerade macht." Sie hatte 14 aktive Projekte, jedes mit seiner eigenen Seite. Jede Seite hatte eine Aufzählungsliste mit Tasks. Jeden Montag verbrachte sie 90 Minuten damit, alle 14 Seiten zu öffnen und den Status rauszuschreiben.

Statt für jedes Projekt eine Seite mit Aufzählungslisten zu erstellen, bau es so:

Projekte-Datenbank mit Eigenschaften:

  • Status (Nicht begonnen, Aktiv, Pausiert, Abgeschlossen)
  • Verantwortlich (Person)
  • Deadline (Datum)
  • Kundin (Beziehung zur Kundinnen-Datenbank)
  • Gesundheit (Gefährdet, Auf Kurs, Voraus)

Aufgaben-Datenbank mit Eigenschaften:

  • Status (Zu erledigen, In Bearbeitung, Erledigt)
  • Zugewiesen an (Person)
  • Projekt (Beziehung zur Projekte-Datenbank)
  • Fällig am (Datum)
  • Priorität (Hoch, Mittel, Niedrig)

Jetzt können deine Projektseiten automatisch alle verknüpften Aufgaben anzeigen. Dein persönliches Dashboard zeigt alle deine Aufgaben über alle Projekte. Deine Teamleitung sieht alles, woran ihr Team arbeitet.

Dieselbe Information, unendliche Perspektiven.

Kurz gesagt: Verknüpfte Aufgaben- und Projekte-Datenbanken schaffen Übersicht für alle Ebenen.

Kundinnen und CRM

Ein richtiges Kundinnen-Management-System sind keine einzelnen Kundinnen-Seiten, sondern eine Kundinnen-Datenbank, verbunden mit allem Kundinnen-Bezogenen:

Eigenschaften:

  • Status (Interessent, Aktiv, Inaktiv, Ehemalig)
  • Vertragswert (Zahl)
  • Verlängerungsdatum (Datum)
  • Account-Verantwortliche (Person)
  • Branche (Auswahl)

Verknüpfte Datenbanken:

  • Projekte (was wir für sie bauen)
  • Meetings (unsere Interaktionshistorie)
  • Rechnungen (finanzielle Beziehung)
  • Kontakte (wen wir dort kennen)

Diese Struktur lässt dich geschäftskritische Fragen sofort beantworten:

  • Welche Verträge laufen nächstes Quartal aus?
  • Was ist unser gesamter aktiver Vertragswert?
  • Mit welchen Kundinnen hatten wir kürzlich kein Meeting?

Kurz gesagt: Ein CRM in Datenbanken macht Kundenbeziehungen transparent und steuerbar.

Content und Marketing

Content-Ersteller starten oft mit einzelnen Seiten pro Inhalt. Ein Datenbank-Ansatz transformiert das:

Content-Datenbank mit Eigenschaften:

  • Typ (Blogartikel, Social Media, Newsletter, Video)
  • Status (Idee, Gliederung, Entwurf, Review, Geplant, Veröffentlicht)
  • Thema (Beziehung zur Themen-Datenbank)
  • Ziel-Keyword (Text)
  • Veröffentlichungsdatum (Datum)
  • Autor (Person)
  • Performance-Metriken (URL zu Analytics)

Erstelle Ansichten für:

  • Redaktionskalender (Kalender-Ansicht nach Veröffentlichungsdatum)
  • Content-Pipeline (Board-Ansicht gruppiert nach Status)
  • Autor-Workload (Tabellen-Ansicht gruppiert nach Autor)
  • Performance-Tracker (Tabellen-Ansicht sortiert nach Metriken)

Dieselbe Datenbank, völlig unterschiedliche Interaktionsmöglichkeiten mit deinem Content, je nachdem, was du erreichen willst.

Kurz gesagt: Content-Datenbanken machen Planung, Produktion und Performance messbar.

Wissensdatenbank

Selbst Dokumentation profitiert von Datenbank-Denken. Statt verschachtelter Wiki-Seiten erstelle eine Wissensdatenbank mit:

  • Kategorie (Auswahl)
  • Verantwortlich (Person, die für Updates verantwortlich ist)
  • Zuletzt aktualisiert (Datum)
  • Verknüpfter Prozess (Beziehung zur Prozesse-Datenbank)
  • Zugriffslevel (Auswahl)

Das macht deine Wissensdatenbank durchsuchbar, wartbar und verantwortlich. Du siehst, welche Dokumentation veraltet ist, wer jeden Bereich besitzt und wie Information mit deinen tatsächlichen Prozessen verbunden ist.

Kurz gesagt: Wissen in Datenbanken bleibt aktuell und zugänglich.

Wie arbeitest du mit mehreren Datenbanken gleichzeitig?

Die wahre Power von Notion-Datenbanken zeigt sich erst, wenn du sie miteinander kombinierst. Hier sind die wichtigsten Techniken:

Mehrere Datenbanken in einer Ansicht kombinieren

Stell dir vor, du willst auf deinem Dashboard alle wichtigen Informationen sehen, aber die leben in verschiedenen Datenbanken. Deine Aufgaben in der Aufgaben-Datenbank, deine Meetings in der Meetings-Datenbank, deine Content-Ideen in der Content-Datenbank.

Die Lösung: Linked Database Views. Das sind keine neuen Datenbanken, sondern zusätzliche Fenster auf bestehende Datenbanken.

So funktioniert's: Du erstellst auf deiner Dashboard-Seite eine verlinkte Ansicht deiner Aufgaben-Datenbank, gefiltert auf "Diese Woche fällig". Direkt darunter eine verlinkte Ansicht deiner Meetings-Datenbank, gefiltert auf "Nächste 7 Tage". Und darunter deine Content-Datenbank, gefiltert auf "In Bearbeitung".

Jede Änderung, die du in einer dieser Ansichten machst, aktualisiert automatisch die Original-Datenbank. Du arbeitest nicht mit Kopien, sondern mit Live-Ansichten.

Eine Kundin hat mir gezeigt, wie sie das nutzt: Ihr Team-Dashboard hat 7 verlinkte Ansichten aus 4 verschiedenen Datenbanken. Jedes Teammitglied sieht genau das, was für seine Rolle relevant ist, ohne zwischen Seiten wechseln zu müssen.

Auf den Punkt gebracht: Linked Database Views sind wie Fenster in verschiedene Räume – du stehst an einem Ort und siehst trotzdem alles.

Wie kombiniere ich mehrere Datenbanken in einem Kalender?

Wenn du mehrere Datenbanken mit Datumsfeldern hast – Meetings, Deadlines, Content-Veröffentlichungen, Events – willst du sie manchmal alle in einem Kalender sehen.

Das Problem: Notion erlaubt aktuell nicht, mehrere verschiedene Datenbanken in einer einzigen Kalenderansicht zu vereinen.

Die Lösung: Eine zentrale Kalender-Datenbank mit Relations.

Statt zu versuchen, mehrere Kalender zu verschmelzen, erstellst du eine "Kalender-Master-Datenbank" mit:

  • Titel (Text)
  • Datum (Datumseigenschaft)
  • Typ (Select: Meeting, Deadline, Event, Content, etc.)
  • Verknüpfte Aufgabe (Relation zur Aufgaben-Datenbank)
  • Verknüpftes Meeting (Relation zur Meetings-Datenbank)
  • Verknüpftes Content-Stück (Relation zur Content-Datenbank)

Jetzt trägst du in diesem zentralen Kalender nur noch Einträge mit Datum ein und verknüpfst sie mit den jeweiligen Originalen. Die Kalenderansicht dieser Datenbank zeigt dir dann wirklich alles auf einen Blick.

Alternativ: Nutze mehrere Linked Database Views in Kalenderansicht untereinander auf einer Seite. Nicht perfekt, aber du siehst alle Termine ohne zwischen Seiten zu springen.

Merke: Manchmal brauchst du keine Verschmelzung, sondern eine übergeordnete Struktur.

Datenbanken synchronisieren

Manchmal willst du, dass zwei Datenbanken automatisch synchronisiert werden.

Beispiel: Du hast eine Projekte-Datenbank und eine Rechnungen-Datenbank. Wenn ein Projekt abgeschlossen wird, soll automatisch eine Rechnung erstellt werden.

Die Wahrheit: Notion hat keine automatische Synchronisation zwischen Datenbanken. Aber es gibt Wege, die trotzdem funktionieren:

1. Relations nutzen

Statt zu synchronisieren, verknüpfe. Deine Rechnung verlinkt zum Projekt. Wenn du das Projekt öffnest, siehst du die verknüpfte Rechnung. Wenn du die Rechnung öffnest, siehst du das verknüpfte Projekt. Keine Duplizierung, keine Synchronisation nötig.

2. Rollup-Eigenschaften

Du kannst Daten aus verknüpften Datenbanken in deine aktuelle Datenbank "heraufziehen". Beispiel: Deine Rechnung zeigt automatisch den Projektstatus aus der verknüpften Projekte-Datenbank als Rollup-Eigenschaft. Ändert sich der Status im Projekt, siehst du das sofort in der Rechnung.

3. Formeln für berechnete Felder

Statt Daten zu kopieren, berechne sie. Wenn dein Rechnungsbetrag vom Projektstatus abhängt, nutze eine Formel, die auf die verknüpfte Datenbank zugreift.

Ich hab selbst lange versucht, Daten zwischen Datenbanken zu "synchronisieren", bis ich verstanden habe: Du musst nicht synchronisieren, wenn du richtig verknüpfst.

Kurz gesagt: Verknüpfungen und Rollups ersetzen Synchronisation. Speichere einmal, zeige überall.

Datenbanken zusammenführen oder kombinieren

Was machst du, wenn du merkst, dass du zwei separate Datenbanken hast, die eigentlich eine sein sollten?

Eine Kundin hatte drei separate Datenbanken: "Kunden-Projekte", "Interne Projekte" und "Pro-Bono-Projekte". Resultat: Sie konnte nie sehen, wie ausgelastet sie insgesamt war. Jede Planung bedeutete, drei Datenbanken zu checken.

Die Lösung: Konsolidieren statt fragmentieren.

So gehst du vor:

  1. Erstelle eine neue, umfassende Datenbank mit allen Eigenschaften, die du brauchst. Füge eine Select-Eigenschaft hinzu, die die alte Kategorisierung abbildet (z.B. "Projekttyp: Kunde, Intern, Pro-Bono").
  2. Verschiebe alle Einträge aus den alten Datenbanken in die neue. In Notion kannst du Einträge einfach zwischen Datenbanken verschieben (Rechtsklick auf einen Eintrag → "Move to" → andere Datenbank auswählen).
  3. Nutze Filter und Ansichten, um die alten Kategorien bei Bedarf zu sehen. Erstelle eine Ansicht "Nur Kundenprojekte" mit Filter auf Projekttyp = "Kunde".
  4. Lösche die alten Datenbanken, wenn alle Daten übertragen sind.

Das Prinzip: Eine große, flexible Datenbank mit intelligenten Filtern ist fast immer besser als viele kleine, starre Datenbanken.

Nach der Konsolidierung sagte die Kundin: "Ich sehe endlich, was wirklich los ist. 5 Minuten statt 30, jeden Morgen."

Ergo: Kombiniere durch Konsolidierung und Filter, nicht durch Duplizierung.

Fazit

Notion ist keine Dokumenten-Software, die zufällig Datenbank-Features hat. Es ist eine Datenbank-Plattform, die zufällig auch lange Texte verarbeiten kann.

Je früher du diese Realität akzeptierst, desto schneller verwandelt sich dein Workspace von einer schönen Seitensammlung, die du nicht wirklich nutzen kannst, in ein operatives System, das mit deinem Business mitwächst.

Der Unterschied ist nicht kompliziert. Er ist strukturell. Seiten speichern Information. Datenbanken schaffen Systeme.

Starte klein. Wähle einen Bereich, in dem du den Schmerz seitenbasierter Organisation spürst: vielleicht deine Projekte, dein Content, dein Kundinnen-Tracking. Baue eine gut strukturierte Datenbank mit den Eigenschaften, die du tatsächlich brauchst. Verknüpfe sie mit einer anderen Datenbank. Erstelle Ansichten, die dir helfen, schneller Entscheidungen zu treffen.

Du wirst den Unterschied sofort spüren. Information, deren Suche früher fünf Minuten dauerte, erscheint sofort. Updates, die mehrere Seiten ändern mussten, passieren jetzt an einem Ort. Erkenntnisse, die unsichtbar waren, werden offensichtlich.

Datenbanken skalieren, Seiten vermehren sich nur.

Kurz-Check: Drei Fragen für deinen Workspace

  1. Legst du dieselbe Art von Information immer wieder an verschiedenen Stellen ab?
  2. Verbringst du mehr Zeit mit Suchen als mit Arbeiten?
  3. Kannst du auf einfache Business-Fragen sofort Antworten geben oder musst du erst Information zusammentragen?

Häufig gestellte Fragen zu Notion-Datenbanken

Wann ist eine Seite besser als eine Datenbank?

Eine Seite ist richtig, wenn die Information einmalig und narrativ ist. Deine Unternehmensgeschichte. Dein Manifest. Eine lange Analyse, die du nur einmal schreibst. Sobald du denkst „Ich werde noch mehr davon brauchen", ist es eine Datenbank.

Kann ich eine Seite nachträglich in eine Datenbank umwandeln?

Notion hat keine direkte Umwandlungsfunktion. Du erstellst eine neue Datenbank und überträgst die Information strukturiert. Das fühlt sich nach Mehrarbeit an, zahlt sich aber sofort durch die gewonnene Funktionalität aus.

Wie viele Datenbanken brauche ich für mein Business?

Die meisten Solopreneurinnen kommen mit 5-8 Kern-Datenbanken aus: Projekte, Aufgaben, Kundinnen, Content, Finanzen, Meetings, Wissen. Alles andere sind oft Spezialfälle. Starte mit wenigen und erweitere nur bei echtem Bedarf.

Was mache ich, wenn eine Datenbank zu groß wird?

Große Datenbanken sind kein Problem für Notion. Das Problem ist meist eine fehlende Struktur. Nutze Ansichten mit klaren Filtern, sodass du nie die gesamte Datenbank auf einmal siehst, sondern immer nur den relevanten Ausschnitt.

Wie überzeuge ich mein Team, auf Datenbanken umzusteigen?

Zeig, nicht erklär. Baue eine gut strukturierte Datenbank für einen Schmerzpunkt auf. Lass sie die Geschwindigkeit und Übersicht erleben. Wenn Leute sehen, dass Fragen sofort beantwortet werden, überzeugt sich das Team selbst.

Sind Datenbanken nicht zu kompliziert für einfache Anwendungsfälle?

Eine einfache Datenbank mit drei Eigenschaften ist nicht komplizierter als eine Seite. Der Unterschied: Sie bleibt funktional, wenn du wächst. Seiten brechen. Datenbanken skalieren.


SEO-Daten

Title-Tag Varianten:

  1. Notion Datenbanken: Wie du von Seiten zu skalierbaren Systemen wechselst
  2. Warum Notion-Seiten scheitern und Datenbanken dein Business skalieren
  3. Das Datenbank-Mindset: Notion richtig strukturieren für Wachstum

Meta Description Varianten:

  1. Lerne, warum seitenbasierte Notion-Strukturen scheitern und wie Datenbanken dein Business skalierbar machen.
  2. Von Seiten zu Datenbanken: Der mentale Shift, der dein Notion von Chaos zu System verwandelt.
  3. Notion-Datenbanken richtig nutzen: Struktur statt Seiten, Systeme statt Dokumente, Skalierung statt Chaos.

Notion Datenbanken

Notion Datenbanken