Office: (Office 2007) SVERWEIS Funktion nach Access

Sinnvolle Tabellenstrukturen sollten nicht nur auf einzelne Tabellen angewendet werden, sondern auf alle. Auch Zeiträume oder andere Grenzen kann man als Datensatz ablegen.

Vielleicht solltest Du Dir einen Grundunterschied vor Augen halten:
Eine Exceltabelle speichert Daten, führt Berechnungen aus und stellt dar.
Demgegenüber dient eine Datenbanktabelle rein dazu, Daten zu speichern - ein Anwender wird sie gar nicht zu Gesicht bekommen.
Berechnungen werden von Abfragen und weiteren Anweisungen ausgeführt. Die Darstellung für den Anwender ist dann Aufgabe von Formularen und Berichten.

 

Hallo Peter,
ändern sich die Rating-Grenzwerte im Zeitablauf oder sind diese für die Zukunft als festgelegt anzunehmen?

 

\@Eberhard

Dies ist mir durchaus bewußt.

@Marsu

Die Grenzwerte sollen starr bleiben.

 

Auch wenn ich nun wieder mit dem Argument geschlagen werde, dass sich selbst Feiertage ändern können
bzw. Einwände der SQL-Puristen *wink.gif* kommen werden.
Ich würde in dem Fall eine kleine Funktion schreiben, die bei Übergabe der beiden Werte das Rating zurückgibt.
Diese kann - in einem globalen Modul stehend - dann auch in Abfragen verwendet werden.

 

Hallo Marsu,

das habe ich mir auch gerade überlegt. Ich werde eine Schleife programmieren und für die Flexibilität die Grenzwerte bei Bedarf über ein bzw. zwei Formulare abänderbar machen.

Danke für die Tipps.

Peter

 

Ich würde sagen, wenn man sich im tiefen Wasser bewegt, ist Schwimmen nicht puristisch, sondern pragmatisch.

Ich halte den Ansatz von maike (#11) für sehr sinnvoll und mit passenden Tabellen auch sehr einfach. Flexible Grenzwerte kann man auch in einer Tabelle pflegen.

In dem Moment, wo ein solches berechnetes Feld dann weiter gefiltert, gruppiert, sortiert werden soll, stirbt eine mögliche Indexnutzung. Die Performance, die man dann liegen lässt, lässt sich kaum mit anderen Methoden aufholen.
Für manche mag das eine theoretische Blase sein (die Kraft des Prozessors macht das schon), bei einer Datenbank sollte man aber von großen Datenmengen ausgehen (sagte ein kluger Mann). Kleine Datenmengen beherrscht man dann erst recht.

 

\@Eberhard

Was wäre denn nach Deiner Ansicht eine sinnvolle Tabellenstruktur ?

Peter

 

Hallo,
die von mir in #4 vorgeschlagen Lösung geht auch problemlos mit Vergleichsoperatoren (>= oder

 

\@Klaus

Ich habe nun schon mehrere Variationen von Tabellen ausprobiert. Ebenfalls auch Dein Vorschlag, der wie schon erwähnt, bis auf die Bereichsabfrage funktioniert.

Was mir aber z.Zt. nicht einfällt an welchen Stelle und wie ich die Vergleichsoperatoren implementiere.

Ich muss beide Tabellen auf irgendeinerweise verknüpfen und durch eine Abfrage oder Funktion dem "Programm" sagen: Suche den passenden Bereich (Rating) in der ersten Tabelle und schreibe den Wert in die zweite bzw. in eine Abfrage.

Peter

 

Hallo Peter,
mit der unten gezeigten Grenzwerttabelle funktioniert das recht einfach wenn man mit Unterabfragen arbeitet.

Die Abfrage dazu:
Code:

Joins

 

Altenativ Ratingtabelle mit von-bis Grenzen und Join-Abfrage:

Code:

 

... mit indizierten Feldern?

Ich sprach auch von größeren(!) Datenmengen, laut Beitrag #1 reicht eine Exceltabelle nicht mehr aus (im Format 97-2003 wären das deutlich mehr als 65.000, ab Excel2007 noch ein paar mehr).

Größere Datenmengen hat man aber nicht nur bei betrieblichen Daten, sondern durchaus über bestimmte Gestaltungen auch schon in einer Kochrezepte-DB. Ein Kreuzprodukt aus drei Tabellen mit je 100 Datensätzen ergibt auch 1.000.000 Datensätze ...

@Peter: Ich hantiere noch mit Acc2000 und kann somit Deine DB auch nicht ansehen. Für Abfragen und als Basis Tabellen reicht aber auch das Acc2000-Format. Alles, was Acc2010 in diesem Zusammenhang mehr kann als Acc2000, ist zumindest kritisch zu betrachten, wenn ich mal DataMacros ausnehme.

 

OT: @ Eberhard
Der Einsatz von Funktionen statt reinem SQL für berechnete Felder in Abfragen ist in best. Fällen sogar von Vorteil.
Z.B. bei der Anzeige von nur wenigen DS im Formular (man zeigt ja keine 100.000 DS auf einmal an.
Oder auch wenn ein Anfügen von DS gefordert ist. (Was weder bei oben gezeigte Subselect, noch bei der Joinvariante möglich ist)

Vlt. ist im nächsten Livemeeting Platz für das Bsp.

Vom Prinzip (SQL ist VBA vorzuziehen) her gebe ich dir gerne Recht. Es gibt jedoch auch (Spezial-?) Fälle in denen der Einsatz von VBA vorteilhaft sein kann.

 

Moin zusammen,

Wow. Erstmals herzlichen Dank für die kreativen Beiträge. Ich werde den Lösungsansatz von Marsu mal testen und später berichten.

@ Eberhard
Du hast vollkommen recht bezüglich der Datenmenge. Diese wird weit über 1.000.000 Datensätze beinhalten.

P.S. Die Angabe über meine Access-Version muss ich wohl nochmals ändern.
Im Profil steht noch Acc2003 tatsächlich ist es Acc2007

Gruß

Peter