SQLite Volltext-Suche

[hansklok]

Hallo,

ich würde gern eine Datenbank-Anwendung erstellen, die Kontakte speichert. Nun möchte ich, damit es nicht zu Doppeleinträgen bei den Namen kommt jeweils eine Vornamen- und eine Nachnamen-Tabelle erstellen.

Nun soll der Benutzer über eine Eingabemaske mit 2 Editfeldern den Vor- und Zunamen eingeben können und mit einem Klick auf den Hinzufügen-Button, soll der Eintrag in die Tabelle Einträge übernommen werden. Davor muss geprüft werden, ob der Vor- und/oder Nachname schon in der Datenbank vorhanden ist, um ggf. damit zu verlinken bzw. neu hinzuzufügen und dann zu verbinden.

Nun gibt es den

Code:

LIKE

-Befehl und den

Code:

MATCH

-Befehl (FTS3/4) in SQLite. Nur ist das ja eine Art Volltext-Suche und würde Beispielsweise auch Ergebnisse wie "Meier-Schulze" liefern, wenn man einen "Meier" hinzufügen will. Es soll aber immer nur jeder Name einmal vorhanden sein. Wie lässt sich das gut über SQLite lösen?

Vornamen
- ID
- Vorname

Nachnamen
- ID
-Nachname

Einträge
- ID
- Vorname-ID
- Nachname-ID

[galex9]

Wieso nicht einfach:

Code:

select id from vorname_tabele where lower(vorname) = :vorname_aus_dem_code_in_klein

Dabei muss man beachten was in Dokumetation zu sqlite steht:

Zitat:

The lower(X) function returns a copy of string X with all ASCII characters converted to lower case. The default built-in lower() function works for ASCII characters only. To do case conversions on non-ASCII characters, load the ICU extension.

[Dejan Vu]

Zitat:

Zitat von hansklok (Beitrag 1318284)

Nur ist das ja eine Art Volltext-Suche

Nee. Das hier ist Volltextsuche Was Du meinst, ist eher pattern matching oder unscharfe Suche in *einem* Feld.

[jobo]

Zitat:

Zitat von galex9 (Beitrag 1318286)

Wieso nicht einfach
.. where lower(vorname) = :vorname_aus_dem_code_in_klein

Weil es nicht das ist, was der TE möchte und weil es in der Form keine Indexnutzung erlaubt, also langsamer ist.

@TE
Deine Frage zu Doppelnamen und Like habe ich nicht richtig verstanden:
Ein Like liefert kein eindeutiges Ergebnis, das willst Du ja scheinbar. Bedeutet es müsste ein interaktiver Prozess folgen, wo der Benutzer einen der Like Treffer auswählt.
Genauso würde es für den Doppelname erfolgen. Ob und welchen Treffer der Anwender wählt, kannst/willst Du nicht beeinflussen.
Erst wenn kein Treffer kommt oder kein passender, kommt die Frage der Eindeutigkeit ins Spiel. Den eindeutigen, noch nicht vorhandenen Namen trägst Du in Deine Liste ein.

[Perlsau]

Irgendwie scheint mir das Konzept des TE nicht sonderlich gut durchdacht, denn es gibt durchaus Leute, bei denen Vor- und Nachname identisch sind, auch wenn die Wahrscheinlichkeit relativ gering ist, ausgerechnet zwei solche Kontakte anlegen zu müssen. Begegnet einem dieser Fall dennoch, was eben nicht auszuschließen ist, kannst man sein Konzept in die Tonne treten. Ich würde daher empfehlen, zumindest noch eine Telefonnummer, Postleitzahl und/oder Straße mit aufzunehmen und bei der Eingabe zu prüfen.

Die beiden Sub-Tabellen für Vor- und Nachname sind nicht wirklich notwendig, um doppelte Einträge zu vermeiden. Zielführend wäre es dagegen, einen eindeutigen Index anzulegen, der Vorname, Nachname und z.B. Tel-Nr. beinhaltet. Damit reagiert bereits die Datenbank auf den Versuch, doppelte Datensätze anzulegen, mit einer entsprechenden Fehlermeldung. Natürlich bieten diese Subtabellen für Vor- und Nachnamen andere Vorteile wie z.B. die Ausklammerung des Vornamens bei der Anrede (Sehr geehrter Herr Müller statt Sehr geehrter Herr Florian Müller), wenn man anhand der Kontaktdaten Serienbriefe erstellen will, oder die Zuweisung eines Geschlechts für die Auswahl der korrekten Anrede. Die Eingabe doppelter Datensätze können sie aber nicht verhindern, denn das liegt, wenn die Datenbank doppelte Einträge gestattet, in der Verantwortung des Anwenders. Auch die Eingabe "falscher doppelter" Datensätze (z.B. Müllre statt Müller oder Shcneider oder Shneider statt Schneider oder Schmitt statt Schmidt oder Schmid oder Schmied usw.) kann nicht wirklich verhindert werden, auch nicht mit diesen Subtabellen, denn schließlich kann der Anwender jeden Vor- und Nachnamen in die Subtabellen eingeben. Mit anderen Worten: Kein Programm der Welt kann dem Anwender die Entscheidung abnehmen, ob diese Person wirklich existiert oder ob es sich um eine bereits eingetragene Person handelt, die nur falsch geschrieben wurde, wenn der Anwender sich vertippt. Was hier helfen könnte, ist der Einsatz eines Views, das die kompletten Daten enthält und der Verwendung eines DbLookUpComboBox, die nach jedem eingetippten Zeichen die bereits eingetragenen Vor- und Nachnamen-Kombinationen anzeigt. Aber auch hier muß sich der Anwender einer zuvor festgelegten Konvention beugen: Wird im View nach dem Schema Vorname Nachname gespeichert, oder Nachname, Vorname?

Fakturierung erfordert eben ein gewisses Maß an Mindestaufmerksamkeit. Ich habe noch nie irgend ein längeres Dokument verfaßt, bei ein Kollege (während meiner Zeit als Schriftsetzer) nach der Word-Fehlerkorrektur beim anschließenden Durchlesen nicht doch noch einen Fehler gefunden hat, und sei er noch so belanglos. Es kommt aus meiner Sicht immer auf das Maß der gerade vorherrschenden Aufmerksamkeit und Konzentration an, wenn man Daten erfaßt. Lenkt mich irgend was ab, bin ich vielleicht erkältet oder emotional unausgeglichen, sind Fehler quasi vorprogrammiert.