Forum: PC-Programmierung Datenbank - Stadtbibliothek speichern


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Der H. (derhein)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich brauche mal ein paar Tipps von Datenbankexperten.

Mal angenommen man hat einen Roman (500 Seiten mit 2500 Zeichen / Seite) 
welcher in eine Datenbank gespeichert werden soll. Über ein Webformular 
soll man die Möglichkeit haben nach Textabschnitten zu suchen. Bei einem 
Suchergebnis wird die Seitenzahl ausgegeben.

Frage:

1) Welche Datenbank würde man hierfür typischerweise benutzen? (Diese 
sollte auch eine performante Suche ermöglichen und unter Linux / Debian 
laufen). SQL, Mongo DB, Coach DB,...?

2) Mal angenommen man verwendet eine SQL DB. Wie soll der Text/Daten 
getrennt werden? Soll jeder Satz in ein eigenes Feld gespeichert werden 
oder soll jede Seite in ein eigenes Feld?

3) Mal angenommen man müßte später eine gesamte Bibliothek in der DB 
speichern, welche Möglichkeiten zur Optimierung der Suchperformance bzw 
zur effizienteren Datenspeicherung würden sich anbieten?

: Bearbeitet durch User
von Mark B. (markbrandis)


Bewertung
2 lesenswert
nicht lesenswert
Der Hein schrieb:
> Mal angenommen man hat einen Roman (500 Seiten mit 2500 Zeichen / Seite)
> welcher in eine Datenbank gespeichert werden soll. Über ein Webformular
> soll man die Möglichkeit haben nach Textabschnitten zu suchen. Bei einem
> Suchergebnis wird die Seitenzahl ausgegeben.
>
> Frage:
>
> 1) Welche Datenbank würde man hierfür typischerweise benutzen?

Womöglich gar keine?

Ich sehe bei dem hier beschriebenen Anwendungsfall erstmal so noch 
nichts, wofür man zwingend eine Datenbank bräuchte.

Einen Roman kann man zum Beispiel auch als PDF-Datei auf einem Webserver 
ablegen. Für das Durchsuchen eines PDFs gibt es entsprechende Tools/APIs 
in verschiedenen Programmiersprachen wie zum Beispiel:

C++:
Xpdf http://www.foolabs.com/xpdf/about.html

Python:
pdfminer https://pypi.python.org/pypi/pdfminer/
PdfSearch http://sourceforge.net/projects/pdfsearch/

Für weitere siehe: List of PDF software
http://en.wikipedia.org/wiki/List_of_PDF_software

Eine weitere Möglichkeit wäre ein Ablegen als HTML-Datei, bzw. in 
mehreren HTML-Dateien. Auch die kann man ganz normal auf einen Server 
kopieren. Den Inhalt der Dateien kann man mit jeder Programmiersprache 
durchsuchen, die File I/O beherrscht. Das dürften so ziemlich alle sein. 
Naja man wird es vielleicht nicht gerade in Assembler machen wollen :-)

Nicht alle Daten kommen in die Datenbank. Insbesondere bei statischen 
Daten, die sich sowieso nicht ändern, ist das eher witzlos. Der Sinn und 
Zweck von Datenbankanwendungen ist es ja gerade, Änderungen an den Daten 
vornehmen und speichern zu können.

: Bearbeitet durch User
von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Neuere Versionen von MySQL bzw. MariaDB (und sicher auch andere) 
beherrschen von Hause aus eine Volltextsuche ... gut verpackt in 
hochoptimierten Algorithmen.

Ich würde also die Originaldokumente als PDF/A oder EPUB speichern, 
versehen mit Absatzmarken und den ASCII-Text in der DB. Bei einem Match 
erfolgt der Link auf den entsprechenden Absatz nebst zusätzlichen Infos 
zu Autor, Werk, Kapitel, Seite usw.

von F. F. (foldi)


Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> Nicht alle Daten kommen in die Datenbank.

Sehe ich auch so.
Aber wenn es eine Datenbank machen soll, dann MySQL. Viele Sachen im 
Internet laufen darüber.

von Sepp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Für eine Bibliothek würde ich auf jeden Fall entsprechende Indices 
verwenden (z.B. alle Wörter im Text). Ob das MySQL derzeit für 
Textfelder anbietet weiß ich nicht.

