Bitte um Feedback zu Buchverwaltungsideen

SteffenN · 29.07.2009, 19:34

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

Freeaak · 29.07.2009, 19:46

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

Chriz · 29.07.2009, 19:55

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:

Code:

author
id | name

book
id | title

publisher 
id | title

term
id | term | soundex_value

book_has_publisher
book_id | publisher_id

book_has_author
book_id | author_id

book_has_term
book_id | term_id

Eine Soundex-Anfrage könnte dann so lauten:

Code:

SELECT title
FROM term AS t
INNER JOIN book_has_term AS bt
bt.term_id = t.id
INNER JOIN book AS b
ON bt.book_id = b.id
WHERE SOUNDEX('Spass') SOUNDS LIKE t.soundex_value
GROUP BY b.id

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

nikosch · 30.07.2009, 00:21

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.

SteffenN · 01.08.2009, 21:58

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 · 01.08.2009, 22:30

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.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Projekt anbieten und suchen	toptom	Beitragsarchiv	4	30.01.2009 15:30
Feedback zu Einsteiger-Tutorial APF	dr.e.	PHP-Fortgeschrittene	0	10.08.2008 22:42
Mail Feedback mit Include eingebunden	mac-x	PHP Tipps 2008	6	28.07.2008 15:03
Feedback von URL-Aufruf in Variable speichern		PHP Tipps 2007	3	17.12.2005 18:50
Feedback	BEGINNER-L	Off-Topic Diskussionen	12	11.11.2005 18:20
[Erledigt] Wir sind neu hier! Bitte um Feedback!		Off-Topic Diskussionen	5	23.03.2005 17:30

29.07.2009, 19:34
SteffenN Neuer Benutzer Registriert seit: 29.07.2009 Beiträge: 6 PHP-Kenntnisse: Anfänger	Bitte um Feedback zu Buchverwaltungsideen 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 PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

29.07.2009, 19:46
Freeaak Erfahrener Benutzer Registriert seit: 05.04.2005 Beiträge: 1.333	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)

29.07.2009, 19:55
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.267	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: Code: author id \| name book id \| title publisher id \| title term id \| term \| soundex_value book_has_publisher book_id \| publisher_id book_has_author book_id \| author_id book_has_term book_id \| term_id Eine Soundex-Anfrage könnte dann so lauten: Code: SELECT title FROM term AS t INNER JOIN book_has_term AS bt bt.term_id = t.id INNER JOIN book AS b ON bt.book_id = b.id WHERE SOUNDEX('Spass') SOUNDS LIKE t.soundex_value GROUP BY b.id Das Ergebnis, eine Liste von Büchern, denen Schlagwörter zugeordnet sind, die wie "Spass" klingen. __________________ "Nuschel ich?" - "Was?" Geändert von Chriz (29.07.2009 um 20:02 Uhr).

30.07.2009, 00:21
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	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. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

01.08.2009, 21:58
SteffenN Neuer Benutzer Registriert seit: 29.07.2009 Beiträge: 6 PHP-Kenntnisse: Anfänger	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

01.08.2009, 22:30
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	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. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --