Office: Vom ("globalen") Suchen und Finden...

Hallo Zusammen,

nachdem ich nun viel Zeit und Mühe in die Konzeption und Realisierung meiner Access-Datenbank investiert habe und mich dabei intensiv damit beschäftigt habe, Daten zu strukturieren, sie zueinander in Beziehung zu setzen, in Abfragen zu verknüpfen und in Formularen bearbeitbar zu machen, stelle ich mir eine wohl sehr grundsätzliche Frage: Wie löse ich eigentlich den eigentlichen Sinn und Zweck einer Datenbank - das FINDEN von Informationen. Bisher lande ich in diesem Zusammenhang immer bei Abfragen. Und klar - ich kann auch Tabellen direkt durchsuchen - die Funktion ist quasi allgegenwärtig. Aber davon rede ich nicht. Ich stelle mir ein Formular vor, das beim Öffnen der DB mit genau drei Elementen aufwartet: Dem Textfeld "Suchbegriff eingeben:", einem großen Eingabefeld und einem Button "Suche starten".

Und was soll dann passieren? Na... es soll gesucht werden. Alles und überall. Und dann sollen die Suchergebnisse angezeigt werden. Ich rede also von Benutzerfreundlichkeit und intuitivem Herangehen. Ich möchte von einem Punkt aus alle vorhandenen Informationen finden können, unabhängig davon, ob mein "Anliegen" zuvor in Form einer Abfrage berücksichtigt wurde oder eben nicht. Anhand des Ergebnisses möchte ich dann entscheiden können, welche gefundene Information für mich gerade relevant ist. Dabei möchte ich natürlich auch mit Platzhaltern suchen können - ich weiß ja vielleicht nicht so ganz genau, was ich suche.

Ich glaube mein Anliegen ist klar. Und jetzt meine konkrete Frage: Wie setze ich eine solche, ich nenne es mal "globale" Suche um? Es kann ja nicht Sinn und Zweck sein, den gesamten bereits vorhandenen und in Beziehungen gesetzten Inhalt noch einmal in einer Abfrage "nachzubauen", um diese dann durchsuchen zu können. Oder doch?

Ich würde mich über Hinweise freuen, wie ich mich diesem Thema am besten und effektivsten nähern kann.

Vielen Dank im Voraus und einen schönen Abend allerseits.

L.

:)

 

Erster Hinweis
zweiter Hinweis
dritter Hinweis
vierter und letzter Hinweis
All das und mehr bekommt man, wenn man im Netz als Suchbegriff "ACCESS Datenbank Suche" eingibt.

 

Hallo,

du hast doch eine DB zu einem - was auch immer - Thema erstellt.
Hast Daten eingegeben.

Nun kannst du über Abfragen deine Informationen finden.
Allerdings: nur die Informationen, die in der DB vorhanden sind.

Welcher Kunde hat innerhalb des letzten Jahres nicht bestellt?
Welcher Vertreter hat im April 2019 den höchsten/niedrigsten/Durchschnittsumsatz gemacht. Usw. usf.

Wenn es das nicht sein sollte, müsstest du nochmal die Tastatur anheizen!

Was ist der Grund deiner Sinnkrise?

Gruß
Rainer

 

Moin,

eine Datenbank zu erstellen kostet einen Haufen Geld, das muss auch wieder reinkommen, indem der Nutzer in seiner Arbeit unterstützt wird. Zur Unterstützung gehört mE nicht die Antwort auf die Frage, was in der Datenbank alles versteckt sein könnte.

Ich halte diese Art der Suche für sinnlos, nicht nur weil sie Geld kostet, sondern weil sie nichts bringt. Vor die Suche gehört nämlich die Frage, was ich wissen möchte (logisch: alles), und das ist halt was anderes als die Begeisterung, die in mir aufkam, als ich im zarten Alter von 10 Jahren ein Lexikon geschenkt bekam und es auf einen Sitz ausgelesen habe (garnichwah).

 

Im gleichen Zuge solltest Du von einer Performancekatastrophe reden, es sei denn, die Datenbank ist und bleibt ein Bänkchen mit bescheidenen Zahlen an Tabellen und enthaltenen Datensätzen.

