Dokument - Letzte Änderungen [de]

Drupal

2026-08-18T16:42:33Z

Content Sync

← Nächstältere Version	Version vom 18. August 2026, 16:42 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
(kein Unterschied)

Drush installieren

2026-08-18T16:37:46Z

Die Seite wurde neu angelegt: „mmm“

Neue Seite

mmm

Drupal

2026-08-18T15:39:47Z

← Nächstältere Version		Version vom 18. August 2026, 15:39 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
	==Konfiguration exportieren (YAML)==		==Konfiguration exportieren (YAML)==
	Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:		Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
Zeile 49:		Zeile 50:
	! Methode !! Für !! Aufwand		! Methode !! Für !! Aufwand
	\|-		\|-
	\| Default Content \|\| Demo-Inhalte mit Modul ausliefern \|\| gering		\| [[Default Content]] \|\| Demo-Inhalte mit Modul ausliefern \|\| gering
	\|-		\|-
	\| Content Sync \|\| Staging→Live, identische Site-Struktur \|\| gering–mittel		\| Content Sync \|\| Staging→Live, identische Site-Struktur \|\| gering–mittel
Zeile 85:		Zeile 86:

	'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.		'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.
			==Hinweis==
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Drupal

2026-08-18T14:58:34Z

Die Seite wurde neu angelegt: „==Konfiguration exportieren (YAML)== Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert: <pre> drush config:export --destination=/pfad/zum/backup/config </pre> ==Inhalts Backup== ===Inhalte als CSV/XLSX=== Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/…“

Neue Seite

==Konfiguration exportieren (YAML)==
Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert:
<pre>
drush config:export --destination=/pfad/zum/backup/config
</pre>

==Inhalts Backup==
===Inhalte als CSV/XLSX===
Modul Views Data Export (drush en views_data_export). Du legst eine View auf Inhalte an, fügst eine Anzeige „Data Export" hinzu, wählst CSV/JSON/XML und die gewünschten Felder. Ergebnis ist ein Download-Pfad, den du auch per Cron automatisiert schreiben lassen kannst.
===Inhalte auf eine andere Drupal-Site übertragen===
====Default Content====
Modul: <pre>drush en default_content</pre>
Exportiert Nodes samt referenzierter Entitäten (Taxonomiebegriffe, Medien, …) als YAML/JSON-API-Dateien, ideal um Inhalte mit einem Modul/Install-Profil auszuliefern.
* Export: <pre>drush default-content-export node <nid></pre> bzw. <pre>drush default-content-export-module <modulname></pre> schreibt die Dateien nach <code>MODULENAME/content/node/</code>.
* Import: Modul auf der Zielsite aktivieren – die Inhalte werden bei der Installation automatisch importiert (Hook <code>hook_install</code> bzw. <code>default_content_deploy</code>).
* Einsatzzweck: Demo-Inhalte, die zusammen mit einem Feature/Modul ausgeliefert werden sollen.

====Content Sync====
Modul: <code>content_sync</code>. Funktioniert wie <code>drush config:export/import</code>, aber für Content-Entitäten.
<pre>
drush content-sync:export
drush content-sync:import
</pre>
Export schreibt Inhalte als YAML in einen Content-Sync-Ordner, Import liest sie auf der Zielsite wieder ein. Eignet sich für Staging→Live-Workflows mit identischer Site-Struktur, bei denen Content wie Konfiguration versioniert/deployed werden soll.

====Migrate API====
Module: <code>migrate_plus</code>, <code>migrate_tools</code>. Der robusteste, aber aufwändigste Weg – funktioniert auch bei unterschiedlichen Strukturen/Content-Types zwischen Quelle und Ziel.
* Migration-Definition als YAML (<code>migrate_plus.migration.*.yml</code>) mit drei Teilen:
** '''source''' – z. B. <code>url</code> (JSON:API der Quellsite), <code>csv</code>, <code>sql</code> (direkter DB-Zugriff)
** '''process''' – Feld-Mapping/Transformation (Quellfeld → Zielfeld, inkl. Transformationen wie Datumsformate)
** '''destination''' – z. B. <code>entity:node</code>
* Ausführen: <pre>
drush migrate:import migration_id
drush migrate:status
drush migrate:rollback migration_id
</pre>
Vorteil: wiederholbar und idempotent, daher gut geeignet für große oder strukturell abweichende Sites.

====Core JSON:API====
Kein Zusatzmodul nötig, nur Core-Modul <code>jsonapi</code> aktivieren.
* Alle Artikel: <pre>GET /jsonapi/node/article</pre> (Pagination über <code>page[offset]</code>/<code>page[limit]</code>)
* Einzelner Node: <pre>GET /jsonapi/node/article/{uuid}</pre>
* Referenzen mitladen: <pre>GET /jsonapi/node/article?include=field_tags,uid</pre>
* Anlegen auf Zielsite: <pre>POST /jsonapi/node/article</pre> mit Bearer-Token oder Basic-Auth-Berechtigung.
* Eignet sich als Quelle für eine Migration (siehe Migrate API, <code>source: plugin: url</code>) oder für eigene Skripte, die Daten abholen und auf der Zielsite wieder anlegen.

====Entscheidungshilfe====
{| class="wikitable"
! Methode !! Für !! Aufwand
|-
| Default Content || Demo-Inhalte mit Modul ausliefern || gering
|-
| Content Sync || Staging→Live, identische Site-Struktur || gering–mittel
|-
| Migrate API || große/strukturell abweichende Sites, wiederholbare Importe || hoch
|-
| JSON:API || Ad-hoc-Abfragen, eigene Skripte, Migrate-Quelle || gering (aber manuell)
|}

====Benutzerdaten ausschließen====
Bei allen vier Wegen hängt am Node standardmäßig ein Autor-Feld (<code>uid</code>), das sonst die komplette User-Entität (Name, E-Mail, Passwort-Hash, Rollen) mit hochziehen kann.

'''Views Data Export''': unkritisch – nur Felder, die explizit zur View hinzugefügt werden, landen im Export. Das Feld „Authored by“/„uid“ einfach nicht hinzufügen.

'''Default Content''': Der Exporter zieht referenzierte Entitäten (also auch den Autor) standardmäßig mit.
* Vor dem Export den Node-Autor auf einen neutralen, auf beiden Sites vorhandenen Account setzen (z. B. <code>uid: 1</code>), oder
* Nach dem Export das <code>uid</code>-Feld in der generierten YAML-Datei manuell entfernen/überschreiben, oder
* Per <code>hook_default_content_export_alter()</code> das <code>uid</code>-Feld aus dem zu exportierenden Entity-Array streichen, bevor die YAML geschrieben wird.

'''Content Sync''': Im Konfigurationsformular wählst du gezielt aus, welche Entity-Types synchronisiert werden. Lässt du „User“ dort weg, werden keine Benutzer-Entitäten exportiert/importiert – das <code>uid</code>-Feld am Node bleibt dann nur eine ID-Referenz, die auf der Zielsite auf einen dort bereits existierenden User zeigen muss (sonst leer/ungültig).

'''Migrate API''': am saubersten steuerbar – im <code>process</code>-Mapping das Quellfeld <code>uid</code> einfach nicht mappen oder fix auf einen Default-Wert setzen:
<pre>
process:
uid:
plugin: default_value
default_value: 1
</pre>
Damit wird die User-Quelle für diese Migration gar nicht erst abgefragt.

'''JSON:API''':
* Beim Abruf per Sparse Fieldset das <code>uid</code>-Feld weglassen und nicht in <code>include</code> aufführen: <pre>GET /jsonapi/node/article?fields[node--article]=title,body,field_tags</pre>
* Der anonymen/API-Rolle nicht die Berechtigung „View user information“ geben – dann liefert <code>/jsonapi/user/user</code> ohnehin nichts.
* Beim Anlegen (<code>POST /jsonapi/node/article</code>) die <code>uid</code>-Relationship einfach weglassen – Drupal setzt automatisch den authentifizierten API-User als Autor.

'''Empfehlung''': Statt echte Benutzerkonten zu übertragen, auf beiden Sites einen festen technischen Autor anlegen (z. B. „content-import“, gleiche <code>uid</code>/Name) und alle migrierten Inhalte auf diesen Account mappen. Das vermeidet auch DSGVO-Probleme, da Passwort-Hashes/E-Mails nie den Server verlassen.

Hauptseite

2026-08-18T14:57:44Z

Siehe auch

← Nächstältere Version	Version vom 18. August 2026, 14:57 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
(kein Unterschied)

Drupal

2026-08-18T10:59:09Z

Thorsten löschte die Seite Drupal Inhalt war: „==Voraussetzung== * Drush Installieren ==Konfiguration exportieren (YAML)== Die gesamte Website-Struktur (Content-Typen, Felder, Views, Taxonomie-Vokabulare, Rollen-Berechtigungen) wird als standardisierte YAML-Dateien exportiert: <pre> drush config:export --destination=/pfad/zum/backup/config </pre> Vorteil: Völlig unabhängig vom Datenbanksystem (PostgreSQL, MySQL,…“. Einziger Bearbeiter: Thorsten (Diskussion)

Drush Installieren

2026-08-18T10:56:11Z

Thorsten löschte die Seite Drush Installieren Inhalt war: „Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act). == Drush Installation in Drupal == Diese Seite beschreibt die Schritte zur Installation von '''Drush''' (Drupal Shell) über Composer in einem Drupal-Projekt. === Befehle === <syntaxhighlight lang="bash"> cd /…“. Einziger Bearbeiter: Thorsten (Diskussion)

