SteffenN

Hallo zusammen,

wir möchten eine Buchverwaltung, die mehrere hundert Titel umfasst und bislang in einer Tabellenkalkulation vorliegt, auf PHP / MySQL umstellen.

Die Bücher sind verschlagwortet (Schema: Buch1 ~> Begriff1, Begriff2 / Buch2 ~> Begriff2, Begriff3, Begriff4 / Buch3 ~> Begriff5 etc., d.h. aktuell sind die Schlagworte in einem String durch Kommata voneinander getrennt).

In unserer Suchmaske wird es für die Recherche im Bestand u.a. ein Feld 'Schlagworte' geben, hier kann man als Freitext verschiedene Begriffe eingeben.

Uns schwebt nun vor...

a) Schreibvarianten abzufangen (Beispiel: Eingabe 'Spass-Buch' soll zum Treffer 'Spaßbuch' führen)

b) Synonyme zu erkennen (Beispiel: Eingabe 'Witzbuch' soll zum Treffer 'Spaßbuch' führen)

Generell haben wir uns nun diesen Ansatz überlegt:

c) Den Suchstring entgegennehmen, gemäß a) und b) bearbeiten und für den Fall, dass nach mehreren Schlagworten gesucht werden soll, entsprechend splitten.

d) Die Query an die DB nach folgendem Grobschema generieren:
select allerhand_variablen from dbname.tabelle where eingabesuchwort1 in schlagwortstring and eingabesuchwort2 in schlagwortstring and ...

Das würde vermutlich funktionieren, aber sehr wahrscheinlich gibt es bessere Alternativen, eventuell auch mit eigenen Tabellen zu Schlagworten.

Da ich bislang wenig Erfahrung mit PHP und MySQL habe, wäre es schön, wenn jemand Verbesserungsvorschläge oder Kommentare zu unseren Plänen hätte.

Weil es letztlich nur um eine Recordzahl im relativ niedrigen vierstelligen Bereich gehen wird, würde ich Performancefragen bei der Optimierung unseres Ansatzes als nicht entscheidend einschätzen, wesentlicher wären Funktionalität und Sicherheit von Applikation und DB.

Schönen Dank schon mal für Eure Hilfe
und viele Grüße,
Steffen

Mister Ad

Freeaak

man könnte die tabelle normalisieren, allerdings würde das fast nur die performance verbessern.

__________________
"Wenn du nicht weißt, was du tust: Machs mit Eleganz!"

