Hallo Harald,
Post by Peter GötzHallo Dragan,
Post by D. GottschaldtOK, grundsätzlich magst Du ja recht haben, aber man muß akzeptieren, daß
es ab und zu mal Anforderungen abseits der reinen Lehre gibt, die es
notwendig machen, eine nicht optimale Lösung zu wählen. So z. B. bei den
im Eingangspost beschriebenen Beispiel. Aus Deiner eigenen Erfahrung
wirst Du bestimmt auch Pflichtenhefte kennen, bei denen man sich an den
Kopf greifen muß, den Kunden aber schlichtweg nicht von der Unsinnigkeit
einer solchen Vorgehensweise überzeugen kann, selbst wenn man mit einer
mehrköpfigen Beratermannschaft aufläuft.
Mir ist sowas in der Art auch schon des öfteren begegnet. Meistens blieb es
dabei nicht bei einem einzigen derartigen Klops, so dass ich denn auch
meistens solche Aufträge gar nicht erst weiter- bzw. ausgeführt habe - mit
solchen Kunden gibt es in der Regel im Projektverlauf zu viel Ärger.
Klar, ist manchmal auch sinnvoller, aber andererseits bin ich so dermaßen
käuflich :-)
Im Ernst: bei Aufträgen im 6- oder zumindest mitleren 5-stelligen Bereich
(leider nicht an der Tagesordnung) überlegt man sich schon sehr genau, ob
man dem Kunden dann eben nicht seinen Willen läßt. Es läßt sich ja
schriftlich fixieren, was man rät und welche Lösung der Kunde letztendlich
durchsetzt - mit den Konsequenzen, die sich daraus ergeben. Siehe es mal
positiv: damit generiert der Kunde selbst für Leute wie uns Folgeaufträge,
indem er uns später Sachen korrigieren läßt, vor denen man ihn vorher schon
ehrlicherweise gewarnt hat.
Post by Peter GötzPost by D. GottschaldtAls Beispiel, welches in diesem speziellen Fall wohl nicht relevant ist,
sei nur genannt, wenn man Datensätze im eigenen Programm erzeugt, und
diese in ein Fremdsystem exportieren muß, welches eben nicht mit GUIDs,
sondern z. B. (alpha-)numerischen IDs arbeitet.
Wo ist das grundsätzliche Problem, auch dort GUIDs weiterzuverwenden? In
Stringform sind sie alphanumerisch, und nach wie vor eindeutig. Numerisch
sind sie ja schon per se.
OK, und jetzt nimm mal einen Fall an, wo die ID 7-, 8- oder 10-stellig sein
muß und schon ist es vorbei mit den guten Vorsätzen. Oder der noch
schlimmere Fall, wenn bereits eine gewisse Systematik existiert, mit der IDs
gebildet werden. Ganz zu schweigen von Uraltsystemen, die etwa auf AS400
laufen und schon vor 20 Jahren konzipiert wurden. Zwar werden j auch diese
in der Regel kontinuierlich weiterentwickelt und modernisiert, aber die
wenigsten greifen dabei auch die ID-Thematik auf. Dazu kommen noch die
Fälle, in denen Software von den Betrieben selbst konfiguriert und teilweise
umprogrammiert wird (bei manchen mühelos möglich) und IDs nach Kriterien
gebildet werden, die den Erfordernissen des Betriebs entsprechen (oder halt
auch zufällig entstehen) und sich nicht nach professionellen
Programmierrichtlinien ausrichten.
Post by Peter GötzSollte aber ein anderes System ein spezifisches ID-Format erwarten, ist
dieses entweder bekannt, so dass man tatsächlich einen dafür passenden
Generator bauen kann (und evtl. muss, falls das importierende System kein
API dafür anbietet). Oder mögliche Formate sind noch nicht
vorausschaubar -
aber dann kann jede Wahl eines Formats später genau die falsche gewesen
sein.
Eben. Und meine Funktion ist halt nichts anderes als ein solchen
ID-Generator. Nicht elegant, aber sie hat bisher ihren Zweck erfüllt.
Wegen diverser Gründe mache ich Anbindungen von Fremdsystemen fast
ausschließlich über die Datenbank und seltenst über bereitgestellte
Schnittstellen. Gerade das ist bei vielen der Knackpunkt: Für die Zwecke,
die zumindest meine Kunden benötigen, reichen die von den Herstellern
bereitgestellten APIs und Schnittstellen nicht aus.
Post by Peter GötzZufahrlässigkeit
Zufall-Lässigkeit
;-)
Klar, aber mach mal eine Schleife, die IDs aus meiner Funktion erzeugt und
schaue nach, wann das erste Duplikat erscheint.
Post by Peter GötzPost by D. GottschaldtOder auch, wenn Datensätze des eigenen Programms mit Datensätzen von
Fremdsystemen gemischt werden müssen, was zumindest bei meinen Projekten
fast ausschließlich der Fall ist. Da würde es nicht unbedingt Sinn
machen, zwei Arten von IDs zu pflegen.
Siehe oben: Wenn die Fremdformate bekannt sind, gibt es vieles zu
überlegen, nicht nur das Format alleine. Ist es nicht bekannt, ist jede
Überlegung vorher müßig.
Klar. Soviel Selbsterhaltungstrieb sollte jeder haben, um sich diese
Gedanken schon bei den ersten Projektbesprechungen zu machen; bzw. schon bei
der allerersten Analyse.
Post by Peter GötzPost by D. GottschaldtJa, natürlich kann es zu Duplikaten kommen, aber wie gesagt: betrachte
mal selbst die Wahrscheinlichkeit und die relativ einfachen
Möglichkeiten, das abzufangen.
Mit welchen Kosten abfangen? Jedesmal erst prüfen, ob ein vergebener Index
bereits vergeben ist, oder fehlschlagende Einfügeversuche abfangen? Beides
ziemlich hohe Kosten, finde ich.
Finde ich nicht, denn bei einem ausreichend großen Bereich kommen
fehlgeschlagene Einfügeversuche kaum vor.
Selbst bei einem oder zwei am Tag wären die Kosten minimal, d. h. der
zusätzliche Zeitaufwand für den Einfügeversuch bewegt sich im
Zehntelsekundenbreich und die Alternativfunktion wird ja nur im Fehlerfall
aufgerufen. Aber wie gesagt: das kam in meinem System in 4 Jahren im
Regelbetrieb genau einmal vor. Insofern also hinnehmbar.
Post by Peter GötzPost by D. GottschaldtIm übrigen mal einen herzlichen Dank an Dich und die anderen
Newsgroup-Cracks hier; als ich vor ca. 8 Jahren durch einen ziemlich
blöden Zufall meinen anständigen Beruf als Dipl.-Betriebswirt aufgab und
in die "Niederungen" der Softwareentwicklung hinabstieg, waren es Deine
Seiten, Beiträge (wie auch die von H. M. Genauck, E. Boye und diversen
anderen Ungenannten), die es mir ermöglicht haben, mich in die Geschichte
einzuarbeiten und Unmengen von Fehlern zu vermeiden.
Danke, das ist nett, das auch mal zu hören...
;-)
Ich habe zu danken.
Gruß
Dragan Gottschaldt
Post by Peter GötzViele Grüße
Harald M. Genauck
ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de