Variable Datensatzherkunft

[Joe0301]

Halli Hallo,

Ich wollte mal eben nachhacken ob mein vorhaben so möglich ist, oder ob ich anders an die Sache herangehen muss.

Ich habe 6 Tabellen die identisch sind.    TabelleA TabelleB usw.
Und eine weitere TabelleZuordnung.
Meine Abfrage Ordnet jeh nach Übereinstimmung eines wertes Tabelle A weitere Neue Spalten zu.
Ich habe eine Globale Variable, die A,B usw speichert.
Nun möchte ich irgendwie der Abfrage sagen Wenn B gespeichert ist Tabelle B mit der Zuordnung zu erweitern.
Wie mach ich das ? Also wie gestallte ich die Datensatzherkunft variabel ?
Die Abfrage dient als Grundlage für einen Bericht.

Schonmal Vielen Dank im Vorraus.
MfG
Joe0301

PS: Die Abfrage ordnet die Spalten aus TabelleZuordnung zu

[Beaker s.a.]

Hallo Joe,
Sorry, völlig unverständlich, aber

Ich habe 6 Tabellen die identisch sind.    TabelleA TabelleB usw.

ist schon mal verdächtig.
Poste doch erstmal ein Bild des Beziehungsfensters (alle Tabellen mit allen Feldern
müssen sichtbar sein). Dann sehen wir weiter.
gruss ekkehard

[MzKlMu]

Hallo,

Ich habe 6 Tabellen die identisch sind. 

Das würde ich nicht als verdächtig bezeichnen, sondern als falsch.

Das gehört alles in eine Tabelle mit einem Kennzeichen zur Unterscheidung der 6 Fälle (oder was auch immer das Unterscheidungsmerkmal ist.).

Die ganzen Fragen lösen sich dann in Luft auf.

Daher erst mal die Frage:
Wieso sind das 6 identische Tabellen ?

[Joe0301]

Hallo Beaker s.a.

Leider handelt es sich um Sensible Daten und ein umschreiben der Namen wäre zu aufwendig bei der Größe der Datenbank.

mit identisch meinte ich den aufbau der Tabellen, der Inhalt unterscheidet sich.
Ich erkläre es mal anhand eines Beispiels.

Ich habe 6 Autos vom gleichen Typ sagen wir Audi A4
Nur hat jedes Auto eine andere Ausstattung, darin unterscheiden sich die Tabellen von Inhalt manches ist ähnlich manches nicht.

Ob ich Auto1 oder Auto 5 habe muss am anfang ausgewählt und gespeichert werden.

Jedes Ausstattungsteil hat seine eigene Nummer (Bauteilnr)
in der TabelleZuordnung stehen unter der Bauteilnr weiterführende indormationen.

meine abfrage sucht sich nun die Daten aus TabelleAuto(Nr.) und fügt die weiterführenden Informationen aus der TabelleZuordnung hinzu.
Das funktioniert auch alles einwandfrei.
(Abfrage ist mit TabelleZuordnung in einer Beziehung über die Bauteilnr.)

Nun möchte ich Der Abfrage nur irgendwie mitteilen können das ich Auto5 habe und somit TabelleAuto(5)
verwendet werden soll und nicht TabellAuto(1). Die datensatzherkunft der Abfrage ist erstmal nur AutoTabelle(1)
Die möchte ich falls ein Auto 7 hinzukommt gerne flexibel gestallten.

Ich hoffe es ist nun verstänldich wie das ganze ablaufen soll.

(Die Abfrage ist für ein Bericht in dem Die Ausstattung aufgezeigt wird und die Weiterführenden Daten wie Beispielsweise Aufpreis für dieses Bauteil)

MzKIMu
Ja dieses verfahren ist mir bekannt und anfangs auch so gedacht gewesen, Ich würde die Tabellen Aufgrund der Menge der Datensätze (etwa 4000) die mittlerweile entstanden sind gerne Aufteilen um auch den Rechenaufwand möglichst klein zuhalten.


MfG
Joe0301

[MzKlMu]

Hallo,
Du kannst es drehen und wenden wie Du willst. Die 6 Tabellen sind falsch.

Ich habe 6 Autos vom gleichen Typ sagen wir Audi A4

Und, wo ist das Problem ? Die Daten kommen in eine Tabelle mit einem Feld für den Autotyp (AudiA4, AudiA6 ...)

Ich würde die Tabellen Aufgrund der Menge der Datensätze (etwa 4000) die mittlerweile entstanden sind gerne Aufteilen um auch den Rechenaufwand möglichst klein zuhalten.

