nicht angemeldet
Hi,
http://www.spiegel.de/wirtschaft/0,1518,335124,00.html
Da wurde wohl mit der heißen Nadel gestrickt und die Testphase ausgelassen.
man muss wissen, dass der Staat sowieso ein schlechter Abnehmer von Entwicklungsleistungen ist. Das Interesse eines Beamten an der Qualitaet der erbrachten Leistung ist naturgemaess geringer als das von Abnehmern in der Privatwirtschaft. Aus eigener Erfahrung kann ich berichten, dass Abnehmer sich oft nur versuchen "abzusichern" (d.h. sich in eine Position zu bringen, in der ihr kein Fehler nachgewiesen werden kann), also ihrer Abnehmerrolle aus verschiedensten Gruenden (mangelndes Interesse, Faulheit, Inkompetenz, aus strategischen Ueberlegungen heraus) nicht gerecht werden. - Und die Entwickler setzen in aller Regel exakt das um, was angefordert ist.
Bei Kontonummern die führenden Nullen hinten anzufügen, hätte dann eigentlich auffallen müssen.
Das riecht nach COBOL-Datenhaltung.
Muss mit den Kontonummern eigentlich im späteren Verlauf noch gerechnet werden?
Es gibt da Plausibilitaetskontrollen, also es kann anhand einer BLZ und einer Kontonummer festgestellt werden, ob die Kombination der beiden ueberhaupt zulaessig ist. Das ist u.a. implementiert um beim OCR erfolgreicher sein zu koennen.
Wäre es in diesem Fall sinnvoll mit einer Stringvariablen zu arbeiten, da man dort die führenden Nullen direkt eingeben kann und diese dann nicht verloren gehen?
Eine "Stringvariable" soll in diesem Zusammenhang wohl heissen: die Einstellung Zeichenkette in der Datenbankschicht. - Nun, das sind Fragestellungen, die sich aus der Ferne oft nicht kompetent bearbeiten lassen. Ist zum Beispiel klar, das nur Ziffern Teil einer Kontonummer sein koennen, waere die Einstellung "NUMERIC (9)" (bei Maximallaenge 9) praeziser und guenstiger fuer die Datenkonsistenz.
Im geschilderten Fall - so wie uebrigens auch bei der Maut-Katastrophe - sehe ich also die Schuldigen (erst einmal) immer im Abnehmerbereich, gerade auch dann, wenn der Staat mitmischt.
Gruss,
Ludger