Überlegenswert wäre auf jeden Fall auch ein Bigram Index, oder sowas in 
der Art, damit man auch trotz Tippfehler die richtigen Textpassagen 
findert. Aber da müsste man vermutlich wirklich die Experten auf dem 
Gebiet fragen.

Ich weiß das bei größeren Projekten in diesem Feld Oracle verwendet wir 
da bestimmte Funktionen bei MySQL derzeit einfach noch nicht existieren 
(hab mal von einem Kollegen gehört die bei Linguistischen Datenbanken 
z.B. stored procedures anwenden)

Bei aktuellen und sinnvollen Metadaten in der Datenbank könnte es, ja 
nach Anforderung, sogar reichen nur das PDF als Volltextversion 
abzulegen.

Lg, Sepp

von Rene S. (Firma: BfEHS) (rschube)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

dein Problem ist ein Thema für NoSQL Datenbanken wie MongoDB oder Redis.
Die einen nicht-relationalen Ansatz verfolgen.

Auszug aus Wikipedia:
"Relationale Datenbanken leiden üblicherweise unter Leistungsproblemen 
bei datenintensiven Applikationen wie Indexierung von großen 
Dokumentmengen..."

Es ist ja nicht so das du gerade das erste Bibliotheksprogramm erfindest 
:-) Damit haben sich schon Leute beschäftigt.

Grüße aus Berlin

von db23 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde das Problem etwas mehr strukturieren.

Zum einen brauchst du ja eine (effiziente) Suche. Hierfür brauchst du 
eine Komponente, die dir die Fundstellen zu einen Begriff zurückliefert. 
Je nachdem wie man suchen möchte wäre ein Index evtl. von Vorteil. 
Vielleicht reicht auch eine einfache Textsuche. Wenn du einen Index 
verwenden willst und dabei auch einen erweiterten Suchausdruck umsetzen 
willst würde ich z.B. mal Apache Lucene oder auch den Volltext-Index von 
Mysql anschauen.

Zum anderen brauchst du eine Ablage der Dokumente, damit man schnell 
darauf zugreifen kann. Von meiner Begriffsauslegung her brauchst du 
dafür eine  Datenbank (=System zur elektronischen Datenverwaltung) und 
zwar egal ob du ein Standard SQL-DBMS, NoSQL oder auch eine eigene 
Datenbank damit meinst, die die Dokumente als Dateien ablegt. Ich würde 
die Wahl aber eher von Suche abhängig machen. Schliesslich soll die DB 
deinen Anwendungszweck unterstützen und nicht als Selbstzweck benutzt 
werden.

Irgendwie musst du dir ja auch noch Gedanken machen wie die Seitenzahl 
eines Buches erhalten bleiben soll. Eine reine Textdatei ist sicher gut 
für die Suche und effizient zum speichern, aber lässt eine beliebige 
Interpretation der Ausgabe und damit der Seitenzuordnung zu. Vielleicht 
wäre hier eine Art Markup, z.B. XML von Vorteil. Dann könnte man über 
Lucene und dessen Meta-Daten einfach auf ein XML-Path verweisen und man 
bräuchte nicht mal ein ausgewachsene DBMS dafür.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mag mir jemand nebenbei erklären, wozu eine Volltextsuche(!) in Büchern 
einer Stadtbibliothek nötig sein soll?

von db23 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Mag mir jemand nebenbei erklären, wozu eine Volltextsuche(!) in Büchern
> einer Stadtbibliothek nötig sein soll?

Ich war zwar schon länger nicht mehr in einer physikalischen Bibliothek, 
aber die Google Büchersuche war mir schon oft eine Hilfe, wenn ich nach 
bestimmten Begriffen gesucht habe. So findet man dort auch Bücher die 
einen Begriff wie z.B. "neonicotinoids" nicht im Titel haben.

Ich halte das für sinnvoll.

von Rene S. (Firma: BfEHS) (rschube)


Bewertung
1 lesenswert
nicht lesenswert
Das ist für die Hausaufgaben :-)
Du musst 'Die Leiden des jungen Werthers' nicht lesen, kannst aber auf 
Knopfdruck die Seitenzahl nennen auf der ein bestimmtes Zitat steht.

von Konrad S. (maybee)


