Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   redundante Datenspeicherung (https://www.delphipraxis.net/128753-redundante-datenspeicherung.html)

globetrotter77 10. Feb 2009 11:49

Re: redundante Datenspeicherung
 
Zitat:

Zitat von Sir Rufo
Manchmal wird die Art der Speicherung auch durch die Arbeitsweise festgelegt ...

Ich betreue auch einen Einzelhandel und da ist bei der Auftragserstellung/Rechnung der Divers-Kunde sehr beliebt.

Eine Dummy-Kunden-Nummer, wenn der Kunde nicht dauerhaft gespeichert werden soll.

Also wird die Adresse einfach im Rechnungskopf gespeichert. Somit revisionssicher und auch Diverskunden-fähig.

Als weiterer Hinweis ist die Angabe der Lieferschnschrift, die sich ja auch von Auftrag zu Auftrag ändern kann (mal für die Omi, mal für wen auch immer). Auch hier werden diese Daten im Rechnungskopf gespeichert.

Weiterer Vorteil: Bei einer Revision werden nur die Tabellen Rechnungskopf und Positionen benötigt. Eine Verknüpfung mit den Adress-Bestönden entfällt.

Aber insgesamt bleibt es halt Geschmckssache ;)

cu

Oliver

Ich kenne fast ausschließlich Firmen, bei denen mit solchen Dummy-Daten gearbeitet wurde.
Das lässt sich auch nicht ausrotten und muss meiner Meinung nach auch zulässig bleiben.
Die Stammdaten sind für die Revision normalerweise völlig uninteressant, sondern dienen nur als Grundlage für die Neuerstellung von Datensätzen.
Die Prozessdaten dagegen müssen sämtliche prozessrelevanten Einstellungen beinhalten.
Und statt der Lieferanschrift kann übrigens auch mal ganz banal "wird abgeholt" drin stehen!
Das hat dann auch kein Gültigkeitsdatum, sondern ist nur für diesen einen Fall zutreffend.
Vor allem ändert man, wenn der Kunde am Telefon ausnahmsweise so etwas gewünscht hat, nicht gleich die Stammdaten ab.

Reinhard Kern 10. Feb 2009 12:10

Re: redundante Datenspeicherung
 
Zitat:

Zitat von Sir Rufo
Aber insgesamt bleibt es halt Geschmckssache ;)

Oliver

Hallo,

nicht nur, es geht auch um den Aufwand beim Programmieren und auch um die einfache Bedienung. Nach der reinen Theorie müsste man eine Tabelle führen für Versandkosten, weil die ja oft gleich sind, aber dann muss der User, wenn er mal was mit Kurier zustellt, erst in den Stammdaten die Versandkostenart Kurier neu erstellen, wozu er möglicherweise keine Berechtigung hat. Also kommen bei mir die Versandkosten einfach als Betrag in den Rechnungssatz, mögen die Theorie-Fanatiker noch so laut schreien. Die Standardwerte kann man ja durchaus aus einer Tabelle mit den wichtigsten Beträgen holen, aber nur als Hilfe beim Rechnungschreiben.

Ein weiterer verbreiteter Irrsinn: eine Alexanderstrasse könnte es ja in mehreren Städten geben, also muss die Strasse in eine extra Tabelle - und der User muss für die meisten Kunden erstmal eine neue Strasse anlegen.

Gruss Reinhard

globetrotter77 10. Feb 2009 12:21

Re: redundante Datenspeicherung
 
Zitat:

Zitat von Reinhard Kern
Ein weiterer verbreiteter Irrsinn: eine Alexanderstrasse könnte es ja in mehreren Städten geben, also muss die Strasse in eine extra Tabelle - und der User muss für die meisten Kunden erstmal eine neue Strasse anlegen.

Gruss Reinhard

Genau! Und für die Hausnummern legen wir auch gleich noch eine Tabelle an!
dto. für mögliche Vor- und Nachnamen ... *grins*

Blup 11. Feb 2009 09:28

Re: redundante Datenspeicherung
 
Zitat:

Zitat von globetrotter77
Zitat:

Zitat von Reinhard Kern
Ein weiterer verbreiteter Irrsinn: eine Alexanderstrasse könnte es ja in mehreren Städten geben, also muss die Strasse in eine extra Tabelle - und der User muss für die meisten Kunden erstmal eine neue Strasse anlegen.

Gruss Reinhard

Genau! Und für die Hausnummern legen wir auch gleich noch eine Tabelle an!
dto. für mögliche Vor- und Nachnamen ... *grins*

Da gibts nix zum grinsen. Bei einer automatischen Tourenplanung sind unter Umständen auch die Hausnummern deren Geoposition und auf welcher Straßenseite diese liegen wichtig. Die entsprechenden Daten kann man zu mindest für große Städte auch fertig kaufen.

Natürlich kann die Anwendung auch viele Sachen im Hintergrund erledigen. Zum Beispiel für einen Kunden "Diverse" die entsprechenden Rollen und Adressen anzulegen. Man muss sich nur entgültig von der Ansicht verabschieden, das die Benutzeroberfläche den Datenbankaufbau 1:1 wiederspiegelt.

Zu Tabellen für Vor- und Nachnahmen, wenn du eine Datenbank z.b. für eine Telefongesellschaft erstellst, wirst du genau das tun.
Bei einer Minianwendung die nur tausend Kunden speichert sicher nicht.
Speicherplatz ist Geld, insbesondere wenn man Kosten und Aufwand für Datensicherung und Wartung mit einbezieht.

Reinhard Kern 11. Feb 2009 13:14

Re: redundante Datenspeicherung
 
Zitat:

Zitat von Blup
Da gibts nix zum grinsen. Bei einer automatischen Tourenplanung sind unter Umständen auch die Hausnummern deren Geoposition und auf welcher Straßenseite diese liegen wichtig. ...

Hallo,

einfach falsch gelesen: wir machen uns nicht drüber lustig, für die Hausnummern ein eigenes FELD zu reservieren, sondern für diese eine TABELLE anzulegen. Den Unterschied zu erläutern würde aber hier zu weit führen.

Gruss Reinhard

globetrotter77 11. Feb 2009 20:05

Re: redundante Datenspeicherung
 
Zitat:

Zitat von Reinhard Kern
einfach falsch gelesen: wir machen uns nicht drüber lustig, für die Hausnummern ein eigenes FELD zu reservieren, sondern für diese eine TABELLE anzulegen. Den Unterschied zu erläutern würde aber hier zu weit führen.

Gruss Reinhard

Genau so meinte ich das auch!
Ich habe es auch schon erlebt, dass jemand eine Tabelle anlegen wollte mit genau einem Feld, das jeweils einen Buchstaben, aber eben nur in z.B. 7 Ausprägungen annehmen durfte. Da platzt mir dann schon die Hutschnur!


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:38 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz