Nachschlagefelder

[FrankiLi]

Hallo zusammen,

ich gehe gerade das Buch "Anwendungen entwickeln mit Access" von Andre Mindhorst durch. Mich wundert, dass er dort mit Nachschlagefeldern arbeitet, die ja unter Fachleuten vehement abgelehnt werden. Dass er damit auf Einsteiger Rücksicht nimmt, glaube ich nicht, denn der Rest des Buches geht viel schneller ins Eingemachte, als die Umsetzung mit Nachschlagefeldern an Vorteilen liefern könnte, denke ich.

Es geht dabei um die Variante per Nachschlage-Assisten und separater Tabelle für die Werte, hierbei wird automatisch eine 1:n-Beziehung erstellt, also nicht die direkte Eingabe der Werte als Liste.

Habt Ihr eine mögliche Erklärung dafür, warum er die Nutzung der Nachschlagefelder empfiehlt - ich bin verwirrt. Sind die etwa doch nicht so "schlimm"?

Gruss
Frank

[Lachtaube]

Woher sollen wir denn die Intension des Buchautors beim Verfassen des Artikels zu Nachschlagefeldern kennen?

[FrankiLi]

Ich weiß nicht, woher Du ("wir"?) die kennen solltest, es geht auch nicht um einen "Artikel", aber vielleicht hast Du ja eine Idee dazu - wenn nicht, ist das natürlich nicht schlimm

[Josef P.]

Hallo!

Es geht dabei um die Variante per Nachschlage-Assisten und separater Tabelle für die Werte, hierbei wird automatisch eine 1:n-Beziehung erstellt, also nicht die direkte Eingabe der Werte als Liste.

Das setzte ich im folgenden Text voraus.

Meine Meinung zu Nachschlagefeldern:
Sie können Anfänger vortäuschen, dass "Text" im Datenfeld steht und keine Zahl (Fremdschlüssel zur Auswahltabelle). Sie verhindern daher eventuell das Verstehen der Datenmodellierung.
Aus diesem Grund ist es durchaus empfehlenswert sie einem Anfänger am Anfang etwas auszureden. Das ist einfacher als die Funktionsweise zu erklären. Diese erklärt sich später von alleine, wenn man weiß, wie ein Datenmodell aufgebaut wird und dann entscheidet Nachschlagefelder zu verwenden.

Wenn du im DBWiki-Artikel "Die Nachteile von Nachschlagefeldern" liest, wirst du feststellten, dass die meisten Argumente wirkungslos werden, wenn man weiß, wie Nachschlagefelder funktionieren.
Würde ich ein Access-Backend verwenden, würde ich Nachschlagefelder nicht einsetzen, weil ich keine Vorteile davon habe.

Nachschlagefelder erleichtern meiner Meinung nach nur die Eingabe der Daten direkt in die Tabelle. Das ist dann aber bei meinen Anwendung nur für mich bei Konfigurationstabellen. Die Anwender lasse ich niemals direkt in die Tabelle.
Ich gaub beim Erstellen eines Formulars wird dann bei diesen Feldern auch gleich eine Combobox verwendet. Das kann man als vorteilhaft betrachten, weil man die Combox nicht selbst füllen muss.

Folgender Punkt aus dem DBWiki kann richtig oder falsch sein:

Berichte, deren Datenherkunft Nachschlagefelder enthält, benötigen Kombinationsfelder zu deren Darstellung, die den Bericht langsam und ineffizient machen können.

Warm soll ich dazu gezwungen werden, eine Combobox im Bericht zu verwenden? Ich kann in der Berichtsquelle einen Join auf die verwendete Datenquelle vom Nachschlagefeld verwenden und dann direkt den "Beschreibungstext" im Bericht anzeigen.
Vielleicht wird im DBWiki-Artikel auch davon ausgegangen, dass Nachschlagefelder hauptsächlich Wertlisten und keine Tabelle für die Auswahl verwenden.

Warum Andre Nachschlagefelder verwendet, weiß ich nicht. Ich bin mir allerdings sicher, dass er weiß wie sie funktionieren.