Genau das Gegenteil ist der Fall, durch einen normalisierten Aufbau der Tabelle wird sich die Rechenzeit eher verringern. Du hast eine falsche Vorstellung von einer Datenbank. Und 4000 Datensätze sind ein Klacks für Access, das sind Kinkerlitzchen, beim 100fachen beginnen große Datenmangen. Und ob Du 6x4000 DS hast oder 24000 ändert absolut nicht an der Datenmenge. Und wahrscheinlich sind bei Deinem Datenmodell auch noch Unionabfragen notwendig, welche die Rechenzeit drastisch verschlechtert.

Mit einer Tabelle für die 6 Arten und einem Kennzeichen für die Art wirst Du die jetzigen Probleme gar nicht mehr haben.

Die möchte ich falls ein Auto 7 hinzukommt gerne flexibel gestallten.

Das wird dann Dein größtes Problem, hast Du Dir schon mal überlegt, was Du dann alles ändern musst ?
Bei einem normalisierten Aufbau (eine Tabelle) ist das nur das Hinzufügen eines Datensatzes, fertig.

Bau die DB um, alles andere ist eine Sackgasse.

Nachtrag (auf Grund der Antwort von ekkehard, war mir vorher nicht aufgefallen):

und ein umschreiben der Namen wäre zu aufwendig

Wenn die Feldnamen selbst schon sensibel sind, stimmt das Datenmodell sowieso nicht. Wenn es (beispielhaft) Felder für das Gehalt gibt (was ja sensibel ist), die das Gehalt kennzeichnen (also 3000, 4000 jeweils als Feldname) dann wäre das sensibel. Wenn es aber nur ein Feld gibt das Gehalt heißt, ist daran nichts mehr sensibel.
Mit anderen Worten, in einer (korrekt aufgebauten) Datenbank kann man im Regelfall nicht von den Feldnamen auf deren Inhalt (den eigentlichen Wert) schließen. Man kennt nur die Bedeutung.

[Beaker s.a.]

Hallo Joe,

Leider handelt es sich um Sensible Daten und ein umschreiben der Namen wäre zu aufwendig bei der Größe der Datenbank.

Daten wollen wir auch gar nicht sehen, nur die "Überschriften" (Feldnamen).
Ansonsten wie vermutet, falsches Datenmodell, - siehe Klaus' Antwort(en).
gruss ekkehard

[MzKlMu]

Hallo,
ich habe oben in #4 noch einen Nachtrag gemacht, Hinweis nur damit Du (Joe) nichts überliest.

[crystal]

Lieber Joe,

natürlich haben die anderen prinzipiell Recht! Eine Revision des Datenmodells wäre sicher ein sehr guter Ansatz, dein Problem zu lösen.

Aber ich akzeptiere, dass du mit einer gewachsenen Struktur (zunächst) weiter arbeiten willst oder musst.

Daher:
Wenn du A, B usw. schon speicherst und kennst, dann brauchst du doch eigentlich deiner Abfrage nur etwas Code "vorzuschalten", etwa so:

select case Typ
  case A:
    strAbfrage = "Select ... from TabelleA where ..."
  case B:
    strAbfrage = "Select ... from TabelleB where ..."
  case C:
    strAbfrage = "Select ... from TabelleC where ..."
...
end select
<Abfrage ausführen mit strAbfrage>

Sorry - aber ihr wisst ja, dass ich Pragmatiker bin.

Vielleicht hilft dir diese Idee, dein Dilemma zumindest kurzfristig zu lösen. Eine Re-Organisation der DB wäre dann ein nächster Schritt, der aber ohne Zeitdruck erfolgen könnte.

lg
crystal

"Vielleicht führen nicht alle Wege nach Rom, aber mehr als einer ist es gewiss." [Unbekannter Autor, vielleicht Heisenberg oder Watson, oder Darwin oder Marie Curie, Ford, Chaplin, Willy Brandt, Olivia (Freundin von Popeye)]

[MzKlMu]

Hallo,
@Cristal
Du unterläufst gerade den Versuch die DB (die sich der Anzahl seiner Beiträge noch im Aufbau befindet) noch rechtzeitig in geordnete Bahnen zu bringen. Das wird später immer mehr Arbeit. Und ob solche pragmatischen Ansätze wirklich helfen darf auch bezweifelt werden. Zumindest im Anfangsstadium der DB.

Und wenn man der Meinung ist, man müsste wegen 4000 DS aus Performancegründen die DB auf 6 Tabellen aufteilen, so ist man damit ganz sicher auf dem Holzweg. Denn ursprünglich war es ja mal eine Tabelle. Das Aufteilen führt genau zum Gegenteil.

