Hallo!
Post by Olaf NoehringIch hasse "ja/nein" Felder - besser ist m. E. (<-
mitleser bitte beachten und keinen Glaubenskrieg vom Zaun
brechen) Kombinationsfelder in denen die Möglichkeiten
stehen. Da kannst du nämlich auch "-keine Angabe-"
hinterlegen. Das Feld zum "Pflichtfeld" machen und es
kann bei der Eingabe nicht vergessen werden.
Die Idee, einen nicht vorhandenen (im Sinne von "Wert nicht
bekannt") Eintrag durch "-keine Angabe-" zu codieren, halte
ich für keine gute Idee, und von der DB-Theorie ist es
verboten.
Dort wird ausdrücklich gefordert, daß nicht vorhandenene
Werte einheitlich durch alle Datentypen durch den NULL-Wert
auszudrücken sind.
Es gibt mehrere Gründe hierfür:
1.) Es soll über alle Datenbanken, -systeme und Plattformen
eine einheitliche Handhabung garantiert sein.
Jeder (fast jeder) DB-Programmierer würde sich blind
darauf verlassen, daß in einer übernommenen DB
ein fehlendes Konto mit IsNull(Konto) aufgefunden
wird.
2.) Ein NULL-Wert schließt bestimmte logische Implikationen
ein - ich habe das Verhalten von NULL mit True und
False schon mehrfach tabellarisch gepostet -, die
in Form einer dreiwertigen Logik präzise seiner
Bedeutung entsprechen. Wenn Du einen selbstgemachten
Wert für "keine Angabe" benutzt, funktioniert das
natürlich nicht mehr.
3.) Wenn Du ein Feld zum Pflichtfeld machst, und dann die
Eingabe eines Wertes zuläßt, der für "keine Angabe"
steht, dann hast Du die Eingabepflicht ja wieder
ausgehebelt und ihren Sinn damit ad absurdum geführt.
Wenn man "keine Angabe" machen darf, laß die
Eingabepflicht weg und man macht halt keine Angabe.
4.) Andere Codierungen für "Nichts" als der systemimmanente
NULL-Wert sind fehleranfällig:
Statt "-keine Angabe-": "- keine Angabe -" oder
"-keine Agnabe-" oder, oder, oder...
Okay, Du hast die Liste in einer Tabelle hinterlegt,
Du Listenreicher (Vorsicht, Wortspiel ;-) ), aber:
Wie stellst Du sicher, daß in 30 Jahren niemand die
Werte "Weiß nicht", "Will nicht" und wasweißich
hinterlegt, die Dein Code nicht kennt?
5.) Wenn der Benutzer nichts weiß, tippt er (oder wählt aus)
einfach nichts. Das ist anschaulicher als "Nichts" in
welcher Form auch immer einzugeben.
Post by Olaf NoehringWo wir gerade dabei sind: Werte nicht als Wertliste beim
Nachschlagefeld speichern, sondern auch in einer (extra)
Tabelle damit sich die Liste leicht ändern/ergänzen lässt.
Bei benutzererweiterbaren Listen ganz klar ja (endlich mal
kein Gemecker ;-) ) - idealerweise entsprechend DKNF mit
Integerschlüssel und zweitem Feld Beschreibungstext.
Bei konstanten Listen, an denen sich nichts ändern kann
oder darf, wäre aber in jedem Fall die Wertliste als
Gültigkeitsregel zu hinterlegen, um Benutzererweiterungen
gerade zu verhindern.
Post by Olaf NoehringAnsonsten würde ich bei __derzeitigem Infostand__ wohl
ein Feld in der Auftragstabelle anlegen in dem
eingetragen (d.h. ausgewählt)wird "offen", "storniert",
"erledigt" - zusätzlich noch ein Datum wann der
entsprechende Auftrag "storniert" oder "erledigt" wurde.
Stornodatum und Storno Ja/Nein (andere entsprechend) ist
mit größter Vorsicht zu genießen: Eigentlich ein
Entwurfsfehler, da Storno ein berechneter Wert
ist:
Storno = Not IsNull(Stornodatum)
Ich habe das selbst schon mit angewidertem Gesichtsausdruck
und viel Code zur Widerspruchsvermeidung gemacht, wenn
schlecht gepflegte Altdaten zu übernehmen waren - Storniert
ja, aber ohne Datum.
Bei einer "frischen" DB würde ich das aber tunlichst
unterlassen. Damit User$ nicht das Datum eintippen muß,
kann im Formular ein Storno-Button das aktuelle Datum
einsetzen oder einen Popup-Kalender aufrufen, falls
ein anderes Datum gewünscht ist. Ein codegesteuertes
Rechteck/Textfeld mag rot bei stornierten und grün bei
sonstigen werden.
Ich hoffe, das war jetzt keine Kriegserklärung für Dich. ;-)
Aber bei manchen, was Du sagst, habe ich, wie ich meine,
begründete Bedenken.
Gruß aus Mainz
Michael