(Murphy's Gesetze)

Chriz

Hallo,
ob es sich um wenige oder viel Datensätze handelt ist für eine Datenbankoptimierung erstmal nicht entscheidend. Schliesslich könnte es ja sein, dass ihr die Suche einmal erweitern wollt, da sollte das Datenbankschema dann schon solide sein.

Zum Thema Normalisierung kannst du dich mal hier einlesen, falls es für dich in Frage kommt:
Normalisierung (Datenbank) – Wikipedia

Schreibvarianten abfangen kannst du mit Levenshtein oder Soundex. Die Levenshtein-Distanz:
Levenshtein-Distanz – Wikipedia
errechnet, wieviele Buchstaben-Tausch- oder -Verschiebeoperationen nötig sind, um von Wort A zu Wort B zu gelangen. Von Spass-Buch zu Spaßbuch wären es 3 (oder 4 für Groß-Kleinschreibung, beachtest du aber nicht), also relativ wenig gemessen an der Länge des Wortes. Natürlich kannst du auch automatisch in die Suche eine "ss" -> "ß", "ä" => "ae", .. Konvertierung vornehmen. Die Volltextsuche der Suchmaschine scheidet aus, da es ja Schlagwörter und keine langen Texte sind. Soundex() berechnet für jedes Wort einen Klangwert, so daß Meyer und Meier beispielsweise einen gleichen Soundex-Wert bekommen. Levenshtein ist allerdings noch nicht in MySQL implementiert soweit ich weiß. Daher könnte vielleicht das hier für dich interessant sein:
codejanitor Levenshtein Distance as a MySQL Stored Function

Die Datenbank normalisiert könnte nun so aussehen:

Eine Soundex-Anfrage könnte dann so lauten:

Das Ergebnis, eine Liste von Büchern, denen Schlagwörter zugeordnet sind, die wie "Spass" klingen.

__________________
„Was interessiert mich mein Geschwätz von gestern.“ - Konrad Adenauer

nikosch

Meine 2 cents:

Verschlagwortungs- oder Taggingprinzipien sind i.A. nicht flexibel angelegt. Synonyme o.ä. werden hier eigentlich nicht angewendet.
Ihr könntet aber eine Art künstliche Inhaltsbeschreibung aus Schlagworten schaffen, die man mit einem üblichen Suchmechanismus auswertet. Hier hätte man keine normalisierte Form, sondern eine durch Leerzeichen getrennte Wortmenge, die man einfach durch LIKE auswerten kann.

Deshalb würde ich auch von SOUNDEX und Co abraten und statt dessen Verfahren wie Stemmer verwenden und die Wortliste beim Eintragen des Datensatzes erstellen. Suchworte würden dann zuerst gestemmt, dann durch eine Synonymersetzung geschickt (ebenfalls Stemming) und anschliessend an LIKE verfüttert.

__________________
--
„Eins ist Fakt: Gescannt wird nackt!“

Privatsphäre 2.0 - Nacktscanner mit Eyetracking.
Unser Flugzeug darf kein geschlechtsfreier Raum sein.
--

SteffenN

Hallo zusammen,

vielen Dank für die schnellen Antworten und sorry für meine späte Antwort - am Do hatte ich keine Zeit, und gestern war ich bei Babelsberg vs. Bayer Leverkusen

Ich weiß, 'eigentlich' setzt man eine DB normalisiert auf. Aus verschiedenen Gründen ist es bei uns jedoch so, dass wir die Erfassung der Bücher in einer Tabellenkalkulation machen (hat durchaus einige Vorzüge), diese Datenhaltung dann nach CSV ex- und in dieser Form nach MySQL importieren.
An diese DB soll man dann mit Hilfe der in PHP erstellten Internet-Schnittstelle Anfragen generieren können.
Damit haben wir eine große flache Tabelle mit vielen Variablen, die man gewiß besser strukturieren könnte (sollte?) - wir erkaufen eine gewisse Bequemlichkeit der Datenerfassung halt mit einer suboptimalen Datenstruktur. Für den Betrieb auf der DB und die Verwaltung der Vorgänge wird es aber weitere Tabellen geben.
Soweit ich weiß, ist einer der Gründe für die Normalisierung, dass man damit Dateninkonsistenzen vermeiden oder wenigstens begrenzen kann.
Nun ja, einige Standardchecks laufen bei uns schon auf der Ebene der Tabellenkalkulation ab, und weitere Checks werde ich in PHP programmieren, so dass damit zumindest schlimme Hundchen beseitigt werden.

Wir haben die Bücher intern verschlagwortet und dazu eine Art kontrolliertes und hierarchisch gegliedertes Vokabular erstellt.
Wie schon im ersten Posting beschrieben, liegen diese Schlagworte in einem langen String vor und sind ggw. per Komma getrennt.

Nikoschs Vorschläge kommen unseren Plänen auch recht nahe. Eine Synonymliste scheint mir aber unumgänglich: Was wäre denn, wenn wir schreibfaul sind und das Schlagwort 'WM' verwenden, eine Suchende aber frustriert ist, weil sie mit 'Weltmeisterschaft' keine Treffer hätte?
Insofern müssen Umschreibungen schon letztlich auf unseren Kernbegriff führen.
Wie ich das DB-technisch umsetze, darüber muss ich noch nachdenken.

Schönen Sonntag,
Steffen

nikosch

Je nachdem, ob auch ein Export als CSV notwenig ist, koentest Du auch darüber nachdenken, die Daten doch zu normalisieren und eine zusätzliche Importtabelle zu benutzen, die dann softwareseitig in die Normalform überführt wird. Eine entsprechende Überführung müsste man nach einem Import antriggern (weiss nicht, moeglicherweise iost das auch via DB Trigger moeglich) oder per CRON in einem zeitlichen Intervall (dann fehlen in der normalisierten Menge zeitweise einige Elemente).
Andere Moeglichlichkeit wäre, das CSV über PHP zu importieren und dort neue INSERT-Statements zu erzeugen.

Wie gesagt, Stemming koennte man mit einer Liste ebenfalls gestemmter Synonymwoerter ergänzen. WM wäre allerdings schon ein Extremfall, weil das Wort so kurz ist.
Allerdings ist es bei einem festen Vokabular (ein sog. Thesaurus) auch nicht ganz so dringlich mit der Wortstammreduzierung, da bei einem gut gepflegten Index kaum Doppelungen vorkommen sollten - doch eher Taggingprinzip.

Nachteilig ist das Verhältnis zur Suche.
Tags bietet man üblicherweise als Liste/Wolke an, so dass die Suche schon konkret ist. Eine Synonymsuche funktioniert nur so gut, wie der Wort- und Synonymindex ist. Deshalb mein Vorschlag des Stemmings: Hier werden sowohl von der Schlagwortmenge, als auch von den Suchwoertern einzig die Wortstämme gebildet und verglichen.

__________________
--
„Eins ist Fakt: Gescannt wird nackt!“

Privatsphäre 2.0 - Nacktscanner mit Eyetracking.
Unser Flugzeug darf kein geschlechtsfreier Raum sein.
--