Office: (Office 2010) Aufbau von KundenDB

Liegenschaft ist klar, schließlich kann ja ein Kunde viele Grundstücke haben.

Wo aber jetzt (aus der Sicht eines Maschinenverleihs) der Unterschied zwischen einer Firma, einem Privatier und einer Behörde liegt, erschließt sich mir nicht.
Der zentrale Punkt ist doch, daß die alle eine Adresse haben, an die die Rechnung geschickt wird. Was steht noch in der Tabelle?
Die Ansprechpartner (Hausmeister, Sachbearbeiter usw.) stehen doch in einer separaten Tabelle.

 

Der Unterschied ist einfach das ich viel verschiedene Felder habe.
bei der Verwaltung oder bei der Firma muss ich zum Beispiel eventuell noch eine Rechnungsadresse oder eine MWST Nummer haben, die ich beim
Privatkunden nicht habe.

Wenn ich eine Tabelle mache die für alle verschiedenen Kunden geht dann haben ich sehr viele Felder. Und das wollte ich vermeiden?
Sind meine Überlegungen falsch?

 

Die Überlegungen sind nicht falsch, sondern nur nicht zu Ende gedacht.

Für die Übersichtlichkeit der Daten gibt es doch die Abfragemöglichkeiten. Hier kannst du dir doch nur die Felder auswählen, die du sehen möchtest.

Also z.B. nur die alllgemeinen Felder für Privatkunden und die dazu speziellen.

oder die allgemeinen Felder für Verwaltung und die dazu speziellen.

usw. usw.

Also für die Verwaltung sieht die Abfrage vielleicht so aus:
Rechnungsadresse; MWSt-Nummer; und weitere benötigte Felder

Für die Privatkunden könnte die Abfrage folgende Felder beinhalten:
Name, Vorname, Str. Plz, Ort, und weitere benötigte Felder.

Was meinst du? Wäre das ein Lösungsweg für dich?

mfg
Roland

 

Das ist ein guter Lösungsweg. Den hab ich mir auch schon überlegt.

Was mache ich aber wenn eine Verwaltung mehrere Rechnungsadressen
hat und auch mehrer Ansprechpartner...?!

Wäre das Sinnvoll wenn ich eine KundenTabelle habe mit allen Feldern und
dann noch eine Tabelle für Ansprechpartner, Rechnungsadresse, Eigentümer... usw?

An dieser Stelle habe ich mühe...oder ich denke langsam ich habe einfach
einen Knoten *Smilie *frown.gif*

 

Auch das ist über Abfragen lösbar.

mfg
Roland

 

Hallo,
an der Stelle möchte ich noch mal auf meinen Beitrag #17 hinweisen. Das scheint mir untergegangen zu sein.
Hier sollten 1:1 Bezeihungen verwendet werden. Damit lassen sich zu einer Haupttabelle in weiteren Tabellen die speziellen Felder anlegen.
Das ist ein Fall bei dem die seltenen 1:1 Beziehungen sinnvoll sind.

Code:

Und das wären n:m Beziehungen mit Zwischentabellen, aber auch das hatten wir schon mal.

 

Tja, ich würd' mal zusammenschreiben, was ich wirklich brauche.
Die MwSt-Identnummer, die gibt's nur bei Firmen und bleibt bei Privatkunden eben leer. Abgesehen davon, daß diese Identnummer eigentlich nur wichtig ist, wenn Du auf die Berechnung der MwSt. verzichtest, weil die Ware exportiert wird.
Außerdem hat ein Privatkunde einen Vornamen und eine Firma nicht, na und? Bleibt der Vorname eben leer.
Normalisierung bedeutet nicht, daß in jeder Tabelle jedes Feld immer gefüllt sein muß.
Sollte es wirklich Kunden geben, bei denen es mehrere RECHNUNGSadressen gibt? Ich versuch' mich zu erinnern, ob mir so etwas schon mal vorgekommen ist bei einem Datenbestand von gut 120 Tsd. Kunden.

Edit:
Die große Zahl ist ein untaugliches Argument. Es gibt aber ein gutes: eine Firma hat einen Firmensitz und da geht die Rechnung hin. Sollte doch mal die Rechnungsverwaltung nicht im Firmensitz stattfinden, dann ist das eben eine Adresse in der Tabelle "Ansprechpartner".

 

Hallo.

Ich kann CptChaos nur unterstützen. Kunden/Personen spezifische Daten gehören in seperate Tabellen. Die Hauptatbelle (1*Smilie bildet den kleinsten gemeinsamen Nenner. Die Detailtabelle liefert die spezifisch relevanten Daten zu einer Person.

Wenn ein Geburtsdatum bei einer Privatperson nicht gefüllt ist, weil ich keines habe, gebe ich Dir Recht. Aber wenn ich ich ein Feld "Handelsregisternummer" nicht befüllen kann. weil es für eine Privatperson eine solche nicht gibt, dann denke ich sehr wohl an das Thema Normalisierung. Weitere Feldbeispiele erforderlich?

 

\@Sascha

Bist Du sicher, dass Du CptChaos meinst? *grins

 

Hi,
ist mir noch nicht vorgekommen.

Aber eine abweichende oder auch mehrere abweichende Auslieferungsadressen.

mfg
Roland

 

Gegenfrage: ist es ausgeschlossen? *Smilie

Andererseits: die Rechnungsadresse wirst du ja nur für die nächste Rechnung brauchen. Selbst wenn ein Kunde jedesmal die Rechnung woanders hin haben will, wäre das mit der Änderung der einen Rechnungsadresse machbar.

 

Hallo,

Das würde aber bedeuten, dass man immer die komplette Rechnungsanschrift in der Rechnungstabelle führen muss.

 

Hallo Klaus,

ist das denn nicht immer bei abweichenden Adressen der Fall?

mfg
Roland

 

Hallo,

Nein, eigentlich nicht. Wenn ich die Rechnungsanschriften in einer separaten Tabelle erfasse mit einer 1:n Beziehung habe ich nur einen Bezug (Schlüsselfeld) zur Rechnungsadresse. Das heist, ich wähle aus einem Kombi die passende Adresse aus und speichere das entsprechende Schlüsselfeld.

 

Entweder das, oder man speichert nur um "Finanzdaten" der Rechnung.

Die historischen Rechnungsadressen braucht kein Mensch. Eine alte Rechnung sollte zwar mit ihren "Finanzdaten" (Mengen, Preise, Datumswerte etc) in der Datenbank bleiben, aber z.B. die Rechnungsadresse von damals wird nicht mehr gebraucht. Denn: ein evtl. nötiger Nachdruck der Rechnung sollte nicht durch ein "Neuaufbauen" der Rechnung geschehen, wie sie damals hätte aussehen müssen, sondern durch Ausdruck eines damals erzeugten PDF oder eines ähnlich schwer änderbaren Formats.

Es schadet aber nicht, die Adressen mitzuspeichern.