![]() |
Datenbank: SQLite • Version: 3.8 • Zugriff über: -
SQLite Volltext-Suche
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:
-Befehl und den
LIKE
Code:
-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?
MATCH
Vornamen - ID - Vorname Nachnamen - ID -Nachname Einträge - ID - Vorname-ID - Nachname-ID |
AW: SQLite Volltext-Suche
Wieso nicht einfach:
Code:
Dabei muss man beachten was in Dokumetation zu sqlite steht:
select id from vorname_tabele where lower(vorname) = :vorname_aus_dem_code_in_klein
Zitat:
|
AW: SQLite Volltext-Suche
Zitat:
![]() |
AW: SQLite Volltext-Suche
Zitat:
@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. |
AW: SQLite Volltext-Suche
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz