Wie Du Deine erste KI-Datenbank aufbaust

Jetzt wird es konkret. Du hast die Theorie verstanden, die häufigsten Stolpersteine kennengelernt, und MariaDB läuft. Zeit für den praktischen Aufbau Deiner ersten produktiven KI-Datenbank. Diese wird anders aussehen als Standard-Web-Datenbanken, weil KI-Daten ihre eigenen Anforderungen haben.

Der wichtigste Unterschied: KI-Daten sind oft unstrukturiert und ändern sich häufig. Prompts werden iteriert, Modelle wechseln, neue Metadaten kommen hinzu. Deine Datenbankstruktur muss flexibel genug für Änderungen sein, aber strukturiert genug für effiziente Abfragen.

Beginne mit dem Kern: Users, Sessions, Prompts und Results. Diese vier Entitäten bilden das Herzstück praktisch aller KI-Anwendungen. Sessions verbinden zusammengehörige Prompts, Results speichern die KI-Antworten mit allen relevanten Metadaten.

Kern-Tabellen für KI-Anwendungen:

users: Grundlegende Benutzerverwaltung mit Preferences

sessions: Gruppierung zusammengehöriger KI-Interaktionen

prompts: Eingaben mit Metadaten und Versionierung

results: KI-Ausgaben mit Kosten, Timing und Quality-Ratings

models: Verfügbare KI-Modelle mit Capabilities und Pricing

Die Sessions-Tabelle ist oft übersehen, aber essential für Kontext. KI-Anwendungen sind meist konversationell: Eine Frage führt zur nächsten, Antworten bauen aufeinander auf. Sessions ermöglichen es Dir, diesen Kontext zu modellieren und auszuwerten.

JSON-Felder sind bei KI-Datenbanken besonders wertvoll. Model-spezifische Parameter, variable Metadaten, experimentelle Features - all das lässt sich flexibel in JSON speichern ohne die Tabellen-Struktur ständig zu ändern.

Erweiterte Prompts-Tabelle mit JSON:

CREATE TABLE prompts (

  id INT AUTO_INCREMENT PRIMARY KEY,

  session_id INT,

  user_id INT NOT NULL,

  prompt_text TEXT NOT NULL,

  system_prompt TEXT,

  temperature DECIMAL(3,2) DEFAULT 0.7,

  max_tokens INT DEFAULT 1000,

  model_params JSON,

  tags JSON,

  version INT DEFAULT 1,

  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

);

Versionierung ist bei KI-Prompts kritisch. Du wirst ständig experimentieren: verschiedene Formulierungen, andere Parameter, neue Ansätze. Ohne Versionierung verlierst Du erfolgreiche Varianten und kannst Rückschritte nicht nachvollziehen.

Die Results-Tabelle sollte nicht nur den Output speichern, sondern auch Performance-Daten. Response-Zeit, Token-Verbrauch, Kosten pro Anfrage - diese Daten sind Gold wert für Optimierung und Budgetplanung.

Umfassende Results-Tabelle:

CREATE TABLE results (

  id INT AUTO_INCREMENT PRIMARY KEY,

  prompt_id INT NOT NULL,

  result_text LONGTEXT,

  model_used VARCHAR(100) NOT NULL,

  tokens_input INT,

  tokens_output INT,

  cost_cents INT,

  response_time_ms INT,

  quality_rating TINYINT,

  error_code VARCHAR(50),

  model_metadata JSON,

  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

);

Error-Handling von Anfang an einbauen. KI-APIs sind nicht 100% zuverlässig: Rate Limits, Service-Ausfälle, Model-Überlasten passieren. Deine Datenbank sollte auch fehlgeschlagene Requests dokumentieren für Debugging und Retry-Logic.

Kategorisierung und Tagging ermöglichen Dir später bessere Auswertungen. "Content Creation", "Code Review", "Data Analysis" - kategorisiere Deine Prompts von Anfang an. Das hilft beim Filtern, Auswerten und Optimieren verschiedener Use Cases.

Flexible Kategorisierung implementieren:

CREATE TABLE categories (

  id INT AUTO_INCREMENT PRIMARY KEY,

  name VARCHAR(100) UNIQUE NOT NULL,

  description TEXT,

  color VARCHAR(7) DEFAULT '#666666'

);

ALTER TABLE prompts ADD COLUMN category_id INT,

ADD FOREIGN KEY (category_id) REFERENCES categories(id);

Soft Deletes sind bei KI-Daten besonders sinnvoll. Prompts und Results zu löschen vernichtet wertvolle Lerndaten. Stattdessen markiere Datensätze als gelöscht - so bleiben sie für Analysen verfügbar, aber verschwinden aus der normalen Anwendung.

Full-Text-Search über Prompts und Results einrichten. Du wirst häufig nach ähnlichen Prompts oder bestimmten Antworten suchen. MariaDB's Full-Text-Indizes machen das effizient und schnell.

Full-Text-Search aktivieren:

ALTER TABLE prompts ADD FULLTEXT(prompt_text);

ALTER TABLE results ADD FULLTEXT(result_text);

-- Suche nach ähnlichen Prompts:

SELECT * FROM prompts

WHERE MATCH(prompt_text) AGAINST('machine learning' IN NATURAL LANGUAGE MODE);

Audit-Trail für kritische Änderungen. Wenn mehrere Personen mit der KI-Datenbank arbeiten, willst Du nachvollziehen können, wer was wann geändert hat. Besonders bei Prompt-Optimierungen oder Model-Wechseln ist das wertvoll.

Performance-Indizes nicht vergessen. user_id, session_id, created_at, model_used - diese Felder werden häufig in WHERE-Klauseln verwendet und brauchen Indizes. Ohne sie werden Abfragen bei wachsenden Datenmengen langsam.

Archivierung von Anfang an mitdenken. KI-Daten können schnell groß werden, besonders bei intensiver Nutzung. Definiere Aufbewahrungszeiten: Was behältst Du wie lange? Was archivierst Du? Was löschst Du wirklich?

Einfache Archivierungsstrategie:

-- Alte Sessions archivieren (älter als 1 Jahr)

CREATE TABLE archived_sessions LIKE sessions;

CREATE TABLE archived_prompts LIKE prompts;

CREATE TABLE archived_results LIKE results;

-- Regelmäßiger Cleanup per Cron-Job

-- Verschiebe alte Daten in Archive-Tabellen

Testing-Framework für Deine Datenbankstruktur aufbauen. Erstelle Test-Daten, die realistisch sind: verschiedene Prompt-Längen, unterschiedliche Result-Größen, gemischte Kategorien. Entwickle gegen realistische Daten, nicht gegen drei Beispiel-Datensätze.

Mit dieser Struktur hast Du eine solide, erweiterbare Basis für KI-Anwendungen. Die Datenbank kann mit Deinen Anforderungen mitwachsen ohne grundlegende Umbauten. Als nächstes sorgen wir dafür, dass alles sicher bleibt.