Hauptseite

2026-08-18T05:42:20Z

Siehe auch

← Nächstältere Version		Version vom 18. August 2026, 05:42 Uhr
Zeile 101:		Zeile 101:
	* [[Weiter]]		* [[Weiter]]
	* [[Wissenssysteme & Tools im Überblick]]		* [[Wissenssysteme & Tools im Überblick]]
			* [[Drupal]]

	==Hinweis==		==Hinweis==
	Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).		Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Weiter

2026-08-15T12:40:03Z

← Nächstältere Version		Version vom 15. August 2026, 12:40 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1:		Zeile 1:

			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).


	Im Open-Source-Bereich gibt es eine breite Palette an ausgereiften Wissensmanagement- und Wiki-Systemen für das Self-Hosting. Je nach Struktur, gewünschter Benutzeroberfläche und Speicherbackend lassen sie sich in verschiedene Kategorien einteilen		Im Open-Source-Bereich gibt es eine breite Palette an ausgereiften Wissensmanagement- und Wiki-Systemen für das Self-Hosting. Je nach Struktur, gewünschter Benutzeroberfläche und Speicherbackend lassen sie sich in verschiedene Kategorien einteilen

Wissenssysteme & Tools im Überblick

2026-08-15T12:38:34Z

← Nächstältere Version		Version vom 15. August 2026, 12:38 Uhr
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
	==Klassische Regelsysteme & Inferenz (Rule Engines)==		==Klassische Regelsysteme & Inferenz (Rule Engines)==
	''Systeme, die Wissen als Wenn-Dann-Regeln abbilden und daraus automatisch Schlussfolgerungen (Inferenz) ableiten.''		''Systeme, die Wissen als Wenn-Dann-Regeln abbilden und daraus automatisch Schlussfolgerungen (Inferenz) ableiten.''

Grundbegriffe Informatik

2026-08-15T12:37:52Z

← Nächstältere Version		Version vom 15. August 2026, 12:37 Uhr
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
	__NOTOC__		__NOTOC__
	==Grundbegriffe Informatik==		==Grundbegriffe Informatik==

Wissenssysteme & Tools im Überblick

2026-08-15T12:36:06Z

Die Seite wurde neu angelegt: „ ==Klassische Regelsysteme & Inferenz (Rule Engines)== ''Systeme, die Wissen als Wenn-Dann-Regeln abbilden und daraus automatisch Schlussfolgerungen (Inferenz) ableiten.'' * CLIPS – In C entwickeltes, produktionsregelbasiertes Expertensystem-Toolkit, seit den 1980ern u. a. von der NASA genutzt. * Drools (KIE Community) – Java-basierte Business-Rules-Management-Engine mit Rete-Algorithmus, Teil der KIE-Plattform. * Pyke / Experta (Python) – Python-Bi…“

Neue Seite

==Klassische Regelsysteme & Inferenz (Rule Engines)==
''Systeme, die Wissen als Wenn-Dann-Regeln abbilden und daraus automatisch Schlussfolgerungen (Inferenz) ableiten.''
* CLIPS – In C entwickeltes, produktionsregelbasiertes Expertensystem-Toolkit, seit den 1980ern u. a. von der NASA genutzt.
* Drools (KIE Community) – Java-basierte Business-Rules-Management-Engine mit Rete-Algorithmus, Teil der KIE-Plattform.
* Pyke / Experta (Python) – Python-Bibliotheken für regelbasierte Wissensverarbeitung mit Vorwärtsverkettung (Forward Chaining).

==Wissensgraphen & Ontologien (Semantic Web)==
''Modellieren Wissen als vernetzte Graphen aus Entitäten und Beziehungen, oft nach Semantic-Web-Standards wie RDF/OWL.''
* Apache Jena – Java-Framework zum Erstellen und Abfragen RDF-basierter Wissensgraphen mit SPARQL-Unterstützung.
* Protégé – Open-Source-Editor der Stanford University zum Erstellen und Bearbeiten von Ontologien (OWL/RDF).
* Neo4j (Community Edition) – Weit verbreitete native Graphdatenbank mit der Abfragesprache Cypher.
* Memgraph – In-Memory-Graphdatenbank, kompatibel mit Cypher, optimiert für Echtzeit-Graphanalysen.

==Moderne KI-gestützte Wissenssysteme (RAG & Vektorsuche)==
''Kombinieren große Sprachmodelle mit externen Wissensquellen über Retrieval-Augmented Generation (RAG).''
* Dify – Low-Code-Plattform zum Erstellen von LLM-Anwendungen inkl. RAG-Pipelines und Agenten.
* RAGFlow – Open-Source-Engine speziell für RAG-Workflows mit tiefem Dokumentenverständnis.
* Onyx – Open-Source-Plattform für unternehmensweite KI-Suche und Chat über eigene Datenquellen (vormals Danswer).
* LlamaIndex – Framework zur Verbindung von LLMs mit strukturierten und unstrukturierten Datenquellen (Indexierung/Retrieval).
* LangChain – Framework zum Verketten von LLM-Aufrufen, Tools und Datenquellen zu komplexen Anwendungen.
* Ollama – Tool zum lokalen Ausführen und Verwalten von Open-Source-LLMs.
* LocalAI – Open-Source-Alternative zur OpenAI-API für lokal gehostete Sprachmodelle.

==Dokumentenbasiertes Wissensmanagement (Wikis & Docs)==
''Klassische Werkzeuge zum Erfassen, Strukturieren und gemeinsamen Bearbeiten von Wissen in Textform.''
* Wiki.js – Modernes, Node.js-basiertes Wiki-System mit Markdown-Unterstützung und ansprechender Oberfläche.
* Outline – Team-Wiki/Wissensdatenbank mit Fokus auf schnelle Suche und modernes Design.
* XWiki – Erweiterbare Open-Source-Wiki-Plattform mit eigenem Applikations-Framework.
* MediaWiki – Die Software hinter Wikipedia, weit verbreitet für offene und Unternehmens-Wikis.

==Integrierte Gesamtlösungen (Monolithen / Frameworks)==
''Große, oft modulare Plattformen, die Wissensmanagement in ein umfassenderes System integrieren.''
* Drupal mit Opigno & ECA – Content-Management-System Drupal, erweitert um Lernmanagement (Opigno) und Ereignis-Automatisierung (ECA).
* ILIAS – Open-Source-Lernmanagementsystem (LMS) mit Wissens- und Kursverwaltung, v. a. im Hochschulbereich.

==Wissenszentrierte & Semantische Systeme==
''Verbinden klassisches Wiki-Wissen mit semantischen Technologien.''
* Semantic MediaWiki (SMW) – Erweiterung für MediaWiki, die Seiteninhalte mit semantischen Annotationen zu einem Wissensgraphen verknüpft.

==Vektordatenbanken==
''Speichern und durchsuchen Daten anhand ihrer Vektor-Embeddings – Grundlage vieler RAG-Systeme.''
* Milvus – Skalierbare Open-Source-Vektordatenbank für Ähnlichkeitssuche in großen Datenmengen.
* Weaviate – Open-Source-Vektordatenbank mit integrierter Hybrid-Suche (Vektor + Keyword).
* Qdrant – Performante Open-Source-Vektor-Suchmaschine, geschrieben in Rust.
* Chroma – Leichtgewichtige, entwicklerfreundliche Vektordatenbank, beliebt in LLM-Prototypen.
* Pinecone – Vollständig verwalteter (Cloud-)Vektordatenbank-Dienst.

==Persönliches Wissensmanagement (PKM)==
''Werkzeuge für Einzelpersonen zum Vernetzen und Strukturieren persönlicher Notizen.''
* Obsidian – Lokal-first-Notiz-App mit verlinkten Markdown-Dateien und Graphenansicht.
* Logseq – Open-Source-Outliner mit Fokus auf verknüpftes, blockbasiertes Denken (ähnlich Roam Research).
* Notion – All-in-One-Arbeitsbereich für Notizen, Datenbanken und Wikis.
* TiddlyWiki – Nicht-lineares, einzeldateibasiertes persönliches Wiki im Browser.

==Enterprise Search / Volltextsuche==
''Ermöglichen das schnelle Durchsuchen großer, oft heterogener Datenbestände.''
* Elasticsearch – Verteilte Such- und Analyse-Engine auf Basis von Apache Lucene.
* OpenSearch – Community-Fork von Elasticsearch/Kibana nach der Lizenzänderung.
* Solr – Etablierte, ebenfalls auf Apache Lucene basierende Suchplattform.
* Meilisearch – Schnelle, entwicklerfreundliche Open-Source-Suchmaschine mit Relevanz "out of the box".