Ja dieses verfahren ist mir bekannt und anfangs auch so gedacht gewesen, Ich würde die Tabellen Aufgrund der Menge der Datensätze (etwa 4000) die mittlerweile entstanden sind gerne Aufteilen um auch den Rechenaufwand möglichst klein zuhalten.

Aber ich sage da jetzt nichts mehr dazu. Jeder ist seines Glückes Schmied.

[crystal]

<ot>
Lieber Klaus,

ich habe ja durchaus deutlich gesagt, dass eine Revision der DB eine sehr zu empfehlende Maßnahme ist.
Ich verstehe aber auch die Situation, dass ein Entwickler, der sich die "5 Sterne der Normalisierung" noch nicht verdient hat, vor einem Problem steht, dass er so schnell und einfach wie möglich lösen möchte. So kommen dann meine pragmatischen Ideen zustande.

Ich möchte mit solchen Ideen nicht die berechtigte Kritik (z.B. von dir) wegwischen, sondern dem Fragesteller eine schnelle Lösung anbieten, ohne jedoch darauf zu verzichten, diese berechtigte Kritik unberücksichtigt zu lassen.

Mein Motto wäre also etwa so: erstmal schnelle Hilfe und dann intensives Nachdenken und strukurelle Änderungen. Wenn ich mit dem Auto wegen eines platten Reifens liegen bleibe, will ich ja auch erstmal ein neues Rad, um weiter zu kommen und nicht lange Diskussionen über die Notwendigkeit eines Ersatzrades.

lg
crystal
</ot>

[Beaker s.a.]

Hallo,

erstmal schnelle Hilfe und dann intensives Nachdenken

Auf lange Sicht ist es anders herum schneller.
gruss ekkehard

[ebs17]

Beim Nachdenken (an intensiv möchte ich mich gar nicht vergreifen) sollte man auch berücksichtigen, dass man in einer einigermaßen funktionierenden Datenbanklösung nicht nur Daten innerhalb eines Autotyps (einer der bisherigen Tabellen) anschauen und auswerten wird, sondern ganz schnell auch Betrachtungen über alle Autos, auch die neu hinzukommenden, führen werden muss.

Mit einer Tabelle sind ein paar neu hinzukommende Daten überhaupt kein Problem und somit das Pragmatische an sich.
Wer wegen ein paar zusätzlichen Daten an eine Umprogrammierung denken muss, sitzt auf einem sinkenden Schiff. Die Zeitfrage stellt sich dann ganz anders.

Wer Angst vor ein paar mehr Daten hat, die dann die Performance einbrechen lassen könnten, ist dann ein Kandidat, sich neben der Bedienung von einigen Accessfunktionen und -assistenten dann auch mal richtig mit Datenbank und Datenbankmanagement mit SQL zu beschäftigen.

Als Beispiel: Mehr Daten heißt mehr Arbeit damit und somit ein höherer Zeitbedarf. Klingt soweit logisch. Da aber Datenbanken typischerweise potentiell mit sehr vielen Daten und das performant umgehen müssen, hat man sich schon vor langer Zeit etwas einfallen lassen: Einen Index. In einer Accesstabelle kann man übrigens bis 32 Indizes definieren. Was bringt das?