mfg
Josef

[FrankiLi]

Warum Andre Nachschlagefelder verwendet, weiß ich nicht. Ich bin mir allerdings sicher, dass er weiß wie sie funktionieren.

Das bin ich mir auch, deshalb bin ich ja so verwundert. Insbesondere wegen dem auch von Dir verwendeten Grund, dass das ja nur bei Arbeiten in der Tabelle (statt im Formular) hilfreich wäre und das per se keine gute Idee ist.

Seltsam.

Vielleicht wird im DBWiki-Artikel auch davon ausgegangen, dass Nachschlagefelder hauptsächlich Wertlisten und keine Tabelle für die Auswahl verwenden.

Dazu würden mich brennend weitere Meinungen interessieren.

PS: Lorenz Hölscher verwendet in seinen Videos auch Nachschlagefelder. Da bin ich aber noch davon ausgegangen, dass sich das nur an absolute Anfänger richtet.

[Josef P.]

.. dass das ja nur bei Arbeiten in der Tabelle (statt im Formular) hilfreich wäre

Beim Erstellen von Formularen hilft dann Access mit, gleiche eine Combobox zu erstellen. Das erspart einen Arbeitsschritt, wenn man diese Combobox nutzen will.

Anm.: Es spricht z. B. nichts dagegen für die Anwendungsentwicklung ein Nachschlagefeld zu verwenden und ein Produktiv-Backend ohne die Nachschlagefelder einzusetzen.

LG
Josef

[FrankiLi]

Anm.: Es spricht z. B. nichts dagegen für die Anwendungsentwicklung ein Nachschlagefeld zu verwenden und ein Produktiv-Backend ohne die Nachschlagefelder einzusetzen.

Meinst Du damit, dass die Nachschlagefelder (die Variante mit Tabelle) in der Entwicklung Zeit sparen könnten und mit Backend später einfach ihren Nutzen in der Tabelle automatisch verlieren, aber dann auch kein Nachteil sind?

[Josef P.]

Ein Szenario:

Du erstellst eine Tabelle mit einem Nachschlagefeld, das die Werte aus einer anderen Tabelle holt (id + Bezeichnung).
Dann erstellst du ein Formular, bindest das an die Tabelle und fügst aus der Feld-Liste ("vorhandene Felder hinzufügen") das Datenfeld ein, das in der Tabelle ein Nachschlagefeld zugeordnet bekommen hat.
Es wird dann keine Textbox sondern eine Combobox ins Formular eingefügt.
Wenn du dann in der Tabelle die Nachschlagefunktionalität löscht, wird die Combobox eine Combobox bleiben und wie eine Combobox funktionieren.

Ob das praktischer als das Einfügen einer Combobox inkl. dem Einstellen der Datenquelle ist, darf jeder selbst beurteilen. Für mich stellst sich die Frage nicht, da ich kein Access-Backend verwende und daher sowieso keine Nachschlagefelder nutze.


Falls das Nachschlagefeld in der Backend-Tabelle bleibt, wird vermutlich auch nicht viel passieren. Ob es zu Performance-Unterschieden kommt, kann ich mangels Interesse, das zu testen, nicht beurteilen.
Dass, wie im DBWiki beschrieben, eine Referenz und ein Index angelegt wird, kann ich nicht bestätigen. Zumindest konnte ich über die Index-Auflistung keinen Index bemerken. Den im Entwurf unsichtbaren aber über die Index-Auflistung sichtbaren Index, der aufgrund von Beziehungen erstellt wird, gab es zumindest nicht. Das schließt allerdings nicht aus, dass intern doch so eine Beziehung erstellt wird. Allerdings würde mich interessieren, was für eine Beziehung das sein soll, da bei meinem Test eine RI-Verletzung nicht verhindert wurde.
Anm.: Ich testete mit Access 2016 und einer accdb-Datei.