==Agenten- & Orchestrierungs-Frameworks==
''Koordinieren mehrere LLM-Aufrufe, Tools oder Agenten zu komplexeren automatisierten Abläufen.''
* AutoGen – Microsoft-Framework für Multi-Agenten-Konversationen zur Aufgabenlösung.
* CrewAI – Framework zur Orchestrierung rollenbasierter KI-Agenten-Teams.
* Haystack – Framework von deepset für Such- und RAG-Pipelines mit LLMs.
* n8n – Open-Source-Workflow-Automatisierungstool mit visueller Oberfläche, inkl. KI-Integrationen.

==Taxonomie- & Thesaurus-Management==
''Verwalten kontrollierte Vokabulare und Begriffshierarchien zur einheitlichen Verschlagwortung.''
* PoolParty – Kommerzielle Plattform für Taxonomie- und Wissensgraph-Management.
* TopBraid – Enterprise-Plattform für Ontologie-, Taxonomie- und Datenmanagement.
* SKOS-Tools – Werkzeuge rund um den W3C-Standard SKOS (Simple Knowledge Organization System) für kontrollierte Vokabulare.

==Konversationelle KI / Chatbot-Frameworks==
''Ermöglichen den Aufbau dialogbasierter Assistenzsysteme.''
* Rasa – Open-Source-Framework für kontextbewusste Chatbots und Sprachassistenten.
* Botpress – Open-Source-Plattform zum Erstellen und Betreiben von Konversations-Bots.

Hauptseite

2026-08-15T12:34:22Z

Siehe auch

← Nächstältere Version		Version vom 15. August 2026, 12:34 Uhr
Zeile 100:		Zeile 100:
	* [[Grundbegriffe Informatik]]		* [[Grundbegriffe Informatik]]
	* [[Weiter]]		* [[Weiter]]
			* [[Wissenssysteme & Tools im Überblick]]

	==Hinweis==		==Hinweis==
	Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).		Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Weiter

2026-08-15T09:36:37Z

Die Seite wurde neu angelegt: „Im Open-Source-Bereich gibt es eine breite Palette an ausgereiften Wissensmanagement- und Wiki-Systemen für das Self-Hosting. Je nach Struktur, gewünschter Benutzeroberfläche und Speicherbackend lassen sie sich in verschiedene Kategorien einteilen ==Moderne Wissensdatenbanken (Notion- & Confluence-Alternativen)== All-in-one-Arbeitsbereiche mit Seiten, Datenbanken und Blöcken – ersetzen Notion/Confluence im Self-Hosting. ==Entwicklerfreundliche & M…“

Neue Seite

Im Open-Source-Bereich gibt es eine breite Palette an ausgereiften Wissensmanagement- und Wiki-Systemen für das Self-Hosting. Je nach Struktur, gewünschter Benutzeroberfläche und Speicherbackend lassen sie sich in verschiedene Kategorien einteilen

==Moderne Wissensdatenbanken (Notion- & Confluence-Alternativen)==
All-in-one-Arbeitsbereiche mit Seiten, Datenbanken und Blöcken – ersetzen Notion/Confluence im Self-Hosting.

==Entwicklerfreundliche & Markdown-fokussierte Wikis==
Wikis, die primär mit Markdown arbeiten und sich vor allem an Entwickler-Teams richten.
* '''Wiki.js''' – Modernes Wiki mit Markdown-Editor, Git-Sync, feingranularer Rechteverwaltung und Node.js-Backend.

===Docs-as-Code-Generatoren===
Statische Seitengeneratoren, die Dokumentation aus Markdown-Dateien im Git-Repo erzeugen – Inhalte werden wie Code versioniert und reviewed.
* '''MkDocs mit Material-Theme''' – Python-basierter statischer Doku-Generator mit populärem, stark anpassbarem Material-Design-Theme.
* '''Docusaurus''' – React-basierter Doku-Generator von Meta, stark bei Versionierung und Mehrsprachigkeit.
* '''Astro Starlight''' – Doku-Theme auf Basis von Astro, sehr performant durch minimales JavaScript im Browser.
* '''VitePress''' – Vite-basierter, schneller statischer Seitengenerator, häufig für Vue-/JS-Projektdokumentationen genutzt.
* '''mdBook''' – Rust-Tool zum Erstellen von Büchern/Dokus aus Markdown, bekannt aus der offiziellen Rust-Dokumentation.

===Klassische Wiki-Engines===
Traditionelle, datenbankgestützte Wiki-Software mit eigener Syntax und Weboberfläche.
* '''MediaWiki''' – Software hinter Wikipedia, sehr mächtig und erweiterbar, aber vergleichsweise aufwändig im Betrieb.
* '''DokuWiki''' – Dateibasiertes Wiki ganz ohne Datenbank, dadurch einfach zu hosten und zu sichern.
* '''XWiki''' – Enterprise-Wiki mit Anwendungs-Baukasten für strukturierte Daten, Formulare und Skripting.

==Vernetztes Wissen & Personal Knowledge Management (PKM)==
Tools für vernetzte Notizen mit bidirektionalen Links, Backlinks und Graph-Ansicht – Fokus auf persönliches statt Team-Wissen.
* '''SilverBullet''' – Web-basiertes Markdown-Notizsystem mit eingebauter Automatisierung/Scripting.
* '''Joplin''' – Open-Source-Notiz-App mit Ende-zu-Ende-Verschlüsselung und Sync, Alternative zu Evernote.
* '''Logseq''' – Outliner-basiertes PKM-Tool mit Backlinks und Graph-Ansicht, ähnlich Roam Research.

==Git-basierte Wikis==
Wikis, die Inhalte direkt in einem Git-Repository speichern statt in einer Datenbank.
* '''Gollum''' – Einfaches Wiki, das direkt auf einem Git-Repo aufsetzt; jede Seite ist eine Datei im Repo.

==KI- & RAG-basierte Expertensysteme (Fokus: Eigene Dokumente abfragen)==
Anwendungen, die eigene Dokumente per Retrieval-Augmented Generation (RAG) durchsuchbar und per Chat befragbar machen.
* '''AnythingLLM''' – All-in-one-RAG-App mit UI, Nutzerverwaltung und Anbindung an lokale oder Cloud-LLMs.
* '''Open WebUI''' – Chat-Oberfläche für lokale LLMs (z. B. über Ollama), inkl. Dokumenten-RAG und Multi-User-Betrieb.
* '''Dify''' – Low-Code-Plattform zum Bauen von LLM-Apps und RAG-Workflows mit visuellem Editor.

==Vektordatenbanken (Semantische Suche)==
Speichern Text als Vektor-Embeddings, damit inhaltlich ähnliche statt nur wortgleiche Treffer gefunden werden – Grundlage jedes RAG-Systems.
* '''Qdrant''' – Performante Vektordatenbank in Rust, beliebt für RAG-Projekte, guter Hybrid-Search-Support.
* '''ChromaDB''' – Leichtgewichtige, einfach einzurichtende Vektordatenbank, oft für Prototypen genutzt.
* '''Milvus''' – Skalierbare Vektordatenbank für sehr große Datenmengen, produktionsreif für Enterprise-Einsatz.
* '''pgvector''' – PostgreSQL-Erweiterung für Vektorsuche – praktisch, wenn ohnehin schon Postgres im Einsatz ist.

==Content-Management-Systeme (CMS)==
Systeme zur Verwaltung und Veröffentlichung von Webinhalten (Seiten, Artikel, Medien) mit Redaktionsworkflows.

===Klassische CMS===
* '''Drupal''' – Sehr flexibles, aber komplexeres CMS mit feingranularer Rechteverwaltung, stark bei großen strukturierten Websites.

==LLM-Inferenz==
Software zum lokalen Ausführen von Sprachmodellen (Inference) – die Grundlage für alle self-hosted KI-Anwendungen.
* '''Ollama''' – Einfachste Möglichkeit, offene LLMs lokal laufen zu lassen; CLI + API, riesige Modellbibliothek.
* '''llama.cpp''' – Effiziente C/C++-Inferenz-Engine für LLMs, läuft auch auf schwacher Hardware/CPU.
* '''vLLM''' – Hochperformante Inferenz-Engine für Produktionseinsatz mit hohem Durchsatz (Batching, PagedAttention).
* '''LM Studio''' – Desktop-App mit GUI zum Herunterladen und Ausführen lokaler Modelle, einsteigerfreundlich.
* '''LocalAI''' – OpenAI-API-kompatible, self-hosted Inferenz-Lösung für Text-, Bild- und Audio-Modelle.
* '''text-generation-webui''' – Web-Oberfläche für lokale LLMs mit vielen Erweiterungen (Gradio-basiert).

===Agenten-optimierte Open-Source-Modelle===
Offene Sprachmodelle, die gezielt auf Tool-Calling/Function-Calling und Agenten-Verhalten trainiert wurden.
* '''Nous Hermes 3 / Hermes 2 Pro''' – Fine-Tunes von Llama/Mistral, stark bei strukturierten Funktionsaufrufen.
* '''Qwen2.5-Coder / Qwen-Agent''' – Alibabas Modellreihe, sehr gut bei Code und Agenten-Workflows.
* '''Mistral Small / NeMo''' – Kompakte, function-calling-fähige Modelle mit guter Geschwindigkeit-Qualitäts-Balance.

