Tabelle mit vielen Feldern?

[DahnSwiss]

Guten Abend zusammen

Erst mal vielen Dank für die Beiträge, die mir täglich helfen, die kleinen oder grösseren Probleme zu lösen.

Meine Frage:
Ich bin am Datenstamm (Werkstattsoftware) und habe viele Felder die zu einem Fahrzeug gehören. Soll ich diese in verschiedene Tabellen verteilen, oder die Stammgrundlagen des Fahrzeuges alle in der gleichen Tabelle einbinden?

Was ist besser, viele Tabellen oder ein mit allen Daten zum Fahrzeug (mind. 80-130 Felder zugehörig zum Fahrzeug, wie Länge, Breite, Hubraum, Versicherung, Gewichte usw.)

[DF6GL]

Hallo,

besser ist ein "Zwischending". Stichwort lautet "Normalisierung" , sieh dazu u. st. Liks 1, 1a und 1b

In die Fahrzeugtabelle gehören alle Felder, die ein bestimmtes Fahrzeug in Gänze beschreiben (Attribute)

Manche dieser Felder stellen nur einen Wert dar, z. B. Länge oder Breite.

Andere Felder enthalten einen Verweis ( Fremdschlüssel ) auf eine "Nachschlagetabelle", die alle möglichen , aber genau definierten Werte zur Verfügung stellt und aus denen der benötigte Wert für das Fz ausgewählt wird.  (--> siehe Normalisierung).

Diese Normalisierung der Daten und Aufteilung in Tabellen mit ref. Beziehungen muss als Erstes durchgeführt werden.

[PhilS]

Was ist besser, viele Tabellen oder ein mit allen Daten zum Fahrzeug (mind. 80-130 Felder zugehörig zum Fahrzeug, wie Länge, Breite, Hubraum, Versicherung, Gewichte usw.)

Franz' Antwort dazu ist völlig korrekt, aber auch sehr abstrakt. Daher möchte ich das ein wenig konkretisieren.

Ich würde die Daten aufteilen in

• zwei Haupttabellen
  
  
  
  • Model - Daten die für alle Fahrzeuge eines Modells gleich sind (Hersteller, Marke, Modell, Abmessungen, Motorisierung, etc.) - (Letztendlich ist das auch nur eine besondere Nachschlagetabelle.)
    
  • Fahrzeug - Individuelle FZG-Daten (Fahrgestellnummer, Kennzeichen, FZG-Halter, Erstzulassung, Versicherung, etc.) - FZG-Halter wäre wahrscheinlich eine weitere Tabelle mit allen Personen-Addressdaten.
• zahlreiche Nachschlagetabellen die in den beiden anderen Tabellen referenziert werden. Z.B. für Versicherung, Hersteller, Marke, Modell, Motor, etc.)

[/list]

[Beaker s.a.]

@Regulars
Alles richtig was ihr sagt. Aber den Begriff "Nachschlagetabellen" würde ich bei einem
Anfänger, der noch mit dem Aufbau des DM beschäftigt ist nicht verwenden. Ich meine,
der Begriff ist ja nicht falsch, aber der TS verwendet das dann in den Haupttabellen als
Nachschlagefelder, die wir ihm dann wieder "um die Ohren hauen".
Das sind doch Tabellen, die einen Wertevorrat zur Verfügung stellen; - gibt es dafür nicht
einen besseren Begriff?
gruss ekkehard

[DF6GL]

Hallo,

na denn:  Wertevorrattabelle     

oder "Prüflistentabelle"

Manchmal hört man auch "Stammtabelle", allerdings versteh ich darunter etwas anderes.


Normalerweise sollte man auch als Anfängern zwischen einer "Tabelle" und einem "Feld" unterscheiden können, sofern man auch richtig liest...

[Beaker s.a.]

Hallo Franz,

sofern man auch richtig liest...

Schon richtig, aber wenn er dann im Tabellenentwurf das
Register "Nachschlagen" entdeckt, ist das doch schnell mal
assoziiert.
gruss ekkehard

[DahnSwiss]

Guten Abend zusammen

Danke für Eure Tip's

Wie ich das schon vermutet habe, ist es des "Erbauers" Grundkonzept, welches er selber für sich entscheiden muss oder soll. Habe mich nun entschieden, die Daten in der Grundtabelle zu belassen. Jeweils in "Verbund" mit einer Definitionstabelle

Unsere Branche hat eben viele Details, die bei einem Fahrzeug als wichtig und abrufbar sind. Sie sollen auch vor der Reparatur vom Fahrzeug die nötigsten Daten aufzeigen. Bsp: Fahrer ruft an, hat Schaden an "Etwas" und man kann schon vor Eintreffen vom Fahrzeug reagieren, oder Dinge organisieren für die Reparatur. (Im Transportwesen zählt jede Minute, welche das Fahrzeug steht)

Eigentlich besteht schon eine Version dieser Software (läuft nun schon etwa 1 Jahr aktiv), aber irgendwie steht man dann plötzlich in der Struktur an, und muss sich die ganze Datenstruktur überdenken. Und das tue ich zur Zeit mit einer Neuvariante. (Man braucht ja immer ein Ziel vor Augen  )

Wenn's Interessiert, werde in nächstem Anhang ein paar Sreenshot's erstellen

Vorerst mal vielen Dank für Eure Hinweise, man lernt immer gerne wieder nNeues und neue Gedankengänge dazu. Bin eigentlich aber immer noch ein Frischling in Access 

[Lachtaube]

Auf mich wirken die gezeigten Daten statisch. Werden denn keine Handlungen am Fahrzeug von euch auf Grund von Serviceverträgen (z.B. Winter-/Sommerreifenwechsel und ggf. Einlagerung), Reparaturen, etc. erfasst?

PS: In eine individuelle Fahrzeugtabelle gehören, wie das Phil auch schon vorschlug, IMO nur vom Standard abweichende (Aufbauten, etc.) bzw. individuelle (Seriennummern, Baujahr, Farblackierung, etc.) Attribute, die nicht jeder Fahrzeugtyp einer Marke aufweist. Bei gleichen Fahrzeugtypen müsstst Du ja einen bestimmten Sermon immer wieder neu herunterbeten.

[Beaker s.a.]

Und wozu braucht man 5 Tabellen für Adressen?

[Lachtaube]

@Ekkehard,

das ist eine Adresstabelle, die 5x in Beziehung steht.

[Beaker s.a.]

Grrr, alles klar, an  die automatische Nummerierung hatte ich nicht gedacht.

[DahnSwiss]

@Lachtaube

Das war nur die Grundtabelle vom Fahrzeug.

Das "Ganze" wird schon Dynamisch 

[DahnSwiss]

Guten Abend zusammen

Langsam nimmt das "Ding" Gestalt an und läuft schon recht gut.

Nun bin ich an Feiertags-Management, damit man an keinem Feiertag einen Termin eingibt. Dazu habe ich nun zusätzlich ein Tabelle mit den Feiertagen. Nun müsste ich nur noch raustüfteln, wie ich die Gültigkeitsregel in Bezug dieser Tabelle zusammenhänge, damit ein Mendung auftritt, wenn man einen Feiertag erwischt.

Ist aber noch nicht Priorität, Jetzt sind z.Z. alle Formulare in Arbeit und die dazugehörigen Eingabehilfen, damit das Ganze schnell und effizent bearbeitet werden kann. Ein Mechaniker hat nicht viel Zeit für Computer-Eingaben, sondern muss FZ reparieren