Hallo Zusammen,
mal eine grundsätzliche Frage zu Abfragen. Hoffe ich bin nicht auf dem Holzweg.
Thema Normalisierung
Siehe Bilder Beispiel.
Das genannte Beispiel sind mind 5 Abfragen, die aufeinander folgen.
Damit meine ich, dass
z.b. Abfrage 1 ersteinmal den Status (letzterWert) ermittelt.
Abfrage 2 Ermittelt die Summe der Packstücke
und Abfrage 3 ermittelt den jeweiligen Firmennamen
Abfrage 4 bekommt Abfrage 3 + Abfrage 2
Die Verknüpfung ist hierbei auf 2 .. ermittelt alle DS auch die , die keinen Wert in Tabelle Packstücke hat.
ich möchte alle Aufträge sehen.
so und dann noch Abfrage 5
Diese besteht aus Abfrage 4 + Abfrage 1
und dann komme ich zum gewünschten Ergebnis siehe BILD C
So und nun zu meiner eigentlichen Frage..
Ist das wirklich der Weg oder verrenne ich mich in etwas ?
Wenn ja das ist der Weg:
Mir kommt das Performance mässig schlechter vor,
als wenn ich alles in eine Tbl schreibe.
Wenn ja, das ist falsch.
Was wäre die Alternative ?#
Lg Bernie
Hallo,
vermutlich ist das durch die Brust ins Auge geschossen...
Zeige mal das Beziehungsfenster (mit allen Tabellen- und Feldnamen) und erkläre, was Du analysieren willst.
(z. B. "Anzahl der Packstücke eines jeden Kunden, die den Status xyz haben mit Anzeige der Lieferanschrift und Kundennummer".)
Hallo,
Zitatvermutlich ist das durch die Brust ins Auge geschossen...
Dachte ich mir. :(
ZitatZeige mal das Beziehungsfenster (mit allen Tabellen- und Feldnamen) und erkläre, was Du analysieren willst.
Ich dachte das wäre zu verwirrend. Daher hatte ich mich bemüht es mit den Bildern einfach zu halten.
Ist das nicht besser ?
Im Prinzip möchte ich doch nur eine
Ansicht mit allen relevanten Daten.
Ich dachte ich mach das über Abfragen.
Und hole mir somit aus jeder Tabelle das richtige Feld.
Einen anderen weg kenn ich leider nicht.
Gibt es noch andere Möglichkeiten ?
Lg
Bernie
Anbei das Beziehungsfenster
Das Formular wies aussehen soll
und die Abfragen die Bestandteil zum Formular sind
Lg Bernie
Hallo,
sorry, im Beziehungsfenster kann ich nicht viel erkennen, weil zu klein, außer, dass die Beziehungen selber mangelhaft , d. h. gar keine sind...
Da gibt es jede Menge Überarbeitungspotential.
Zudem ist mir immer noch nicht klar, was eigentlich erreicht werden soll, und die Abfragen sind auch nicht überschaubar oder deren Sinn zu erkennen.
Hi,
Zitatsorry, im Beziehungsfenster kann ich nicht viel erkennen, weil zu klein, außer, dass die Beziehungen selber mangelhaft , d. h. gar keine sind...
Zudem ist mir immer noch nicht klar, was eigentlich erreicht werden soll, und die Abfragen sind auch nicht überschaubar oder deren Sinn zu erkennen.
Jetzt ist vermutlich die Verwirrung komplett.
Daher postete ich ja leicht verdauliche Daten im ersten Post ;)
Ich möchte aus mehren Tabellen ein tabellarisches UFO befüllen, dass so aussieht wie
es in Bild 2 dargestellt ist.
Andere Frage. Wenn du dir mal das Bild des ersten Post mit dem Namen A_Bild_B ansiehst
Die umrandeten Daten sollen Tabellen sein.
Und unterhalb in GRÜN das soll das Ergebnis sein.
Wie würdest du das machen ?
Lg Bernie
Vermutlich würde Franz saubere Tabellen mit sauberen Beziehungen (inkl. referentieller Integrität) herstellen, auf eine sinnvolle Indizierung achten und dann eine Abfrage erstellen, die nur notwendige Felder aus nur benötigten Tabellen verbindet und verarbeitet - soll ja auch noch performant sein.
Dazu sind Deine bisherigen Darstellungen allesamt nicht geeignet, um da einen Ansatz anbieten zu können.
So wie eine Kfz-Werkstatt sich wegen einer Reparatur das Auto anschaut statt einigen von mir geschossenen Bildern, so solltest Du vielleicht eine Demo der DB mit wenigen aber aussagekräftigen Datensätzen anbieten. Keine überflüssigen Formulare und Berichte.
Hallo Ebbs,
einverstanden.
Hier die Beispieldatenbank.
So in etwa sieht mein Tabellenaufbau aus
Zur Erklärung :
DT_TABELLE = Auftragserfassung
LA_Tabelle = Zwischentabelle für die Verpackungsstation
LA_MASSE_Tabelle = Tabelle mit allen Packstücken
TA_Tabelle = Transportauftragstabelle. Hier wird der Sendungsweg erfasst. ( das wird benötigt, da ein Auftrag z.b. von München nach Stuttgart und dann weiter nach Frankfurt verladen werden kann )
TA_Status_Tabelle : aktueller Status der Sendung.. Zb. wurden
Packstücke erfasst lautet der Status "Ladebereit"
Bei nicht erfassten Packstücken lautet dieser Angelegt.
Die X-Abfrage ist das was ich brauche.
Alle DS mit den entsprechenden Daten .. ( auch ohne erfasste Masse )
Hoffe das hilft
Lg Bernie
Hallo,
warum lädst Du eine DB hoch in der keine Beziehungen angelegt sind?
Das gehört unbedingt dazu, damit man die Zusammenhänge DB überblicken kann.
Hallo MzKlMu
weil ich nicht weiss, wie es sinnvoll aussehen muss.
Franz sagte ja bereits, das meine IST-Beziehungen schei** sind ;-)
Mir bereiten die Beziehungen der TA-Tabelle Schwierigkeiten.
Das ist eigentlich eine eigenständige Tabelle die lediglich ein Feld erhält DT_ID und damit ein einer 1:n Beziehung zu DT_Tabelle steht..
Menno ich weiss es doch nicht. :(
Lg Bernie
Hallo,
wieso gibt es in fast jeder Tabelle eine DT_ID und was bedeuten die Kürzel LA, TA, DT?
Und in welcher Beziehung steht die KD-Tabelle?
hi,
Zitatwieso gibt es in fast jeder Tabelle eine DT_ID und was bedeuten die Kürzel LA, TA, DT?
Die Erklärung steht doch im Post des Downloads.
ZitatZur Erklärung :
DT_TABELLE = Auftragserfassung
LA_Tabelle = Zwischentabelle für die Verpackungsstation
LA_MASSE_Tabelle = Tabelle mit allen Packstücken
TA_Tabelle = Transportauftragstabelle. Hier wird der Sendungsweg erfasst. ( das wird benötigt, da ein Auftrag z.b. von München nach Stuttgart und dann weiter nach Frankfurt verladen werden kann )
TA_Status_Tabelle : aktueller Status der Sendung.. Zb. wurden
Packstücke erfasst lautet der Status "Ladebereit"
Bei nicht erfassten Packstücken lautet dieser Angelegt.
ZitatUnd in welcher Beziehung steht die KD-Tabelle?
Die KD_Tabelle = Adressen
Die KD_ID gibt in den Tabellen TA_Tabelle & DT_Tabelle an
Welche Adresse sich hinter AG_ID / ABS_ID / EMPF_ID befindet
Ist mein Beispiel und das was ich möchte denn so unverständlich ???
Die Abfrage X... liefert bereits die gewünschten Werte
Das soll das Ergebnis sein.
Die Frage ist nur, ob das der richtige Weg ist ?
Lg Bernie
Hallo Bernie,
Zitat von: Bernie110 am September 30, 2014, 18:54:24
Zitatwieso gibt es in fast jeder Tabelle eine DT_ID [...]?
Die Erklärung steht doch im Post des Downloads.
kann ich dort nicht finden. :(
Mindestens in einer der LA-Tabellen dürfte die DT_ID verzichtbar sein.
ZitatDie KD_ID gibt in den Tabellen TA_Tabelle & DT_Tabelle an
Welche Adresse sich hinter AG_ID / ABS_ID / EMPF_ID befindet
Um diese Beziehungen herstellen zu können, musst du die Kundentabelle mehrfach ins Beziehungsfenster holen.
ZitatIst mein Beispiel und das was ich möchte denn so unverständlich ???
Ich finde es immer ziemlich irritierend, wenn in nachfolgenden Beispielen von den ursprünglich gewählten Bezeichnungen abgewichen wird. Anfangs geht es um Aufträge, deren Status und Packstücke. Später wird daraus ohne konkrete Erklärungen/Begründungen LA, TA und DT. (= Liefer-Auftrag? T??-Auftrag? D??-T?? ::))
ZitatDie Frage ist nur, ob das der richtige Weg ist ?
Es geht sicherlich einfacher, aber dafür müssen zuerst die Tabellenbeziehungen restlos aufgeklärt werden.
Hi Maggie,
vielen Dank für deine Mühe.
Ich habe versucht mein Problem, meiner Fähigkeiten entsprechend so gut wie möglich zu beschreiben.
Mehr kann ich nicht vermitteln, um zu meinem Problem eine Antwort zuerhalten.
Ich bin ein Leihe und nicht so gut mit dem was erwartet wird bewandert.
Werd wohl mit meinem Abfrage in Abfrage Gedöns leben müssen.
Wird schon irgendwie gehen.
Ich bedanke mich dennoch recht herzlich für jedes Posting und eure Mühe.
Der Fred kann geschlossen werden
Lg Bernie
Hallo Bernie,
das Problem ist halt, dass wir (mindestens ich) nicht nachvollziehen können, was Du meinst und brauchst.
Nur Du allein kennst die Umgebung (Datenlage) und die Anforderungen daran. Ein bisschen klareren Durchblick müssten wir schon bekommen, um auch erfolgversprechend helfen zu können.
Um da weiter zu kommen, schlage ich Dir vor, in eine neue leere DB(-Datei) die für dieses Problem wichtigen/notwendigen Tabellen zu importieren (einschließlich einiger passenden Spieldaten) und ein Formular zu erstellen, das Deinen Erwartungen nahe kommt.
Diese Datei lädst Du hier dann hoch und beschreibst nochmal möglichst genau (unter Verwendung der in den Tabellen verwendeten Feldnamen) das Problem, bzw. Deine Wunsch-Erwartung.
Hallo Franz,
in Ordnung. Nun habe ich die BeispielDB nochmals etwas angepasst.
Bitte fragt, wenn es immer noch zu unverständlich ist.
Ich möchte doch nur Sendungen von A nach B und dann nach C schicken :-)
Lg Bernie
Hallo Zusammen,
das würde meine Frage beantworten.
https://www.youtube.com/watch?v=AnbjK3nhry0
Was hält ihr davon ?
Lg Bernie
Ich hab das nun mal aus probiert und 4 Abfragen so wie im Video beschrieben eingebunden..
ich sag nur Boa ist das schnell..
Jetzt bleibt nunr noch die Frage zu klären.. Ist das zeilführend oder nicht ?
Lg Bernie
Ps. bin schon mal gespannt auf eure Antworten
Das was im Video beschrieben ist, ist hier (klick mich (http://www.ms-office-forum.net/forum/showpost.php?p=1615764&postcount=5)) ebenfalls kurz beschrieben.
Dazu als Statement: Ob eine Abfrage eine weitere Abfrage aufruft und diese wieder eine weitere oder ob man die SQL-Anweisungen dieser Abfragen zu einer zusammenfasst und diese ausführt, ist hinsichtlich Performance erst einmal egal.
Eine Abfrage enthält keine Daten, sondern nur die Definition, wie Daten aus Tabellen/Abfragen zu holen und zu verarbeiten sind. Im Ergebnis muss also die ganze Litanei abgearbeitet werden, so oder so.
Allerdings: In der zusammengefassten SQL-Anweisung gewinnt man eher einen Überblick.
- So kann man z.B. Felder (oder ganze Tabellen) in Teilabfragen beseitigen, die für die insgesamte Berechnung nicht benötigt werden => ein kleineres Recordset wird schneller zu verarbeiten sein.
- Im gleichen Sinne erkennt man unnötige Operationen in den Teilabfragen wie z.B. Sortierungen => Aufwand, aber keine Wirkung nach außen.
- Eine Abfrage wird vor Ausführung optimiert und daraus ein Ablaufplan erstellt, der nachfolgend verwendet wird. Die Optimierung kann aber nur von Vorhandenem ausgehen und dauert in Jet nicht sehr lange, ist also nicht das "Optimalste", sondern nur "nicht ganz schlecht".
Mit eigenem Abfragedesign, das man nun nur in der Gesamtansicht erkennt, kann man dem Optimierer helfen, einen guten und somit performanten Ablaufplan zu erstellen.
Zitat4 Abfragen so wie im Video beschrieben eingebunden..
Dann zeige doch mal die resultierende SQL-Anweisung.
Hallo Ebs,
das heisst also es hat keine wirkliche Auswirkung auf die Performance ?
Hier mal der zusammengefasste SQL String :
SELECT qyr_DISPO_TA_UFO_B2.LA_ID, X_A_qyr_LA_STATUS_B.STATUS_LA, qyr_DISPO_TA_UFO_B2.STATUS_TA, qyr_DISPO_TA_UFO_B2.NL, qyr_DISPO_TA_UFO_B2.TA_ID, qyr_DISPO_TA_UFO_B2.DT_NR, qyr_DISPO_TA_UFO_B2.DISPO_ART, qyr_DISPO_TA_UFO_B2.SNDG_ART, qyr_DISPO_TA_UFO_B2.Ladedatum, qyr_DISPO_TA_UFO_B2.Ladezeit, qyr_DISPO_TA_UFO_B2.Entladedatum, qyr_DISPO_TA_UFO_B2.Entladezeit, qyr_DISPO_TA_UFO_B2.TOUR_ID, qyr_DISPO_TA_UFO_B2.ABS_FirmenName1, qyr_DISPO_TA_UFO_B2.ABS_Strasse2, qyr_DISPO_TA_UFO_B2.ABS_Land, qyr_DISPO_TA_UFO_B2.ABS_Plz, qyr_DISPO_TA_UFO_B2.ABS_Ort, qyr_DISPO_TA_UFO_B2.ABS_Ort_Lang, qyr_DISPO_TA_UFO_B2.EMPF_FirmenName1, qyr_DISPO_TA_UFO_B2.EMPF_Land, qyr_DISPO_TA_UFO_B2.EMPF_Plz, qyr_DISPO_TA_UFO_B2.EMPF_Ort, qyr_DISPO_TA_UFO_B2.EMPF_Ort_Lang, qyr_DISPO_TA_UFO_B2.Colli, qyr_DISPO_TA_UFO_B2.KG, qyr_DISPO_TA_UFO_B2.LM, qyr_DISPO_TA_UFO_B2.Qbm, qyr_DISPO_TA_UFO_B2.LTW_ID, qyr_DISPO_TA_UFO_B2.LTW, qyr_DISPO_TA_UFO_B2.DISPO_Markierung, qyr_DISPO_TA_UFO_B2.AuftragsNr, qyr_DISPO_TA_UFO_B2.AuftragsNr, qyr_DISPO_TA_UFO_B2.[NOT].FirmenName1, qyr_DISPO_TA_UFO_B2.AG.FirmenName1, qyr_DISPO_TA_UFO_B2.ABS.FirmenName1, qyr_DISPO_TA_UFO_B2.EMPF.FirmenName1, qyr_DISPO_TA_UFO_B2.PA, qyr_DISPO_TA_UFO_B2.KA, qyr_DISPO_TA_UFO_B2.RO, qyr_DISPO_TA_UFO_B2.LS_NR
FROM qyr_DISPO_TA_UFO_B2 INNER JOIN [SELECT qyr_DISPO_TA_UFO_B1.NL,qyr_DISPO_TA_UFO_B1.STATUS_TA,qyr_DISPO_TA_UFO_B1.LA_ID,qyr_DISPO_TA_UFO_B1.TA_ID,qyr_DISPO_TA_UFO_B1.DT_NR,qyr_DISPO_TA_UFO_B1.DISPO_ART,qyr_DISPO_TA_UFO_B1.SNDG_ART,qyr_DISPO_TA_UFO_B1.Ladedatum,qyr_DISPO_TA_UFO_B1.Ladezeit,qyr_DISPO_TA_UFO_B1.Entladedatum,qyr_DISPO_TA_UFO_B1.Entladezeit,qyr_DISPO_TA_UFO_B1.TOUR_ID,qyr_DISPO_TA_UFO_B1.ABS_FirmenName1,qyr_DISPO_TA_UFO_B1.ABS_Strasse2,qyr_DISPO_TA_UFO_B1.ABS_Land,qyr_DISPO_TA_UFO_B1.ABS_Plz,qyr_DISPO_TA_UFO_B1.ABS_Ort,qyr_DISPO_TA_UFO_B1.ABS_Ort_Lang,qyr_DISPO_TA_UFO_B1.EMPF_FirmenName1,qyr_DISPO_TA_UFO_B1.EMPF_Land,qyr_DISPO_TA_UFO_B1.EMPF_Plz,qyr_DISPO_TA_UFO_B1.EMPF_Ort,qyr_DISPO_TA_UFO_B1.EMPF_Ort_Lang,qyr_DISPO_TA_UFO_B1.Colli,qyr_DISPO_TA_UFO_B1.KG,qyr_DISPO_TA_UFO_B1.LM,qyr_DISPO_TA_UFO_B1.Qbm,qyr_DISPO_TA_UFO_B1.LTW_ID,qyr_DISPO_TA_UFO_B1.LTW,qyr_DISPO_TA_UFO_B1.DISPO_Markierung,Y_A_qyr_DT_mit_Adressen.AuftragsNr,Y_A_qyr_DT_mit_Adressen.[NOT].FirmenName1,Y_A_qyr_DT_mit_Adressen.AG.FirmenName1,Y_A_qyr_DT_mit_Adressen.ABS.FirmenName1,Y_A_qyr_DT_mit_Adressen.EMPF.FirmenName1,qyr_DISPO_TA_UFO_B1.PA,qyr_DISPO_TA_UFO_B1.KA,qyr_DISPO_TA_UFO_B1.RO,qyr_DISPO_TA_UFO_B1.LS_NR
FROM qyr_DISPO_TA_UFO_B1 INNER JOIN (SELECT qyr_DISPO_TA_UFO_B.TA_ID,qyr_DISPO_TA_UFO_B.LA_ID,qyr_DISPO_TA_UFO_B.STATUS_TA,qyr_DISPO_TA_UFO_B.NL,qyr_DISPO_TA_UFO_B.DT_NR,qyr_DISPO_TA_UFO_B.DISPO_ART,qyr_DISPO_TA_UFO_B.SNDG_ART,qyr_DISPO_TA_UFO_B.Ladedatum,qyr_DISPO_TA_UFO_B.Ladezeit,qyr_DISPO_TA_UFO_B.Entladedatum,qyr_DISPO_TA_UFO_B.Entladezeit,qyr_DISPO_TA_UFO_B.TOUR_ID,qyr_DISPO_TA_UFO_B.ABS_FirmenName1,qyr_DISPO_TA_UFO_B.ABS_Strasse2,qyr_DISPO_TA_UFO_B.ABS_Land,qyr_DISPO_TA_UFO_B.ABS_Plz,qyr_DISPO_TA_UFO_B.ABS_Ort,qyr_DISPO_TA_UFO_B.ABS_Ort_Lang,qyr_DISPO_TA_UFO_B.EMPF_FirmenName1,qyr_DISPO_TA_UFO_B.EMPF_Land,qyr_DISPO_TA_UFO_B.EMPF_Plz,qyr_DISPO_TA_UFO_B.EMPF_Ort,qyr_DISPO_TA_UFO_B.EMPF_Ort_Lang,qyr_DISPO_TA_UFO_B.LTW_ID,qyr_DISPO_TA_UFO_B.LTW,qyr_DISPO_TA_UFO_B.DISPO_Markierung,Z_qyr_TA_PACKSTÜCKE_C.Colli,Z_qyr_TA_PACKSTÜCKE_C.LM,Z_qyr_TA_PACKSTÜCKE_C.Qbm,Z_qyr_TA_PACKSTÜCKE_C.KG,Z_qyr_TA_PACKSTÜCKE_C.PA,Z_qyr_TA_PACKSTÜCKE_C.KA,Z_qyr_TA_PACKSTÜCKE_C.RO,qyr_DISPO_TA_UFO_B.LS_NR
FROM qyr_DISPO_TA_UFO_B LEFT JOIN (SELECT qyr_DISPO_TA_UFO_A.TA_ID,qyr_DISPO_TA_UFO_A.STATUS_TA,qyr_DISPO_TA_UFO_A.LA_ID,qyr_DISPO_TA_UFO_A.NL,qyr_DISPO_TA_UFO_A.DT_NR,qyr_DISPO_TA_UFO_A.DISPO_ART,qyr_DISPO_TA_UFO_A.SNDG_ART,qyr_DISPO_TA_UFO_A.Ladedatum,qyr_DISPO_TA_UFO_A.Ladezeit,qyr_DISPO_TA_UFO_A.Entladedatum,qyr_DISPO_TA_UFO_A.Entladezeit,qyr_DISPO_TA_UFO_A.TOUR_ID,qyr_DISPO_TA_UFO_A.ABS_FirmenName1,qyr_DISPO_TA_UFO_A.ABS_Strasse2,qyr_DISPO_TA_UFO_A.ABS_Land,qyr_DISPO_TA_UFO_A.ABS_Plz,qyr_DISPO_TA_UFO_A.ABS_Ort,qyr_DISPO_TA_UFO_A.ABS_Ort_Lang,qyr_DISPO_TA_UFO_A.EMPF_FirmenName1,qyr_DISPO_TA_UFO_A.EMPF_Land,qyr_DISPO_TA_UFO_A.EMPF_Plz,qyr_DISPO_TA_UFO_A.EMPF_Ort,qyr_DISPO_TA_UFO_A.EMPF_Ort_Lang,qyr_DISPO_TA_UFO_A.LTW_ID,qyr_DISPO_TA_UFO_A.LTW,qyr_DISPO_TA_UFO_A.DISPO_Markierung,V_LA_MA_TABELLE.LS_NR
FROM qyr_DISPO_TA_UFO_A LEFT JOIN (SELECT TA_TABELLE.TA_ID,TA_TABELLE.STATUS_TA,TA_TABELLE.LA_ID,TA_TABELLE.NL,TA_TABELLE.DT_NR,TA_TABELLE.DISPO_ART,TA_TABELLE.SNDG_ART,TA_TABELLE.ABS_ID,TA_TABELLE.EMPF_ID,TA_TABELLE.Ladedatum,TA_TABELLE.Ladezeit,TA_TABELLE.Entladedatum,TA_TABELLE.Entladezeit,TA_TABELLE.TOUR_ID,KD_TABELLE.FirmenName1 AS ABS_FirmenName1,KD_TABELLE.Strasse2 AS ABS_Strasse2,KD_TABELLE.Land AS ABS_Land,KD_TABELLE.Plz AS ABS_Plz,KD_TABELLE.Ort AS ABS_Ort, [ABS_LAND] & "-" & [ABS_Plz] & " " & [ABS_Ort] AS ABS_Ort_Lang,KD_TABELLE_1.FirmenName1 AS EMPF_FirmenName1,KD_TABELLE_1.Land AS EMPF_Land,KD_TABELLE_1.Plz AS EMPF_Plz,KD_TABELLE_1.Ort AS EMPF_Ort, [EMPF_LAND] & "-" & [EMPF_Plz] & " " & [EMPF_Ort] AS EMPF_Ort_Lang,TA_TABELLE.LTW_ID,TA_TABELLE.LTW,TA_TABELLE.DISPO_Markierung
FROM KD_TABELLE INNER JOIN (TA_TABELLE INNER JOIN KD_TABELLE AS KD_TABELLE_1 ON TA_TABELLE.EMPF_ID = KD_TABELLE_1.KD_ID) ON KD_TABELLE.KD_ID = TA_TABELLE.ABS_ID) AS V_LA_MA_TABELLE ON qyr_DISPO_TA_UFO_A.LA_ID = V_LA_MA_TABELLE.LA_ID) AS Z_qyr_TA_PACKSTÜCKE_C ON qyr_DISPO_TA_UFO_B.LA_ID = Z_qyr_TA_PACKSTÜCKE_C.LA_ID) AS Y_A_qyr_DT_mit_Adressen ON qyr_DISPO_TA_UFO_B1.DT_NR = Y_A_qyr_DT_mit_Adressen.DT_NR]. AS X_A_qyr_LA_STATUS_B ON qyr_DISPO_TA_UFO_B2.LA_ID = X_A_qyr_LA_STATUS_B.LA_ID;
Ich hoffe ich hab das auch richtige gemacht. Funktioniert jedenfalls.
Im Ufo lasse ich folgende Felder anzeigen.
TA_ID
DISPO_ART
STATUS_TA
LA_STATUS
Ladezeit
ABS_Ort_Lang
EMPF_Ort_Lang
CLL
Ladedatum
KG
LM
NL
SNDG_ART
QBM
KA
RO
DISPO_Markierung
LTW_ID
LTW
Entladedatum
Entladezeit
DT_NR
LA_ID
TOUR_ID
NOT
AuftragsNr
ABS_Land
ABS_Plz
ABS_Ort
EMPF_Land
EMPF_Plz
EMPF_Land
EMPF_Ort
FHZ_BEZ
FirmenName1
Die DB wird momentan in Access 2000 entwickelt und soll aber später in eine Access 2013 DB konvertiert werden.
Im Anschluss werden dann die Tabellen in einen SQL Server eingebunden.
Das wäre mal der Plan. Stellt sich die Frage wie hoch die Performance sein wird, wenn ca 50 User in 6 Niederlassungen damit arbeiten.
Ausgehen muss man von ca 200.000 DS je Jahr oder mehr.
Eine Frage habe ich jedoch noch.
Da Abfragen bei komplexen Berechnungen ziemlichen Arbeitsspeicher benötigen, wäre es aus meiner Logik heraus doch besser das Abfrage Ergebnis in eine neue Tabelle zuspeichern oder ?
Sind die Daten in einer neuen Tabelle bereits berechnet, muss nicht jeder weitere User der die Daten benötigt, diese nicht erneut berechnen lassen usw.
Was meine ich :
Die og Abfrage berechnet eben zb Felder wie QBM,LM,KG,Colli,PA,KA,RO immer wieder,
Man könnte sich 2 - 3 Abfragen sparen wenn man es einmal berechent und dann das Ergebnis in eine neue Tabelle speichert.
Ich nehme mal an das diese vorgehnsweise falsch ist oder ?
Lg Bernie
Zitat von: Bernie110 am Oktober 05, 2014, 11:43:02
Stellt sich die Frage wie hoch die Performance sein wird, wenn ca 50 User in 6 Niederlassungen damit arbeiten.
Ausgehen muss man von ca 200.000 DS je Jahr oder mehr.
Eine Frage habe ich jedoch noch.
Da Abfragen bei komplexen Berechnungen ziemlichen Arbeitsspeicher benötigen, wäre es aus meiner Logik heraus doch besser das Abfrage Ergebnis in eine neue Tabelle zuspeichern oder ?
Sind die Daten in einer neuen Tabelle bereits berechnet, muss nicht jeder weitere User der die Daten benötigt, diese nicht erneut berechnen lassen usw
Die Abfrage sieht ziemlich doll aus. Ob sie so gut geschrieben ist oder vereinfacht werden kann, habe ich nicht hinterfragt.
Die Berechnung der Unterabfragen braucht natürlich Hauptspeicher und auch Rechenzeit. Bei Benutzung einer Access-Datei als Backend über das Netz müssen dann außerdem vorher weitgehend alle Daten über das Netz transferiert werden und auf dem Client-PC verarbeitet werden. Das würde bei einer mittelgroßen Datenbank selbst bei schnellem Netzwerk unzumutbar für die Performance sein.
Zu Deiner Frage: Ja, es kann sinnvoll sein, Abfrageergebnisse materialisiert vorzuhalten. Datenbanksysteme haben dies als Feature. Es läuft im Idealfall auch transparent, d.h. das Datenbanksystem entscheidet im Hintergrund, ob es eine materialisierte Abfrage verwendet oder aus den Basistabellen neu errechnet.
Auf dem SQL-Server kann man anzeigen lassen, wie eine Abfrage abgearbeitet wird (Explain-Plan). Die Performance von Abfragen und wie man sie verbessert, ist eine durchaus nicht triviale Thematik, für die man jahrelang sich spezialisieren muß, um sie wirklich voll drauf zu haben.
Das ist dann aber kein Access-Thema mehr. Ich würde aus praktischen Gründen die Abfragen nur auf dem SQL-Server erstellen und optimieren und gegebenfalls Experten hinzuziehen. Gegenenfalls muß auch etwas am Datenmodell gemacht werden (teilweiser Verzicht auf Normalformen in den Tabellen). Im Access hingegen würde ich als Datenquelle für die Entwicklung der Formulare vorübergehend eine "Mock"-Tabelle erstellen, welche die Spalten der Abfrage hat.
Zitates hat keine wirkliche Auswirkung auf die Performance ?
Nun, es könnte schon sein, dass der Abfrageoptimierer wegen der Verknüpfungen teilweise zu einem anderen Ablaufplan kommt. Performance heißt ja verbrauchte Zeit. Wenn Du zwei funktionierende Varianten hast, kannst Du jene einfach messen.
ZitatIm Anschluss werden dann die Tabellen in einen SQL Server eingebunden.
Das als pure Maßnahme ist schlicht Unsinn, weil im Ergebnis Deine Abfragen dann langsamer laufen werden als bei einem Access-Backend. Erklärungen dazu entnimmst Du besser im Zusammenhang einem Buch wie ACCESS und SQL SERVER (http://shop.minhorst.com/buecher/281/access-und-sql-server).
Wenn Du doppelte Arbeit vermeiden willst, erstellst Du Deine Tabellen und die wesentlichen Abfragen gleich im SQL Server und Access ist dann für das Frontend zuständig.
Dann wird die Performance bestmöglich sein, weil der SQL Server (richtig angesprochen) nur noch Berechnungsergebnisse liefert und nicht zusätzlich umfangreiche Daten für notwendige Berechnungen.
In jedem Fall: Neben der Tabellenplanung (Datenmodellierung) sollte man auch gleich einen Blick auf die Indexplanung werfen, da gibt es laufend wiederholte Fehler, auch in Deiner DB.
Performance in Abfragen (http://www.donkarl.com/Downloads/AEK/AEK8_Abfragen_Performance.zip) von Michael Zimmermann
Zur SQL-Anweisung: Die ist nun etwas ganz anderes als die Zusammensetzung der Abfragen in der ersten DB.
So richtig analysieren kann und braucht man dieses "flächenhafte Gebilde" aber nicht. Mein Formatierer steigt da aus, so dass Logik (Tiefenschachtelung) nicht erkennbar ist. Die enthaltenen Abfragen müsste man zusätzlich ob des Inhalts nachschlagen.
Beim Überfliegen der Anweisung sieht man eigentlich nur JOIN's, und zwar allerhand. Da kann man, passende Schlüssel vorausgesetzt, nicht viel verkehrt machen als dass man zuviel macht.
ZitatIm Ufo lasse ich folgende Felder anzeigen.
Ich bin kein Freund von Breitwandmonitor-Formularen und entsprechenden Abfragen. Gerade Access bietet doch einfache Möglichkeiten, Formulare zu erstellen und diese zu verschachteln, so dass eine Datenbasis der Einzelformulare übersichtlich und weniger komplex sein muss.
Og, danke , das hilft mir schon mal weiter
Lg Bernie