Extremeres Beispiel: Performance total mies
Allgemein: Grundlagen - SQL ist leicht ( - Index

[crystal]

Hallo,

Eberhard, mit deiner komplizierten Antwort willst du also letztlich nur mitteilen, dass ein Index über eine Tabelle kein Problem ist, aber über mehrere Tabellen eben nicht funktioniert. Gut.

Wir wissen leider nicht, was genau den TS veranlasst hat, die ursprüngliche Tabelle zu vervielfältigen. Allein die Anzahl der DS ist für mich keine ausreichende Begründung, ich vermute eher andere Gründe (organisatorische Veränderungen, Erweiterung der Tabelle um zusätzliche Felder, Status-Updates etc.).

Vielleicht müssen wir abwarten, was der TS dazu noch mitteilt.

Ansonsten könnte man ihm ja auch Hilfe dazu bieten, die jetzt 6 Tabellen in einer zusammenzufassen. Das Access kein Problem damit hat, 4.000 oder 24.000 DS zu handeln (natürlich mit Indizes gemäß Eberhard), ist für Access-Nutzer sicher einsichtig, wenn sie über etwas Erfahrung verfügen.

Wenn aber ein Nutzer schon bei der ersten Tabelle, die nach seiner Meinung "zu langsam" wurde, den falschen Weg der Duplizierung gegangen ist, stellt sich doch die Frage, ob man ihm nicht zunächst mit Pragmatismus helfen sollte, um ihm dann die Möglichkeit zu geben, (ich wiederhole mich) intensiv nachzudenken - oder nicht.

Es nutzt dem Fragesteller nichts in seiner aktuellen Situation, ihm zu sagen, dass sein Datenmodell und sein Verständnis von Datenbanken (insbesondere Indizes) völlig unzureichend ist, ohne ihm einen pragmatischen Ausweg zu zeigen, der nicht viel Aufwand bedeutet UND ihm die MÖGLICHKEIT gibt, seine Anwendung zu überarbeiten (und dies parallel zur alten Version, die ja täglich benutzt wird).

Das war meine Intention für meine (in manchen Augen primitive oder lächerliche oder gar sträfliche) Lösung.

Gebt doch dem Fragesteller etwas Zeit, die Erfordernisse einer Datenbank-Anwendung zu verstehen, bevor ihr seine bisherige Arbeit "in die Tonne kippen" wollt. Vielleicht wisst ihr manchmal nicht mehr, wie viel "Herzblut" in einer Anwendung steckt, die ein Laie erstellt hat, ohne etwas von Datenmodellierung und Normalisierung oder nur von Indizes gewusst zu haben. Es gilt, diese Arbeit zu respektieren und den Entwickler langsam (und bestimmt) auf den "Pfad der Tugend" zu bringen - nur bitte nicht mit der Holzhammer-Methode.

Im Übrigen denke ich, dass das Beispiel mit Audi und gewissen Zubehörteilen nicht unbedingt der realen Situation entspricht, weil das nicht zwingend sensible Daten wären. Vielleicht hat der Fragesteller hier ein nicht ganz passendes Beispiel gewählt.

Wenn man aber "Audi" durch "Strafgefangener" und "Zubehörteile" durch "persönliche Habe" ersetzt, wäre die Sensibilität der Daten schon deutlich evidenter.

Gleichviel - wir sollten abwarten, welche Informationen der Fragesteller noch liefern kann, ohne Gefahr zu laufen, Geheimnisse oder Interna preiszugeben.

Bis dann also und

lg
crystal

[ebs17]

einen pragmatischen Ausweg zu zeigen, der nicht viel Aufwand bedeutet

Alle Datensätze dieser Tabellen in eine Tabelle schreiben (bspw. einmalig über Anfügeabfragen) und ein zusätzliches Feld über die Zuordnung (bisher Tabellenherkunft) anlegen. Mehr ist es nicht.

Mit einer Tabelle entfällt dann die Programmierung zu den wechselnden Datenherkünften, in Summe also kein Aufwand. Zusätzliche positive Effekte, an die noch keiner denkt, ergeben sich automatisch.

bevor ihr seine bisherige Arbeit "in die Tonne kippen" wollt. Vielleicht wisst ihr manchmal nicht mehr, wie viel "Herzblut" in einer Anwendung steckt, die ein Laie erstellt hat

Wenn einfach weiterprogrammiert wird, also der Umfang wächst, und dann doch festgestellt wird, das man in eine Sackgasse geraten ist: Dann fließt mindestens das gleiche Herzblut, und Zeit (=Geld) braucht man noch viell viel mehr.
Sonstiges - Es war einmal eine kleine Exceltabelle ...

mit deiner komplizierten Antwort

Was ist da zu kompliziert für Dich?
Sowie: Versuche Dir mal vorzustellen, dass Du nicht für den gesamten Rest der Welt sprichst, Deine Wertungen also bestenfalls individuell persönlich, aber nicht allgemeingültig sind.

[crystal]

<ot>
Lieber, sehr geehrter Eberhard,

Was ist da zu kompliziert für Dich?
Sowie: Versuche Dir mal vorzustellen, dass Du nicht für den gesamten Rest der Welt sprichst, Deine Wertungen also bestenfalls individuell persönlich, aber nicht allgemeingültig sind.

Nie habe ich behauptet, die "Wahrheit gepachtet" zu haben, im Gegenteil habe ich meinen Antworten oft "Bitte abwarten, was andere dazu meinen" oder ähnliches zugefügt.

Und: wolltest du nicht auf persönliche und polemische Kritik gegen mich zugunsten einer sachlichen Stellungnahme verzichten? Schade, dass man deinem Wort so wenig vertrauen kann. Ich habe mich jedenfalls daran gehalten und einige deiner xyz Antworten nicht kommentiert. Was xyz dabei bedeutet, kannst du dir selbst zusammenreimen.

Lg
crystal

PS: Ansonsten bitte ich dich, deine Kritik per PN an mich zu senden, dann können wir gerne lebhaft darüber diskutieren.
</ot>