==Autonome KI-Agenten-Systeme==
Systeme, die selbstständig Teilziele planen und iterativ verfolgen, statt nur auf einzelne Prompts zu antworten.
* '''AutoGPT''' – Einer der ersten autonomen Agenten, zerlegt ein Ziel eigenständig in Teilaufgaben.
* '''BabyAGI''' – Minimalistischer autonomer Task-Agent mit Prioritätswarteschlange für Teilaufgaben.
* '''SuperAGI''' – Framework/Plattform zum Bauen und Verwalten mehrerer autonomer Agenten mit UI.
* '''Letta (MemGPT)''' – Agenten-Framework mit Fokus auf persistentem Langzeitgedächtnis über Sitzungen hinweg.
* '''CAMEL-AI''' – Framework für Multi-Agenten-Kommunikation ("Agenten reden miteinander"), gut für Simulationen.

==Autonome Coding-/Content-Agenten (Claude-Code-Alternativen)==
Agenten, die eigenständig Code schreiben, Dateien bearbeiten und Aufgaben im Terminal/Editor ausführen – vergleichbar mit Claude Code.
* '''Aider''' – CLI-Pair-Programming-Agent mit Git-Integration, funktioniert mit lokalen oder API-LLMs.
* '''Cline''' – Autonomer Coding-Agent als VS-Code-Extension, open source, unterstützt lokale Modelle.
* '''Continue.dev''' – Open-Source-Coding-Assistent/Agent, self-hostbar mit eigenem LLM-Backend.
* '''SWE-agent''' – Agent für vollständige Software-Engineering-Aufgaben, von Issue bis fertigem Pull Request.
* '''Devika''' – Open-Source-Alternative zu "Devin", autonomer Multi-Step-Coding-Agent.
* '''GPT Engineer''' – Generiert aus einer Prompt-Beschreibung eine komplette Codebasis.
* '''OpenHands''' – Autonomer Agent für Coding- und allgemeine Computeraufgaben (früher OpenDevin).

==Agenten-Frameworks==
Bibliotheken/Plattformen zum Orchestrieren mehrerer Agenten, Tools und Workflow-Schritten.
* '''LangGraph''' – Graph-basiertes Framework (von LangChain) für zustandsbehaftete, komplexe Agenten-Workflows.
* '''CrewAI''' – Framework für rollenbasierte Multi-Agenten-Teams ("Crew" aus spezialisierten Agenten).
* '''AutoGen / AG2''' – Microsofts Framework für Multi-Agenten-Konversationen und Tool-Nutzung.
* '''n8n''' – No-Code-Workflow-Automatisierung mit KI-Knoten, verbindet Agenten mit hunderten Diensten.
* '''Flowise''' – Visueller Low-Code-Builder für LLM-/RAG-/Agenten-Flows per Drag & Drop.

==Embedding- & Reranking-Modelle==
Modelle, die Text in Vektoren umwandeln (Embedding) bzw. Suchtreffer nach Relevanz neu sortieren (Reranking) – notwendig, damit RAG gute Treffer liefert.
* '''nomic-embed-text''' – Offenes, leistungsstarkes Embedding-Modell, gängiger Standard mit Ollama.
* '''bge-m3''' – Multilingual fähiges Embedding-Modell mit Unterstützung für sehr lange Texte.
* '''e5-mistral''' – Auf Mistral basierendes Embedding-Modell mit starker Retrieval-Qualität.
* '''bge-reranker''' – Sortiert erste Suchtreffer per Cross-Encoder nach tatsächlicher Relevanz neu.
* '''Jina Reranker''' – Alternative Reranking-Modellreihe von Jina AI, ebenfalls Cross-Encoder-basiert.

==Evaluation & Monitoring==
Tools zum Messen, ob RAG-/Agenten-Antworten korrekt, relevant und halluzinationsfrei sind, sowie zum Nachverfolgen von LLM-Aufrufen im Betrieb.
* '''Langfuse''' – Open-Source-Observability-Plattform für LLM-Anwendungen (Traces, Kosten, Prompt-Versionen).
* '''Ragas''' – Framework speziell zur automatisierten Bewertung von RAG-Pipelines (Relevanz, Treue, Vollständigkeit).
* '''Phoenix (Arize)''' – Open-Source-Tool zur Analyse und Visualisierung von LLM-Traces und Embedding-Räumen.

Hauptseite

2026-08-15T09:36:28Z

Siehe auch

← Nächstältere Version		Version vom 15. August 2026, 09:36 Uhr
Zeile 99:		Zeile 99:
	==Siehe auch==		==Siehe auch==
	* [[Grundbegriffe Informatik]]		* [[Grundbegriffe Informatik]]
			* [[Weiter]]

	==Hinweis==		==Hinweis==
	Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).		Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Grundbegriffe Informatik

2026-08-13T11:59:19Z

Änderungen zeigen

Grundbegriffe Informatik

2026-08-13T11:26:52Z

Die Seite wurde neu angelegt: „==Grundbegriffe Informatik== * Daten,Variablen und Datentypen * Datenstrukturen * Modelle * Algorithmen und Programmlogik ===Daten=== ====Wissensbasiertes System==== =====Die Ebenen der Datenverarbeitung===== * Faktendaten (Rohdaten & Information): * Repräsentiertes Wissen: Strukturierte Daten, die logische Zusammenhänge, Regeln oder Beziehungen beschreiben * Metadaten: Daten über die Daten =====Typen von Daten in Wissenssystemen===== Je nach Architekt…“

Neue Seite

==Grundbegriffe Informatik==
* Daten,Variablen und Datentypen
* Datenstrukturen
* Modelle
* Algorithmen und Programmlogik
===Daten===
====Wissensbasiertes System====
=====Die Ebenen der Datenverarbeitung=====
* Faktendaten (Rohdaten & Information):
* Repräsentiertes Wissen: Strukturierte Daten, die logische Zusammenhänge, Regeln oder Beziehungen beschreiben
* Metadaten: Daten über die Daten
=====Typen von Daten in Wissenssystemen=====
Je nach Architektur und Einsatzzweck des Systems werden unterschiedliche Datenformen genutzt:

'''A. Regelbasiertes Wissen (Explizites Wissen)'''
* Form: „Wenn–Dann“-Regeln (If-Then-Rules).
* Anwendung: Klassische Expertensysteme (z. B. in der Medizin oder bei der Fehlerdiagnose).
* Beispiel: ''Wenn der Fehlercode E-101 auftritt und der Druck > 5 bar ist, dann öffne Ventil B.''

'''B. Strukturierte Wissensgraphen & Ontologien'''
* Form: Entitäten (Knoten) und deren Beziehungen (Kanten).
* Anwendung: Semantic Web, moderne Wiki-Systeme, Enterprise Search.
* Beispiel: ''[Ahrensburg] --(ist eine Stadt in)--> [Schleswig-Holstein]''.

'''C. Dokumentenbasiertes / Unstrukturiertes Wissen'''
* Form: Volltexte, Markdown-Dateien, PDFs, Quellcode, Wiki-Seiten.
* Anwendung: Wissensmanagement-Plattformen, Dokumentations-Engines.
* Besonderheit: Oft kombiniert mit Volltext-Indizes oder Schlagwort-Katalogen zur schnellen Durchsuchbarkeit.

'''D. Vektor-Daten (für KI & RAG)'''
* Form: Einbettungen (Embeddings) – hochdimensionale numerische Vektoren, die die semantische Bedeutung von Texten darstellen.
* Anwendung: Modernes LLM-basiertes Wissensmanagement (Retrieval-Augmented Generation / RAG).
* Vorteil: Ermöglicht die Suche nach Bedeutung und Kontext, nicht nur nach exakten Begriffen.
===Variable===
====Speicherarten in menschlichen kognitiven Systemen====
In der Kognitionswissenschaft unterscheidet man bezüglich des veränderbaren (variablen) Wissens vor allem zwei Speicherformen im Langzeitgedächtnis:

