Hallo Michael,
Post by Michael ZimmermannDu hast meinen Einwand mißverstanden. Ich spreche nicht
gegen das Verschlüsseln von Informationen in Form von
Zahlen - wer mich hier etwas kennt, wird wissen, daß
ich zu Zahlen ein intimeres Verhältnis pflege als zu
Text ;-) -, sondern gegen das fehlerhafte Aggregieren
mehrerer Informationen in einem Feld.
Ob wir uns da so mißverstanden haben weiß ich noch nicht, denn einerseits
bin ich ja völlig deiner Meinung, aber andererseits geht es ja darum dass
Informationen intuitiv durch den Leser dieser Informationen erkannt werden
können und andererseits aus programmiertechnischen Gründen diese
Informationen anders aufbereitet bzw. vorliegen sollten / müssen.
Post by Michael ZimmermannPost by Heidrun HeckFür Telefonnummern gilt das ebenfalls, jeder weiß, dass
wenn eine Telefonnummer mit 0190 anfängt es "teuer" wird
usw. Auch hier wird ohne Probleme interpretiert obwohl
die Zahl an sich überhaupt nichts aussagt von
mathematisch gesehener Seite.
Um es an dem Beispiel zu klären: Falsch ist
Telephonnummer
0192666666
0613112345
...
Richtig ist
LW VW HW DW
049 6131 1234 56
...
für z. B. 06131/1234-56
Ja schon klar, aber aus "usability" Sicht ist das etwas ganz anderes. Wenn
ich irgend jemanden nach seiner Telefonnummer frage, dann nennt mir dieser
mit an Sicherheit grenzender Wahrscheinlichkeit nach nicht die 049 am
Anfang. Und schon gar nicht berücksichtigt er, dass dann bei der Vorwahl die
fürhrende 0 wegfallen muss.
Datenbanktechnisch gesehen ist das natürlich falsch, aber darum ging es mir
ja auch gar nicht. Worum es mir ging ist, dass anhand von Zahlen (z.B.
Telefonnummern) der entweder Otto-Normalbürger oder halt auch der Fachmann
irgendwelche Informationen oder Rückschlüsse intuitiv ableiten kann.
Und um bei deiner Aufteilung der Telefonnummer zu bleiben, da ist das
analytisch gesehen vollkommen richtig, aber intuitiv gesehen hat du da die
0190er Nummern vergessen einzusortieren Sondernummern lassen sich da nicht
in das Schema pressen und haben eine ganz andere Bedeutung, da sie ja eben
nicht aus dem Schema bestehen. So kann sich eine solche Nummer eben nicht in
LW / VW / HW / DW aufteilen lassen. Das gleiche gilt auch für andere
Nummernkreise.
Und ganz abgesehen davon dass z.B. 049 190 xxx nicht funktionieren würde.
Post by Michael ZimmermannEs spricht nichts - ich am allerwenigsten - gegen
Zahlencodes, aber je abzufragender Information
muß ein eigenes Feld vorgesehen sein.
Im Beispiel müßten diese Nummernschnipsel noch auf
verschiedene Tabellen verteilt werden, wie LW zu Länder,
VW zu Orte, HW zu Firma/Kontakt, ggf. DW zu Abteilung/Büro/
Ansprechpartner.
Das ist jetzt programmiertechnische Logik die naütrlich stimmt und richtig
ist. Aber darum ging es in meinen Ausführungen nicht. Ich wollte
verdeutlichen, dass auch ohne diese Logik derjenige der sich mit der
Bedeutung der Zahlen, Nummern etc. auskennt diese auch ohne
programmiertechnische Logik deuten kann.
Nehmen wir einfach ein anderes Beispiel:
Frage mal 1000 Autofahrer die mit ihrem eigenen KFZ unterwegs sind wie viel
KW ihr Fahrzeug hat. --> Keine Ahnung
Frage mal 1000 Autofahrer wie viel PS ihr Fahrzeug hat --> Das wissen an die
80%
Hier ist es ebenfalls so, dass Tradition halt vorhanden ist, egal ob die
wissenschaftlich begründet noch richtig / gültig ist usw. Und damit muß man
als reiner Wissenschaftler nicht unbedingt arbeiten, aber wenn man bei
seiner Arbeit irgend eine Schnittstelle zu seinen Kunden braucht, dann muss
man solche Sachen ganz einfach berücksichtigen. Und Tradition hat auch seine
guten Seiten...
Post by Michael ZimmermannSpeziell bei dem diskutierten DATEV-Modell kritisiere
ich, daß die Information Kontenkategorie (Kreditoren,
Debitoren, ...) und der Kontenname durch die Verwendung
von /Zahlenbereichen/ untrennbar verquickt sind.
Ja programmiertechnisch gesehen gebe ich dir da recht.
Post by Michael ZimmermannPost by Heidrun HeckAber da diesen Standard jeder kennt ist das kein Problem.
Daswarschonimmerso,dakönntjajederkommenundüberhaupt? ;-)
Jein, aber est ist halt Tatsache, dass man auf solche Sachen Rücksicht
nehmen muss ob man will oder nicht. Und schon besonders dann wenn es (evtl.
unsinnige) Vorschriften irgendwelchen Art gibt die man berücksichtigen muss.
Post by Michael ZimmermannAls Absolvent einer wissenschaftlichen Ausbildung
reklamiere ich für mich das Recht, falsche Standards
zu kritisieren. Ohne den aufopfernden Einsatz eines
längst verstorbenen Kollegen wäre die Welt noch immer
eine Scheibe. ;-)
Das ist auch völlig ok, aber spätestens dann wenn du dich aus dem rein
wissenschaftlichen Rahmen heraus bewegst bekommst du das Problem bzw. die
Konfrontation mit der Realität. Im kommerziellen Bereich bedeutet das halt,
dass man Abstriche mache muss wenn man seine Software verkaufen möchte.
Kritik an "Gesetzten" ist angebracht und vernünftig, sonst würden wir
wirklich noch auf der "Scheibe" leben <vbg>
Es geht auch nicht um die wissenschaftliche Ausbildung an sich (die habe ich
übrigens auch) sondern darum dass man halt ganz einfach einen Weg finden
muss die rein technische Seite der Programmierung in Einklang mit den
Anforderungen der Kunden zu bringen und dabei die Usability nicht aus den
Augen zu verlieren. Und schon gar nicht, dass die Leute die eine Software
verwenden oft überhaupt keine Ahnung haben und froh sind, dass sie diese
überhaupt auf ihrem Monitor sehen.
--
Gruß,
Heidrun