Wenn man überall sucht, das ja dann konsequent jedes Mal: Warum würde man Bananen im Geburtsdatum und den Doktortitel bei den Artikeln suchen?
Wenn Du beim Apotheker Hustentropfen anforderst, rennt er da durch die ganze Großstadt mit seiner Suche? Nein, er geht zielgerichtet zu einem bestimmten Schrank, öffnet gezielt eine Schublade und greift direkt in ein Fach.
Für ihn wie auch für einen richtigen Datenbankbetreiber steht nicht das Suchen als Ziel, sondern ein unmittelbares und schnelles Finden und Bereitstellen. Daher schafft man nicht nur Strukturen, sondern man nutzt sie auch, und man kennt sie. Anders käme man bei datenbankgemäßen Datenmengen nicht in akzeptable Gänge.

Das kannst Du ja erstellen. Du solltest nur KI-mäßig aus der Sucheingabe ermitteln können, wo genau das präzise zu suchen wäre, und dies userfreundlich programmiert bereitstellen - eine ordentliche Aufgabe, wenn das Backend dann mal 20 Tabellen plus enthält.

Die Beurteilung der Relevanz des Ergebnisses ist dann ein weiteres Thema. Wenn Frau Mai im Buchtitel "Maiensonne" gefunden wird, stellt sich die Frage, wie hilfreich das ist.

Ich halte, wie man bemerken kann, nicht sehr viel von dieser globalen oder Volltextsuche.

Man könnte aber auch das Backend frei online stellen und dann die bereits vorhandenen und sehr einfachen und vertrauten Formulare von Metager, Google, Bing, Yahoo usw. nutzen. Da bekommt das GLOBAL die Bedeutung, die im Worte steckt.

 

Servus Lightfood,
irgendwie hab ich da ein Déjà-vu bei diesem Thema.
Allerdings weiss ich nimmer den Link des Threads, in dem es schon mal eine Diskussion darüber gab.
Jedenfalls ist Dein Wunsch erfüllbar, wenn es auch eine lahme Ente sein wird,
wenn man ohne sinnvolle Vorfilterung einfach auch eindeutig unsinnig eingebundene Tabellen einbezieht.
Aber da gibts ja durchaus relativ einfache Möglichkeiten, nur relevante Tabellen per VBA einzubinden. Ein Ansatz wäre:
Code:

Willst Du eine Beispiel DB, dann schick eine PN mit Deiner Email-Adresse,
denn selbst eine rar meines Beispiels übersteigt die erlaubte Dateigröße
für einen Upload im Forum.

 

Also - mein Anliegen oder meine Fragestellung etwas konkreter an einem Beispiel:

Ich habe verschiedenste Tabellen, z. B. Vereine mit dazugehörigen Informationen, Ehrenamtliche mit dazugehörigen Informationen, Geschäftsstellen mit dazugehörigen Informationen, Mitarbeiter mit.... usw.

Jetzt möchte ich eine Suche an den "Start" der DB stellen. Dort möchte mein User nun nach einer Mitgliedsnummer suchen (zu finden in Tabelle A). Der nächste User gibt eine Vereinskennung ein (steht in Tabelle B), um nach einem bestimmten Verein zu suchen, der Dritte gibt eine Schlüsselnummer ein, um zu erfahren, wem der Schlüssel ausgehändigt wurde (ihr ahnt es... steht in Tabelle C) usw. usf.

Oder man sucht den Namen Müller - vielleicht sogar Müller*, weil man sich nicht mehr sicher ist, ob der Typ am Telefon nun "Müller" oder "Müllert" gesagt hat - was ein Mitarbeiter, ein Ehrenamtlicher oder oder oder sein kann.

Nach meinem durchaus noch beschränkten Verständnis, müsste ich all diese Informationen aus den Tabellen in einer Abfrage sammeln, um dieses Tabellenmonster, das ja quasi all das wäre, was ich aus guten Gründen in der Datenstruktur der DB vermieden habe, an einer Stelle abfragen zu können.

Ich möchte den Nutzern einfach nur den Komfort bieten, was auch immer sie suchen in dieses eine Suchfeld eingeben zu können und dann die Suche zu starten. Wenn sie dabei dann eine Ziffernfolge eingeben, die sowohl einer Schlüsselnummer als auch einer Mitgliedsnummer entspricht, werden sie es im Suchergebnis schon merken und das für sie relevante Ergebnis auswählen. Was ich gerne vermeiden möchte, ist der Zwang zur Auswahl von (Such-)Bereichen vor der Suche - beispielsweise via Kategorieauswahl mittels eines DropDown-Feldes neben dem Suchfeld.