'''Explizites / Deklaratives Wissen ("Wissen, dass")'''
* Episodisches Gedächtnis: Speichert konkrete, zeitlich gebundene Erlebnisse und Ereignisse (z. B. „Gestern habe ich Thema X unterrichtet").
* Semantisches Gedächtnis: Speichert allgemeines, dekontextualisiertes Fakten- und Konzeptwissen (z. B. „Ein Verb beschreibt eine Handlung"). Dieses Netz aus Konzepten passt sich dynamisch an, wenn neue Regeln oder Fakten gelernt werden.

'''Implizites / Prozedurales Wissen ("Wissen, wie")'''
* Speichert Handlungsabläufe und Fertigkeiten (z. B. Grammatikregeln im Sprachgebrauch anwenden). Es verändert sich schrittweise durch Automatisierung und Praxis.

====Speicherungsarten in technischen/digitalen Systemen (KI & Software)====
Bei variablen Wissenssystemen in der Informatik unterscheidet man hauptsächlich zwei Speicherebenen:

'''A) Parameter-Speicher (Parametrisches Wissen)'''
* Wie gespeichert? In den mathematischen Verknüpfungen (Gewichten) neuronaler Netze.
* Variabilität: Ändert sich kontinuierlich während des Trainings oder Fine-Tunings. Einmal trainiert, ist dieses Wissen im laufenden Betrieb jedoch oft starr.

'''B) Externe Vektor- und Graphdatenbanken (Non-parametrisches Wissen)'''
* Wie gespeichert? Informationen werden als Einbettungen (Vectors) oder als semantische Netze (Knowledge Graphs) in Datenbanken abgelegt.
* Variabilität: Sehr hoch. Neue Daten können jederzeit hinzugefügt, aktualisiert oder gelöscht werden, ohne das Grundmodell neu zu trainieren (z. B. bei RAG-Systemen – Retrieval-Augmented Generation).
===Datentypen===
====1. Primitive / Elementare Datentypen====
Diese bilden die kleinsten Bausteine jedes Systems:
* Ganzzahlen (Integer): Diskrete Werte ohne Nachkommastellen (z. B. -42, 0, 1024).
* Gleitkommazahlen (Float, Double): Reelle Zahlen mit Nachkommastellen (z. B. 3.14159).
* Wahrheitswerte (Boolean): Binärwerte (true / false bzw. 1 / 0).
* Zeichen & Zeichenketten (Char, String): Textdaten (z. B. "Wissensgraph").
* Datum & Zeit (Date, Timestamp): Zeitstempel zur zeitlichen Einordnung von Wissen.

====2. Strukturierte & Komplexe Datentypen====
Dienen dazu, mehrere Datenpunkte logisch miteinander zu verknüpfen:

{| class="wikitable"
! Datentyp !! Beschreibung !! Beispiel / Anwendungsfall
|-
| Listen / Arrays || Geordnete Reihenfolge von Elementen || [1, 2, 3, 5, 8]
|-
| Schlüssel-Wert-Paare (Maps / Dictionaries) || Zuordnung von eindeutigen Keys zu Werten || {"Titel": "Artikel", "Autor": "Max"}
|-
| Sätze (Sets) || Ungeordnete Mengen ohne Duplikate || {Rot, Grün, Blau}
|-
| JSON / BSON || Hierarchisch strukturierte Dokumente || Ideal für semi-strukturierte Wissenseinträge
|-
| Blob / Binary || Unstrukturierte Binärdaten || Bilder, Audio-Dateien, Dokumente
|}

====3. Semantische Datentypen (Wissensrepräsentation)====
In modernen Wissenssystemen (z. B. RDF, OWL, Knowledge Graphs) gehen Datentypen über rein technische Formate hinaus und beschreiben Bedeutung und Beziehungen:
* Entitäten / Ressourcen (URIs/IRIs): Eindeutige Identifikatoren für Objekte, Personen oder Konzepte (z. B. http://example.org/person/Thorsten).
* Literale: Konkrete Werte, die an Entitäten hängen (oft kombiniert mit XML-Schema-Datentypen wie xsd:string oder xsd:dateTime).
* Relational- / Kanten-Typen (Predicates): Beschreiben die Art der Beziehung zwischen zwei Entitäten (z. B. istAutorVon, gehörtZuKategorie).
* Vektoren (Embeddings): Dichte numerische Vektoren, die von KI-Modellen und Vektordatenbanken verwendet werden, um semantische Ähnlichkeit zwischen Texten oder Konzepten abzubilden.

===Datenstrukturen===
Wissenssysteme (Knowledge Management Systems, Wissensdatenbanken) nutzen je nach Einsatzzweck, Flexibilität und Abfragesprache ganz unterschiedliche Datenstrukturen. Hier ist eine Übersicht der wichtigsten Strukturen – von einfach und unstrukturiert bis hin zu hochkomplex und semantisch vernetzt:

====1. Unstrukturierte & Hierarchische Strukturen====
'''Flat Files / Plain Text (Markdown, Wikitext)'''
* Funktionsweise: Daten liegen in einfachen Textdateien vor (oft mit Frontmatter für Metadaten).
* Vorteile: Extrem schnell, versionierbar (z. B. via Git), zukunftssicher und ohne Datenbank-Overhead.
* Einsatz: Static Site Generators (Hugo, Jekyll), moderne Notiz-Systeme (Obsidian, Logseq), flache Dokumentationen.

'''Baumstrukturen & Taxonomien'''
* Funktionsweise: Hierarchische Anordnung in Ordnern, Kategorien oder Unterkategorien (Eltern-Kind-Beziehungen).
* Vorteile: Intuitive Navigation für Menschen, klar abgegrenzte Themenbereiche.
* Einsatz: Klassische Dateisysteme, Firmen-Wikis, Inhaltsverzeichnisse.

====2. Strukturierte & Relationale Datenstrukturen====
'''Relationale Datenbanken (SQL)'''
* Funktionsweise: Tabellen mit festem Schema, Primär- und Fremdschlüsseln (z. B. PostgreSQL, MySQL).
* Vorteile: Hohe Datenintegrität (ACID-Konformität), ausgereifte Abfragesprachen, hervorragend für strukturierte Metadaten.
* Einsatz: Klassische Enterprise-CMS (Drupal, TYPO3), Lernplattformen (Moodle), MediaWiki.

'''Dokumentenorientierte Datenbanken (NoSQL)'''
* Funktionsweise: Speicherung in semi-strukturierten Formaten wie JSON, BSON oder XML.
* Vorteile: Flexibles Schema, einfache Skalierbarkeit, schnelle Entwicklung bei sich ändernden Datenmodellen.
* Einsatz: MongoDB, CouchDB, dynamische Wissensplattformen.

====3. Semantische & Vernetzte Strukturen (Graph-basiert)====
'''Eigenschaftsgraphen (Property Graphs)'''
* Funktionsweise: Knoten (Entitäten) und Kanten (Beziehungen) tragen Schlüssel-Wert-Paare (Attributes).
* Vorteile: Abfrage von komplexen, tief verschachtelten Zusammenhängen ohne teure SQL-JOINs.
* Einsatz: Neo4j, Memgraph, Wissensnetze, Empfehlungsdienste.

'''RDF-Tripel / Semantisches Web (Knowledge Graphs)'''
* Funktionsweise: Wissen wird in Form von Aussagen-Tripeln gespeichert: Subjekt → Prädikat → Objekt (z. B. „Ahrensburg → liegtIn → Schleswig-Holstein").
* Vorteile: Standardisiert (W3C, SPARQL, OWL), erlaubt automatische logische Schlussfolgerungen (Inferenz).
* Einsatz: Wikidata, DBpedia, Semantic MediaWiki, ontologiebasierte Expertensysteme.

====4. Moderne & Vektorbasierte Strukturen====
'''Vektordatenbanken (Embeddings)'''
* Funktionsweise: Texte oder Objekte werden durch Machine-Learning-Modelle in hochdimensionale Vektoren (Zahlenreihen) umgewandelt.
* Vorteile: Ermöglicht semantische Suche (Suche nach Bedeutung statt nach exakten Stichwörtern) und Retrieval-Augmented Generation (RAG).
* Einsatz: Pinecone, Qdrant, Chroma, pgvector für KI-Assistenten und LLM-Erweiterungen.
===Modelle===
Während die vorigen Abschnitte einzelne Daten, Datentypen und Datenstrukturen behandeln, beschreibt ein '''Modell''' das übergeordnete Ordnungsprinzip, nach dem ganze Wissensbestände organisiert werden. Die folgenden sieben Modelle sind die in der Praxis dominierenden Ansätze, von einfach bis hochformal.

====1. Hierarchisches / Baum-Modell (Tree / Folder Model)====
* Prinzip: Ordnung über verschachtelte Ordner, Kategorien oder Seitenbäume (Eltern-Kind-Beziehung).
* Typischer Einsatz: Klassische CMS, Dateisysteme, Notiz-Apps (wie Notion, Confluence).
* Vorteil: Intuitive Bedienung, klare Navigation.
* Nachteil: Wissen lässt sich oft nicht eindeutig einem Fachbereich zuordnen (Problem der eierlegenden Wollmilchsau).

====2. Flaches Modell mit Metadaten & Tags (Flat / Key-Value Model)====
* Prinzip: Alle Dokumente liegen auf einer Ebene ("Flat-File") und werden über Schlagwörter (Tags), Taxonomien oder Key-Value-Eigenschaften charakterisiert.
* Typischer Einsatz: Flat-File CMS (z. B. Grav, Kirby), statische Wissensdatenbanken (Markdown-basiert mit Frontmatter).
* Vorteil: Keine starre Ordnerstruktur, hochgradig durchsuchbar, extrem einfach zu sichern/versionieren (z. B. mit Git).
* Nachteil: Ohne disziplinierte Verschlagwortung geht die Übersicht schnell verloren.

====3. Relationales Datenmodell (Relational Model / SQL)====
* Prinzip: Wissen wird in zusammenhängenden Tabellen (Entitäten, Attribute, Fremdschlüssel) strukturiert.
* Typischer Einsatz: Enterprise-Wikis, Moodle/LMS, strukturierte Unternehmensdatenbanken.
* Vorteil: Hohe Datenintegrität, komplexe Abfragen über Fremdschlüssel und Tabellenverknüpfungen möglich.
* Nachteil: Starres Schema; Schemaänderungen bei sich veränderndem Wissen sind aufwendig.

====4. Netzwerk- / Graphen-Modell (Graph Model)====
* Prinzip: Daten bestehen aus Knoten (Entitäten/Dokumenten) und Kanten (Beziehungen).
* Typischer Einsatz: Personal Knowledge Management (z. B. Obsidian, Roam Research), Graph-Datenbanken (Neo4j).
* Vorteil: Spiegelt vernetztes Denken wider. Beziehungen wie ''[Projekt X] --hängt ab von--> [Technologie Y]'' sind native Bestandteile der Datenbank.
* Nachteil: Schwer zu visualisieren/navigieren bei sehr großen Datenmengen ohne gute Filter.

====5. Semantisches / Triples-Modell (RDF / Knowledge Graph)====
* Prinzip: Wissen wird in formallogischen Aussagen aus Subjekt – Prädikat – Objekt (Triples) gespeichert (z. B. ''[MediaWiki] [verwendet] [PostgreSQL]'').
* Typischer Einsatz: Semantic MediaWiki, Wikidata, Ontologie-Systeme (OWL, RDF/SPARQL).
* Vorteil: Maschinenlesbar, erlaubt automatische logische Rückschlüsse (Inferenz) und komplexe semantische Abfragen.
* Nachteil: Hohe Einarbeitungszeit und formale Komplexität beim Erstellen der Ontologien.

====6. Dokumentenorientiertes Modell (NoSQL / JSON)====
* Prinzip: Ein Wissenselement ist ein eigenständiges, strukturiertes Dokument (z. B. JSON/YAML), das eingebettete Attribute und Arrays enthält.
* Typischer Einsatz: CouchDB, MongoDB, elasticsearch-basierte Wissensspeicher.
* Vorteil: Flexibles Schema; jedes Dokument kann individuelle Felder haben, ohne das Gesamtsystem zu blockieren.
* Nachteil: Redundanzen bei Datenbanksicherungen, schwächere Konsistenzprüfungen als bei SQL.

====7. Vektorraum-Modell (Embedding / Latent Space Model)====
* Prinzip: Wissen wird nicht symbolisch, sondern als Position in einem hochdimensionalen Vektorraum repräsentiert; semantische Nähe entspricht geometrischer Nähe (siehe auch [[#Vektor-Daten (für KI & RAG)|Vektor-Daten]] weiter oben).
* Typischer Einsatz: Retrieval-Augmented Generation (RAG), semantische Suche, Empfehlungssysteme (Pinecone, Qdrant, pgvector).
* Vorteil: Findet Zusammenhänge über Bedeutung statt exakter Begriffe, robust gegenüber Synonymen und unscharfen Anfragen.
* Nachteil: Nicht direkt interpretierbar ("Black Box"), keine expliziten Regeln oder Beziehungen wie im Graphen-Modell.

'''Hinweis:''' In der Praxis werden diese Modelle selten pur eingesetzt, sondern kombiniert – dieses Wiki selbst ist ein Beispiel: Es nutzt eine Baumstruktur (Modell 1, über die `==`/`===`-Überschriften), liegt aber als flache, versionierte Textdatei vor (Modell 2).

{| class="wikitable"
! Nr. !! Modell !! Kernprinzip !! Größter Vorteil !! Größter Nachteil
|-
| 1 || Hierarchisch (Baum) || Eltern-Kind-Verschachtelung || Intuitive Navigation || Eindeutige Einordnung oft unmöglich
|-
| 2 || Flach mit Tags || Ebene Dateien + Metadaten || Einfach, git-versionierbar || Erfordert Tagging-Disziplin
|-
| 3 || Relational (SQL) || Tabellen + Fremdschlüssel || Hohe Datenintegrität || Starres Schema
|-
| 4 || Graph (Property Graph) || Knoten + Kanten || Bildet vernetztes Denken ab || Schwer visualisierbar bei großer Skala
|-
| 5 || Semantisch (RDF/Triples) || Subjekt–Prädikat–Objekt || Maschinelle Inferenz möglich || Hoher Formalisierungsaufwand
|-
| 6 || Dokumentenorientiert (NoSQL) || Eigenständige JSON-Dokumente || Flexibles Schema || Schwächere Konsistenzprüfung
|-
| 7 || Vektorraum (Embeddings) || Position im semantischen Raum || Suche nach Bedeutung statt Begriff || Nicht direkt interpretierbar
|}

===Algorithmen und Programmlogik===
Wenn es darum geht, Algorithmen und Programmlogik bildhaft, strukturiert oder regelbasiert darzustellen, unterscheidet man zwischen visuellen Repräsentationsformen (zur Dokumentation und Planung) und formalen Wissenssystemen (zur automatischen Verarbeitung).

====1. Visuelle Wissenssysteme & Graphische Modelle====
Diese Systeme helfen Entwicklern und Lernenden, die Logik eines Programms unabhängig von einer konkreten Programmiersprache zu visualisieren.

{| class="wikitable"
! System / Modell !! Einsatzbereich !! Besonderheit / Logikbausteine
|-
| Nassi-Shneiderman-Diagramm (Struktogramm) || Strukturierte Programmierung, Lehre & Didaktik || Vermeidet Unordnung (kein Pfeilsalat). Basiert auf Sequenz, Auswahl (If-Else) und Wiederholung (Schleifen).
|-
| Programmablaufplan (PAP) / Flowchart || Prozessvisualisierung, technische Abläufe || Klassisches Flussdiagramm (DIN 66001) mit Pfeilen, Rauten für Entscheidungen und Rechtecken für Aktionen.
|-
| UML-Aktivitätsdiagramm || Software-Engineering, objektorientiertes Design || Standard in der Industrie. Zeigt komplexe Kontroll- und Datenflüsse inklusive paralleler Verzweigungen.
|-
| Entscheidungstabellen || Komplexe Geschäftslogik & Regelwerke || Stellt alle möglichen Bedingungen und daraus resultierende Aktionen in Tabellenform gegenüber.
|}

====2. Formale & Regelbasierte Wissenssysteme====
Diese Systeme dienen nicht nur der Visualisierung, sondern führen Programmlogik und Regeln direkt aus:

'''Regelbasierte Systeme & Expertensysteme'''
* Funktionsweise: Wissen wird in Form von Fakten und Logikregeln (WENN Bedingung DANN Aktion) gespeichert. Eine Inferenzmaschine (Inference Engine) wertet diese Logik aus.
* Beispiele:
** Prolog: Deklarative Programmierung basierend auf Prädikatenlogik.
** Drools / Business Rules Engines: Für komplexe Geschäftsregeln im Unternehmensumfeld.

'''Pseudocode & Algorithmen-Markup'''
* Funktionsweise: Eine strukturierte, halbsprachliche Beschreibung von Logik. Er kombiniert natürliche Sprache mit Elementen höherer Programmiersprachen.
* Vorteil: Unabhängig von Syntaxfehlern und konzentriert auf das reine Problemlösungsmuster.

Hauptseite

2026-08-13T11:26:02Z

Hinweis

← Nächstältere Version		Version vom 13. August 2026, 11:26 Uhr
Zeile 97:		Zeile 97:
	* CI/CD: Automatisierte Tests und Deployments.		* CI/CD: Automatisierte Tests und Deployments.
	* Backup-Strategie: Regelmäßige Sicherung von Datenbank und Medien-Storage.		* Backup-Strategie: Regelmäßige Sicherung von Datenbank und Medien-Storage.
			==Siehe auch==
			* [[Grundbegriffe Informatik]]
	==Hinweis==		==Hinweis==
	Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).		Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Wiki.js Rust-Datenmodell

2026-08-12T14:39:41Z

← Nächstältere Version		Version vom 12. August 2026, 14:39 Uhr
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

	Dieses Dokument beschreibt ein reines Rust-Datenmodell (Structs/Enums, ohne externe Crates wie <code>serde</code>, <code>sqlx</code> oder <code>chrono</code>) für das PostgreSQL-Schema von [https://github.com/requarks/wiki Wiki.js] (<code>server/models/*.js</code> + Knex-Migrationen). Der vollständige Quelltext liegt in <code>wikijs_models.rs</code>.		Dieses Dokument beschreibt ein reines Rust-Datenmodell (Structs/Enums, ohne externe Crates wie <code>serde</code>, <code>sqlx</code> oder <code>chrono</code>) für das PostgreSQL-Schema von [https://github.com/requarks/wiki Wiki.js] (<code>server/models/*.js</code> + Knex-Migrationen). Der vollständige Quelltext liegt in <code>wikijs_models.rs</code>.
Zeile 926:		Zeile 927:
	[[Category:Wiki.js]]		[[Category:Wiki.js]]
	[[Category:Datenmodell]]		[[Category:Datenmodell]]
			==Hinweis==
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Speicherung

2026-08-12T14:38:17Z

← Nächstältere Version		Version vom 12. August 2026, 14:38 Uhr
Zeile 1:		Zeile 1:
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

	== Wissensspeicherung ==		== Wissensspeicherung ==

Zeile 282:		Zeile 284:
	[[Kategorie:Rust]]		[[Kategorie:Rust]]
	[[Kategorie:Datenspeicherung]]		[[Kategorie:Datenspeicherung]]
			==Hinweis==
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Wissensmodell

2026-08-12T14:37:06Z

← Nächstältere Version		Version vom 12. August 2026, 14:37 Uhr
Zeile 1:		Zeile 1:

			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

	Ein '''Wissensmodell''' (engl. ''knowledge model'') ist eine strukturierte, formale Repräsentation von Wissen über einen bestimmten Bereich (Domäne). Es ermöglicht einem System, Wissen zu speichern, zu verknüpfen, abzufragen und daraus neue Schlüsse zu ziehen. Dieser Artikel beschreibt zunächst das Konzept allgemein und danach, wie man ein solches Modell konkret in der Programmiersprache '''Rust''' umsetzen kann.		Ein '''Wissensmodell''' (engl. ''knowledge model'') ist eine strukturierte, formale Repräsentation von Wissen über einen bestimmten Bereich (Domäne). Es ermöglicht einem System, Wissen zu speichern, zu verknüpfen, abzufragen und daraus neue Schlüsse zu ziehen. Dieser Artikel beschreibt zunächst das Konzept allgemein und danach, wie man ein solches Modell konkret in der Programmiersprache '''Rust''' umsetzen kann.
Zeile 119:		Zeile 121:
	[[Kategorie:Wissensmodellierung]]		[[Kategorie:Wissensmodellierung]]
	[[Kategorie:Rust]]		[[Kategorie:Rust]]
			==Hinweis==
			Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Speicherung

2026-08-12T14:32:58Z

Die Seite wurde neu angelegt: „== Wissensspeicherung == Dieser Artikel beschreibt zunächst das allgemeine Konzept der Wissensspeicherung und geht anschließend auf die konkrete technische Umsetzung in Rust ein. == Allgemeines Konzept der Wissensspeicherung == Bevor man eine konkrete Technik wählt, lohnt sich der Blick auf das allgemeine Konzept: Wie wird aus rohen Daten überhaupt "Wissen", und wie wird dieses Wissen in einem System organisiert und gespeichert? === Von Daten zu W…“

Neue Seite

== Wissensspeicherung ==

Dieser Artikel beschreibt zunächst das allgemeine Konzept der Wissensspeicherung und geht anschließend auf die konkrete technische Umsetzung in Rust ein.

== Allgemeines Konzept der Wissensspeicherung ==

Bevor man eine konkrete Technik wählt, lohnt sich der Blick auf das allgemeine Konzept: Wie wird aus rohen Daten überhaupt "Wissen", und wie wird dieses Wissen in einem System organisiert und gespeichert?

=== Von Daten zu Wissen: die DIKW-Hierarchie ===

Ein verbreitetes Modell zur Einordnung ist die '''DIKW-Pyramide''' (Data – Information – Knowledge – Wisdom):

{| class="wikitable"
! Stufe !! Beschreibung !! Beispiel
|-
| '''Daten''' (Data) || rohe, unverarbeitete Symbole/Werte ohne Kontext || <code>23</code>
|-
| '''Information''' || Daten mit Kontext/Bedeutung || "Die Temperatur beträgt 23 °C"
|-
| '''Wissen''' (Knowledge) || Information verknüpft mit Erfahrung/Regeln, nutzbar für Entscheidungen || "Bei 23 °C sollte man nicht heizen"
|-
| '''Weisheit''' (Wisdom) || begründete Anwendung von Wissen im Kontext || "Wann sich Heizen trotzdem lohnt"
|}

Ein Wissensspeicher (Knowledge Store) zielt darauf ab, mindestens die Ebene "Wissen" abzubilden – also nicht nur Rohwerte, sondern auch deren Bedeutung, Kontext und Beziehungen untereinander.

=== Explizites vs. implizites Wissen ===

* '''Explizites Wissen''' – lässt sich klar formulieren, dokumentieren und speichern (Texte, Regeln, Datenbankeinträge, Diagramme).
* '''Implizites/Tacit Wissen''' – erfahrungsbasiertes Wissen, das schwer zu formalisieren ist (Intuition, Handlungswissen).

Wissenssysteme können nur explizites Wissen direkt speichern; implizites Wissen muss zuerst "externalisiert" werden (z. B. durch Dokumentation, Interviews, Modellierung), bevor es in ein System aufgenommen werden kann. Dieser Prozess wird oft mit dem '''SECI-Modell''' (Sozialisierung, Externalisierung, Kombination, Internalisierung) beschrieben.

=== Formen der Wissensrepräsentation ===

Damit Wissen maschinell gespeichert und verarbeitet werden kann, muss es in eine Repräsentationsform gebracht werden:

{| class="wikitable"
! Repräsentationsform !! Prinzip !! Typische Systeme
|-
| Unstrukturierter Text || freier Text, Volltextsuche || Wikis, Dokumentenablagen, CMS
|-
| Strukturierte Datensätze || feste Felder/Schema || relationale Datenbanken, Tabellen
|-
| Schlüssel-Wert-Paare || einfache Zuordnung Key → Wert || Key-Value-Stores, Caches
|-
| Graphen/Netze || Entitäten + Beziehungen || Knowledge Graphs, Ontologien (RDF, OWL)
|-
| Regeln/Logik || Wenn-Dann-Regeln, Fakten || Expertensysteme, regelbasierte Systeme
|-
| Vektoren/Embeddings || semantische Nähe im Vektorraum || Vektordatenbanken, KI-/RAG-Systeme
|}

In der Praxis kombinieren viele Systeme mehrere Formen, z. B. ein Wiki (Text) mit Kategorien und Verlinkungen (graphartige Struktur) und einer Volltextsuche (Index).

=== Aufbau eines Wissenssystems (Knowledge System) ===

Ein typisches Wissenssystem durchläuft folgenden Lebenszyklus:

# '''Erfassen''' (Capture) – Wissen aus Quellen (Personen, Dokumenten, Messwerten) aufnehmen
# '''Strukturieren''' (Organize) – Kategorisieren, Verschlagworten, in ein Schema/Modell bringen
# '''Speichern''' (Store) – dauerhafte Ablage in Datei, Datenbank oder Graph
# '''Abrufen''' (Retrieve) – Suche, Abfragen, Navigation, Vernetzung mit anderem Wissen
# '''Pflegen/Aktualisieren''' (Maintain) – Widersprüche auflösen, veraltetes Wissen korrigieren oder entfernen
# '''Weitergeben''' (Share) – Zugriff für andere Personen/Systeme ermöglichen

Klassische Beispiele für Wissenssysteme sind Wikis (wie dieses hier), Knowledge Bases im Support-Kontext, Ontologien/Knowledge Graphs (z. B. Wikidata), Dokumentenmanagementsysteme sowie – im technischen Umfeld – Programme, die Wissen in Datenstrukturen abbilden und mittels der im Folgenden beschriebenen Techniken persistieren.

=== Bezug zur technischen Umsetzung ===

Die im nächsten Abschnitt beschriebenen Rust-Techniken (Structs, serde, Dateien, Key-Value-Stores, Datenbanken) sind die '''technische Speicherschicht''' für die oben genannte Stufe "Speichern". Welche Repräsentationsform (Tabelle, Key-Value, Graph, Text) gewählt wird, bestimmt dabei maßgeblich, welche Rust-Bibliothek/Datenbank sinnvoll ist:

* Strukturierte Datensätze mit Beziehungen → relationale Datenbank (rusqlite, sqlx, diesel)
* Einfache Schlüssel-Wert-Zuordnungen → Key-Value-Store (sled, redb)
* Einzelne Dokumente/Konfiguration → Datei + serde (JSON/TOML/YAML)
* Vernetztes Wissen (Graph) → Graphdatenbank-Anbindung oder eigene Graphstruktur mit Adjazenzlisten

== Wissensspeicherung in Rust ==

Dieser Abschnitt beschreibt die gängigen Methoden, um Daten ("Wissen") in Rust-Programmen dauerhaft zu speichern und wieder zu laden – von einfachen Dateien bis zu vollwertigen Datenbanken.

=== Überblick ===

In Rust gibt es keine "eingebaute" Persistenzschicht wie in manchen anderen Sprachen. Stattdessen kombiniert man:

# eine '''Datenstruktur''' im Speicher (<code>struct</code>, <code>enum</code>, <code>HashMap</code>, …)
# eine '''Serialisierungsbibliothek''', die diese Struktur in ein Speicherformat umwandelt (meist [https://serde.rs serde])
# ein '''Speicherziel''': Datei, Key-Value-Store oder relationale/eingebettete Datenbank

Die Wahl hängt davon ab, wie groß die Datenmenge ist, ob nebenläufiger Zugriff nötig ist und ob Abfragen (Queries) oder nur einfaches Laden/Speichern gebraucht werden.

=== 1. Daten im Arbeitsspeicher modellieren ===

Der erste Schritt ist immer, das "Wissen" als Rust-Typen zu modellieren:

<pre>
struct Notiz {
id: u32,
titel: String,
inhalt: String,
tags: Vec<String>,
}
</pre>

Solche Structs sind die Grundlage für alle folgenden Speichermethoden.

=== 2. Serialisierung mit serde ===

Die Standardlösung in Rust ist die Crate '''serde''' ("SERialize/DEserialize") zusammen mit einem Format wie <code>serde_json</code>, <code>serde_yaml</code>, <code>toml</code> oder <code>bincode</code>.

'''Cargo.toml:'''
<pre>
[dependencies]
serde = { version = "1", features = ["derive"] }
serde_json = "1"
</pre>

'''Struct annotieren:'''
<pre>
#[derive(serde::Serialize, serde::Deserialize)]
struct Notiz {
id: u32,
titel: String,
inhalt: String,
}
</pre>

'''Speichern (Serialisieren) in eine Datei:'''
<pre>
use std::fs;

fn speichern(notiz: &Notiz) -> std::io::Result<()> {
let json = serde_json::to_string_pretty(notiz).unwrap();
fs::write("notiz.json", json)
}
</pre>

'''Laden (Deserialisieren):'''
<pre>
fn laden() -> std::io::Result<Notiz> {
let text = fs::read_to_string("notiz.json")?;
let notiz: Notiz = serde_json::from_str(&text).unwrap();
Ok(notiz)
}
</pre>

==== Gängige Formate mit serde ====

{| class="wikitable"
! Format !! Crate !! Vorteil !! Einsatz
|-
| JSON || <code>serde_json</code> || menschenlesbar, weit verbreitet || Konfiguration, APIs, Austauschformate
|-
| TOML || <code>toml</code> || sehr gut lesbar, für Configs gedacht || Konfigurationsdateien
|-
| YAML || <code>serde_yaml</code> || kompakt, lesbar || Konfiguration
|-
| Bincode || <code>bincode</code> || binär, sehr schnell, kompakt || interne Persistenz, Caches
|-
| MessagePack || <code>rmp-serde</code> || binär, kompakt, sprachübergreifend || Netzwerk, Interop
|-
| CSV || <code>csv</code> (+ serde) || tabellarisch || Tabellen, Datenexport
|}

=== 3. Reine Datei-I/O ohne serde ===

Für sehr einfache Fälle genügt <code>std::fs</code> direkt, z. B. um Text- oder Binärdaten zu schreiben:

<pre>
use std::fs::File;
use std::io::Write;

fn schreiben() -> std::io::Result<()> {
let mut datei = File::create("wissen.txt")?;
datei.write_all(b"Wichtige Information")?;
Ok(())
}
</pre>

Für strukturierte Binärdaten kann <code>std::io::Read</code>/<code>Write</code> zusammen mit Byte-Konvertierungen (<code>to_le_bytes</code>, <code>from_le_bytes</code>) genutzt werden – das ist aber meist unnötig, da <code>bincode</code> diese Arbeit übernimmt.

=== 4. Eingebettete Key-Value-Datenbanken ===

Wenn Daten häufig aktualisiert werden und nicht die ganze Datei neu geschrieben werden soll, eignen sich eingebettete Datenbanken:

* '''sled''' – reine Rust-Implementierung, transaktional, sehr einfache API
* '''rocksdb''' (Bindings zu Facebooks RocksDB) – sehr performant, C++-Unterbau
* '''redb''' – reine Rust-Implementierung, ACID, embedded

Beispiel mit '''sled''':
<pre>
let db = sled::open("meine_datenbank")?;
db.insert(b"schluessel", b"wert")?;
let wert = db.get(b"schluessel")?;
db.flush()?;
</pre>

Kombiniert man <code>sled</code> mit <code>serde</code>/<code>bincode</code>, lassen sich ganze Structs unter einem Schlüssel speichern:
<pre>
let bytes = bincode::serialize(&notiz).unwrap();
db.insert(notiz.id.to_be_bytes(), bytes)?;
</pre>

=== 5. Relationale Datenbanken ===

Für komplexes "Wissen" mit Beziehungen, Abfragen und mehreren Nutzern bieten sich klassische SQL-Datenbanken an.

==== SQLite (lokal, dateibasiert) ====

Crate: <code>rusqlite</code>
<pre>
let conn = rusqlite::Connection::open("wissen.db")?;
conn.execute(
"CREATE TABLE IF NOT EXISTS notiz (
id INTEGER PRIMARY KEY,
titel TEXT NOT NULL,
inhalt TEXT NOT NULL
)",
[],
)?;
conn.execute(
"INSERT INTO notiz (titel, inhalt) VALUES (?1, ?2)",
rusqlite::params!["Titel", "Inhalt"],
)?;
</pre>

==== sqlx (async, mehrere Datenbanken) ====

<code>sqlx</code> unterstützt PostgreSQL, MySQL und SQLite mit asynchronem Zugriff und prüft SQL-Abfragen teils schon zur Kompilierzeit:
<pre>
let pool = sqlx::SqlitePool::connect("sqlite://wissen.db").await?;
sqlx::query("INSERT INTO notiz (titel, inhalt) VALUES (?, ?)")
.bind("Titel")
.bind("Inhalt")
.execute(&pool)
.await?;
</pre>

==== diesel (ORM) ====

<code>diesel</code> ist ein vollwertiges, synchrones ORM mit Migrationstooling und typsicheren Query-Buildern – geeignet für größere Anwendungen mit stabilem Schema.

=== 6. Auswahlkriterien ===

{| class="wikitable"
! Anforderung !! Empfehlung
|-
| Einfache Konfiguration || TOML-Datei + serde
|-
| Ein einzelnes Objekt/Dokument || JSON-Datei + serde_json
|-
| Viele kleine Schreibzugriffe, kein SQL nötig || sled / redb (Key-Value)
|-
| Abfragen, Beziehungen, mehrere Tabellen || SQLite via rusqlite/sqlx, ggf. diesel
|-
| Netzwerk-Datenbank, mehrere Clients || PostgreSQL/MySQL via sqlx oder diesel
|-
| Maximale Geschwindigkeit, keine Lesbarkeit nötig || bincode + Datei oder Key-Value-Store
|}

=== 7. Fehlerbehandlung ===

Alle I/O- und Datenbankoperationen in Rust liefern <code>Result</code> zurück. Für Anwendungen empfiehlt sich eine zentrale Fehlerbehandlung, z. B. mit den Crates '''thiserror''' (für eigene Fehlertypen) oder '''anyhow''' (für einfache Fehlerweitergabe):

<pre>
fn laden() -> anyhow::Result<Notiz> {
let text = std::fs::read_to_string("notiz.json")?;
let notiz = serde_json::from_str(&text)?;
Ok(notiz)
}
</pre>

=== 8. Zusammenfassung ===

* Datenstrukturen mit <code>struct</code>/<code>enum</code> modellieren.
* Mit '''serde''' in ein passendes Format serialisieren (JSON/TOML/YAML für Lesbarkeit, bincode für Performance).
* Für einfache Fälle reichen Dateien (<code>std::fs</code>).
* Für häufige Änderungen: eingebettete Key-Value-Stores wie '''sled''' oder '''redb'''.
* Für komplexe Abfragen und Beziehungen: relationale Datenbanken über '''rusqlite''', '''sqlx''' oder '''diesel'''.
* Fehlerbehandlung zentral mit '''anyhow'''/'''thiserror''' organisieren.

[[Kategorie:Rust]]
[[Kategorie:Datenspeicherung]]

Hauptseite

2026-08-12T14:32:47Z

Data Engine (Wissensmodell & Speicherung)

← Nächstältere Version		Version vom 12. August 2026, 14:32 Uhr
Zeile 5:		Zeile 5:
	== Hauptbausteine im Detail ==		== Hauptbausteine im Detail ==

	=== [[Data Engine]] ([[Wissensmodell]] & Speicherung) ===		=== [[Data Engine]] ([[Wissensmodell]] & [[Speicherung]]) ===
	Das Herzstück des Systems. Es definiert, wie Wissensartikel und ihre Beziehungen abgelegt werden:		Das Herzstück des Systems. Es definiert, wie Wissensartikel und ihre Beziehungen abgelegt werden:
	* Entwickler-Entscheidung: Monolithisches Datenmodell (feste Tabellen für articles, categories, tags) oder flexibles Schema (JSONB / EAV-Muster für benutzerdefinierte Wissens-Typen wie Glossareinträge, How-Tos, FAQs).		* Entwickler-Entscheidung: Monolithisches Datenmodell (feste Tabellen für articles, categories, tags) oder flexibles Schema (JSONB / EAV-Muster für benutzerdefinierte Wissens-Typen wie Glossareinträge, How-Tos, FAQs).