Bitte nicht falsch verstehen: ich will hier nicht zur Verwendung von Nachschlagefeldern animieren sondern nur einmal ein wenig über das "absolute Verbot" diskutieren, da ich der Meinung bin, dass man die Nachschlagefunktionalität durchaus einsetzen darf, wenn man die Funktionsweise kennt und man Vorteile davon hat.
Mangels Erfahrung (also auch keine positive oder negative Erfahrung) bewerte ich das nur aus meinem Verständnis über die Funktionsweise.
Vielleicht kann jemand ein Beispiel beschreiben, bei dem ein Nachschlagefeld zu einem Fehler führte, der nicht auf einer "Falschbedienung" beruht.

mfg
Josef

[crystal]

Hallo Frank,
meine Meinung zu Nachschlagefeldern ist folgende:
1. sie sind in einer frühen Phase der Entwicklung eines Datenmodells sehr hilfreich. Da man in dieser Phase nur mit Tabellen (mit Beispieldaten) und Abfragen arbeitet, ist es schlicht angenehm, in einer Auftrags-Tabelle den Wert "Maier & Co." statt einer Zahl zu sehen (Referenz auf z.B. Kundentabelle).
2. erleichtern sie die Erstellung von Formularen (Kombifelder).
3. können sie dazu beitragen, das Datenmodell richtig zu konstruieren (Referenzfelder/Fremdschlüssel)
4. kann man sie jederzeit entfernen, wenn das Datenmodell steht (was man dann auch tun sollte)

Es ist ähnlich wie mit verknüpften Tabellen. In der Entwurfsphase ist es schlicht hilfreich, durch einfaches Klicken auf das +-Symbol die verknüpften Datensätze sehen zu können.

Ich betrachte dies eher als Hilfe für den Entwickler. Ebenso wie diverse Message-Boxen und Debug.Prints im Code sollte man das aber entfernen, wenn die Anwendung ausgereifter ist.

Warum Andre Minhorst, den ich als Praktiker und Experten durchaus schätze, NFs in seinem Buch nutzt (offenbar ohne dies zu kommentieren oder zu begründen) kann ich auch nicht sagen. Vielleicht ist sein Buch entstanden, als NFs noch neu waren und die negativen Konsequenzen noch nicht so klar, wie sie es heute sind.

Letztlich bleibt, dass NFs ja im Prinzip nur zum Tragen kommen, wenn man eine Tabelle direkt aufruft. Das sollte in einer fertigen Applikation (durch den Nutzer) ohnehin nicht erfolgen, kann aber für den Entwickler hilfreich sein.

Jedenfalls ist es schön, dass du die Nutzung von NFs kritisch hinterfragst, denn das beweist, dass du Access zu verstehen beginnst und allmählich in seine Tiefen eintauchst. In diesem Sinne vielen Dank für deine Nachfragen, die ja auch dazu dienen, anderen Erkenntnisse zu liefern, die gerade beginnen, mit Access zu arbeiten.

lg
crystal

PS: Sorry, wenn ich hier bereits geschriebene Aussagen wiederhole, ohne jedesmal den Autor zu nennen. Ich wollte die Meinungen einfach nur zusammenfassen

[MaggieMay]

Hallo miteinander,

was die Nachschlagefelder in Tabellen betrifft, so meine auch ich, dass sie nicht völlig sinnfrei sind, aber ich vermeide sie aus denselben Gründen wie ich auch Makros nicht einsetze: Die Verwendung von VBA- (bzw. SQL-) Code ist einfach transparenter! Da kannst du im VBA-Editor ganz einfach mal nach einer Variablen suchen: Wo ist sie deklariert, wo wird sie verwendet? Ebenso wie auch nach Prozeduren.

Wie aber könnte man sich auf ähnlich einfache Art und Weise einen Überblick über in Makros verwendete Variablen, Prozedur-, Formular- oder Berichtsaufrufe informieren?!

[Josef P.]

Hallo!

@crystal
Von Andre gibt es einen Artikel zu den Nachschlagefeldern: Nachschlagefelder - Pro und Kontra

mfg
Josef