Zur Vollständigkeit - ich habe keine drei Datensätze, aber auch keine Millionen. Es sind - zur Zeit - knapp ein Dutzend Tabellen - die größten haben um die zweieinhalbtausend Datensätze.

Und um es abzurunden - wobei es eigentlich immer noch Standard ist - will man, wenn man via Eingabe der Ziffernfolge beispielsweise den gesuchten Ehrenamtlichen gefunden hat, diesen Eintrag auch noch anklicken, um den Datensatz zu bearbeiten, oder Details anzuzeigen.

Zusammengefasst: Was wäre der richtige/ ein geeigneter Weg, tabellenübergreifend zu suchen, ohne eine via Abfrage generierte Monstertabelle im Hintergrund? Gibt es überhaupt eine Chance, die Suchergebnisse anklickbar zu machen, ohne SQL-Programmierer zu sein. Gibt es auch für Anfänger verständliche und damit anwendbare "Templates" oder Code-Beispiele, best practices o. ä.?

Vielen herzlichen Dank im Voraus für Wertungs- und Abo-freie Hinweise, die zudem nicht erklären, wie man Google benutzt.

L.

 

Ergänzung: Natürlich wäre eine Auswahl von Feldern vorzunehmen, um die Einbindung "sinnloser" Inhalte in die Suche zu vermeiden. Das verstehe ich. Trotzdem blieben halt noch eine ganze Menge Felder in verschiedenen Tabellen übrig, die eingebunden werden sollten... und das Monster produzieren würden, würde man sie via Abfrage zusammensammeln.

@ Ohrkester: Danke! PN folgt... *Smilie

 

Servus,
ich hatte Dein Anliegen schon verstanden und meine Lösung generiert auch keine Tabellen, sondern gefilterte Ergebnisse, welche in einem Listenfeld temporär angezeigt werden.
Du musst eigentlich nur ein Foemular bauen und darin die Steuerelemente
einbauen und entsprechend deren Namen den Code anpassen oder
die Steuerelemente so bezeichnen, wie sie im Code lauten.
Ansonsten den Rest per PN, wenn Du ein Beispiel haben willst.

 

Absolut klar. Das wäre in der Tat wenig hilfreich. Aber die oben von mir beschriebenen Beispiele würde ich schon als sinnvolle Anwendungsfälle bezeichnen.

 

Hallo,
ich habe in einer dienstlichen Datenbank ein Suchformular erstellt, bei dem ich mit einem Eingabefeld in mehreren unterschiedlichen Datenfeldern suchen kann, die projekttypische "Identifier" (entschuldige den Anglizismus) enthalten. Das habe ich so gelöst, dass beim Suche-Start per Reguläre Ausdrücke ermittelt wird, um welchen Identifier es sich handelt, dann kann die Suche gezielt in dieses Feld gelenkt werden. Eine Einschränkung ist, dass man immer vollständige Identifier eingeben muss, weil die regulären Ausdrücke sonst nicht greifen. Beispiel: Ein Identifier hat immer die Struktur ABC-DE12345. Mache ich eine Eingabe, die eine Ziffer weglässt, meldet mir die Suchfunktion ein falsches Format.
Ein weiterer Tip ist "Find as you type", zu finden in Allen Browns Seite. Bei diesem Tool musst Du aber auswählen, in welchem Datenfeld Du suchen möchtest.
Microsoft Access tips: Find records as you type
Gruß Thomas

 

Du könntest vor die eigentliche Suche eine Vorauswahl (Kombi oder Listbox) setzen in der auf gespeicherte Abfragen (Oberbegriffe) zugegriffen wird. Z.B. Trainer, Mitglieder, Namen, etc.

Mit der Auswahl wird dann die eigentliche Suche in entsprechenden Formularen durchgeführt.

Wären deine jetzigen Überlegungen am Anfang gestanden, hättest du ein anderes Datenbanksystem gewählt.

Gruß
Rainer

 

Meine obigen Ausführungen sollten vor allem darauf hinweisen, dass in einer strukturierten normalisierten Datenbank gleiche Informationen im gleichen Feld einer Tabelle zu finden wären. Diesen Umstand würde man direkt ausnutzen.
Ein Suchen von etwas über alles ist dann erst einmal nur Ausdruck von Unstrukturiertheit, Unklarheit, Orientierungslosigkeit - was dann über erhöhten Aufwand ausgeglichen werden muss.