Bewertung
2 lesenswert
nicht lesenswert
zu 1
Alle "ausgewachsenen" Datenbanksysteme können das. PostgreSQL hat 
ebenfalls Funktionen für die Suche in Texten drin.

zu 2
Einen Text in Sätze aufzuteilen ist keine triviale Aufgabe. Ob es dir 
gelingt, aus einem Textdokument Informationen über die Position auf 
bestimmten Seiten zu gewinnen ... das ist sehr vom Dateityp bzw. vom 
Erstellungsystem abhängig. Glücklicherweise sind die existierenden 
Volltextsuchsysteme nicht wirklich darauf angewiesen.

zu 3
Bei SQL-Datenbanken kann man Partitionierung nutzen. Aber ...

Die bessere Technik für die Suche in Texten bietet Lucene bzw. Solr.
http://lucene.apache.org/
http://lucene.apache.org/solr/
http://de.wikipedia.org/wiki/Apache_Lucene
Durch die bei Lucene verwendeten Techniken ist das System gut skalierbar 
hinsichtlich Größe des Dokumentenbestands und Suchperformanz. Es gibt 
auch einige Firmen, die Unterstützung bei der Einführung oder spezielle 
Erweiterungen anbieten.

von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Der Hein schrieb:
> 1) Welche Datenbank würde man hierfür typischerweise benutzen?

Du willst dasselbe wie Google.

Und Nein, da ist kein SQL dahinter. Sondern ein inverted tree. Und die 
Auswertung und Suche erfolgt mehrstufig und verteilt auf mehrere 
Prozessoren.

In der Praxis würdest du Google deine Bibliothek indizieren lassen und 
nur noch das Ergebnis der weitergeleiteten Suchanfrage bearbeiten

von Ich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
+1 für Lucene

von Konrad S. (maybee)


Bewertung
1 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Mag mir jemand nebenbei erklären, wozu eine Volltextsuche(!) in Büchern
> einer Stadtbibliothek nötig sein soll?

Nach gedruckten Büchern kannst du nach heutigem Stand - inhaltsbezogen - 
fast garnicht suchen. Außer den bibliographischen Angaben steht 
bestenfalls ein Kurztext zur Verfügung, oft der (gekürzte) Klappentext, 
der mehr auf Verkaufsförderung als auf den Inhalt ausgerichtet ist. An 
ein Abstract eines technischen oder wissenschaftlichen Papers kommt das 
nicht ran.

Prinzipiell finde ich Volltextsuche (zumindest als Fallback) eine gute 
Sache. Ich suche oft genug in der Wikipedia und finde nur in den 
Ergebnissen der Volltextsuche passende Treffer. Gut, bei 
Unterhaltungsliteratur müsste ich mir auch erstmal Suchanfragen 
überlegen. (In welchen Simmel trifft ein Erich auf einen Elch, der 
anschließend von einem Ferrari angefahren wird, sowas in der Art ;-)

Man darf aber nicht davon ausgehen, dass eine Volltextsuche den 
vollständigen Text kennt. Da gibt es z.B. bei PDF-Dokumenten durchaus 
einige Lücken, noch schlimmer eingescannte, OCR-behandelte Dokumente.

von greg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
For Volltextsuche in einer Menge Büchern wird man keine normale 
SQL-Datenbank verwenden. Auch wenn die inzwischen Volltextsuche ganz gut 
können ist eine optimierte Lösung wie Solr oder Elasticsearch da besser 
geeignet. Spätestens wenn man so Sachen wie Stemming (Suche nach 
Wortstamm) und ähnliches sauber implementiert haben will.

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
Konrad S. schrieb:
> Ich suche oft genug in der Wikipedia und finde nur in den Ergebnissen
> der Volltextsuche passende Treffer.

Ich benutze Wikipedia nur über google, d.h. ich suche nach "Suchbegriff 
wiki". Liefert bessere Ergebnisse :-)
Für mc.net gilt ähnliches.

von Konrad S. (maybee)


Bewertung
0 lesenswert
nicht lesenswert
le x. schrieb:
> Ich benutze Wikipedia nur über google, d.h. ich suche nach "Suchbegriff
> wiki".

Ich meide die großen Datensammler. Leider geht es nicht ganz ohne sie. 
:-(

> Liefert bessere Ergebnisse :-)

Ja. Braucht schon ein "gewisses" Engagement um bessere Treffer als 
Google zu liefern.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.