Generell hat man da zwei Wege: Erstens man wirft alle Daten in einen Haufen wie die von Dir angedachte Monsterabfrage. Dort hat man aber die grundsätzlichen Probleme, dass Jet nur maximal 255 Felder beherrschen kann. Bei einem festimplementierten Filter über alles bekommt man ggf. Probleme mit den Access-Spezifikationen. Über alles Filtern auf Verdacht ist dann wie gesagt Aufwand.

Der andere Weg wäre, sich wie im Code in #6 gezeigt einzeln durch die Tabellen und Felder zu schleifen. Dieser Code liefert aber bis hierhin nur eine Auflistung der Felder mit zugehöriger Tabelle, wo der Suchbegriff vorkommt. Das Abfrageergebnis an sich wie gewünscht wird es noch nicht sein. Da müsste also noch einiges folgen => Datensatzanzeige.

Unmittelbar darauf hat man ein Darstellungsproblem zu lösen. 255 Felder und Überblick? Das wäre ein Stück weg von userfreundlich.
Wert in Einzeltabelle gefunden? Reicht der Inhalt des Tabellendatensatzes für einen Überblick? Oder müsste man Tabellen hinzuverknüpfen? Welche?
Bei mehreren Funden in verschiedenen Tabellen: Wie stellt man die Inhalte der dann sehr unterschiedlichen Datensätze in einer Liste dar wegen des Überblicks?

Du müsstest also definieren, was unter dem Fund zu verstehen und wie der Fund darzustellen wäre, dann auch bei möglicher Mehrzahl.

Ich hätte bei all dem Bauchschmerzen und würde in eine solche Richtung nicht groß investieren. Beachten sollte man auch, dass funktionierende Datenbanken meist erweitert werden, neue Funktionalitäten erweitern Tabellenstrukturen, eine Skalierbarkeit müsste gegeben sein.

Das sind drei unterschiedliche Informationen. Mit eigenem Nachdenken und Kenntnis der DB sowie aus einem Dialog mit Nutzern könnte man im Vorhinein planen, wonach wirklich gesucht würde. Das sind dann vielleicht zwanzig, dreißig unterschiedliche Punkte, wenn es hoch kommt.
Solche würde ich als Auswahl (Listen-, Kombinationsfeld) anbieten. In Abhängigkeit davon würden gezielte vorbereitete Abfragen ausgeführt. Die Darstellung des Ergebnisses kann dann in einem Listenfeld erfolgen, wo man sich dynamisch nur um die Spaltenanzahl kümmern muss. Über eigene Abfragen kann ich auch die Feldreihenfolge und somit ein einfaches Zusammenfügen von mehreren Abfrageinhalten organisieren. Die Begrenzung auf relevante informative Felder versteht sich da von selbst.

Ich bin recht überzeugt davon, dass die Erstellung von 30 ... 40 Einzelabfragen, die auch (teilweise) ergebnistechnisch miteinander kombiniert werden könnten, sehr viel schneller und einfacher und übersichtlicher ist als die Erstellung des einen Abfragevorgangs, der alles können soll.
Hier sehe ich auch eine einfache Erweiterbarkeit, falls da Anforderungen hinzukommen.

Im genannten Listenfeld kann man Ergebnisse = Datensätze anklicken. Hat man im Datensatz eine verwertbare ID hinterlegt, könnte man damit auch gezielte Folgeaktionen auslösen.

Ich will aber nicht anderen den Spaß an der Entwicklung ihrer Lösungen nehmen.

 

Servus,

Das sehe ich nicht als immer so gegeben. Es kann auch Faulheit und Ignoranz
eines Vorgesetzten sein, der von heut auf morgen eine solche Möglichkeit
haben will.

Das dürfte nicht so schwierig sein.
Code:

Nur so mal als Schnellschuss und das muss dem Vorgesetzten vorerst reichen.

 

Bei einem SELECT * FROM NurEineTabelle bekomme ich resultierend die Information, ob es den Schlüssel in der Schlüsseltabelle gibt. Das war es. Ob, wann und an wen der ausgeliehen wurde ... ?

... meint vermutlich etwas anderes als "muss reichen". Meine Erwartungshaltung hieße schon Komfort bieten oder sein lassen, wobei Komfort nicht nur einen übersichtlichen und intuitiven Aufruf beinhaltet, sondern auch eine Präsentation des Ergebnisses, mit dem man unmittelbar etwas anfangen kann.

Lightfood kann das sicherlich aus seiner Sicht präzisieren.