nicht angemeldet T-Rex
Rolf B
T-Rex
Rolf B
Der Martin
Rolf B
Tabellenkalk
klawischnigg
Moin,
ich hab immer wieder das Problem 3 Werte zu speichern bzw. ab zu fragen. Ja, nein und beides (oder keins von beidem).
Ich wollte mal fragen wie ihr diesen Fall in einer Programmiersprache lösen würdet? Wie würdet ihr die Werte abspeichern? Ich ziehe aktuell -1, 0, 1 als Int vor. Das Problem dabei ist, dass sind Zahlen, die ohne Bezug nichts aussagen. Wie würdet ihr die Werte abfragen? Würdet ihr pro Zustandsmöglichkeit eine Methode machen? Wie würdet ihr den Fall in einer Datenbank lösen? Eventuell gibt es da zwei Lösungsansätze?
Ich erhoffe mir einen eleganten Weg, der immer funktioniert ähnlich der Abfrage true/false.
Gruß bester Lösungsfinder T-Rex
Hallo T-Rex,
ich hab immer wieder das Problem 3 Werte zu speichern bzw. ab zu fragen. Ja, nein und beides (oder keins von beidem).
Bei einer Ja/Nein Frage kann ich mir nicht vorstellen, wie "Ja und Nein" fachlich interpretierbar sein kann. "Keins von beiden" wäre als "unbeanwortet" deutbar. Es gibt für eine generische Lösung aber noch eine vierte Möglichkeit: "Nicht zutreffend".
Den Sachverhalt "nicht zutreffend" sollte man definitiv über ein eigenes boolesches Feld abbilden. Zumindest in der Datenbank.
Den Sachverhalt "Frage unbeantwortet" kann man durch ein nullable bool in der DB darstellen, dann gibt's eben TRUE, FALSE und NULL als mögliche Werte - de facto ist "NULL" aber auch nur ein weiteres bool, das von der DB verwaltet wird.
Wenn Du tatsächlich Ja UND Nein als gültige Eingabe haben kannst, dann mach aus Ja und Nein jeweils ein eigenes bool - d.h. es läuft dann auf 2-3 bools in der DB hinaus: Eins für JA, eins für NEIN und, sofern das benötigt wird, eins für "Frage relevant". Die Abfrage ist dann natürlich etwas mühsamer, aber in einer DB würde ich nicht anfangen, diese unterschiedlichen Zustände in einem Feld abzubilden und als Zahl zu codieren. Damit denormalisierst Du die DB (jedes Attribute in ein eigenes Feld, 1NF), was man nur tut, wenn es für die Performance der DB unabdingbar ist.
Im Programm könntest du diese Zustände durch verschiedene Bits eines int abbilden, aber das macht dein Programm unübersichtlich. Man kann auch ein Objekt dafür vorsehen, und immer dann, wenn Du die Antwort auf eine dieser Ja/Nein Fragen darstellen musst, setzt Du dieses JaNein-Objekt dafür ein. Das kann es dann in der erweiterten Ausprägung "JaNeinIrrelevant" Objekt geben.
Rolf
Danke für deine Antwort. Mir sind die Möglichkeiten durchaus bewusst. Ich habe aber noch nicht den Idealweg gefunden. Wie schon beschrieben erhoffe ich diesen zu finden.
Wie würdest du es konkret und ohne Hypothese lösen? Um es noch konkreter zu machen, nehmen wir mal eine Fußgängerampel als praktisches Beispiel. Diese zeigt rot, grün oder beides (bei einem Fehler z.B.). Wie würdest du die Werte in einem Programm speichern und abfragen und wie in einer Datenbank?
Gruß prakitsches Rexilein
Hallo T-Rex,
in einem Programm würde ich die einzelnen Lampenzustände speichern. In die Datenbank würde ich nur gültige Werte legen, d.h. den Zustand "ROT-GRÜN" einer kaputten Ampel würde ich gar nicht speichern.
Es sei denn, ich muss... Und nun hypothetisieren wir doch wieder.
Um zu Deinem "Ja/Nein" zurückzukommen - wenn ein Anwender mir eine Frage mit JA oder NEIN beantworten muss, würde ich ihm keine Checkboxen vorsetzen, sondern eine Liste von Radiobuttons. Wenn die alle den gleichen Namen haben, lässt der Browser nur einen davon zu. Wenn der Anwender die Zustände "unbeantwortet" oder "nicht zutreffend" auswählen können soll, gibt's dafür einen weiteren Radiobutton (oder einen separaten "Antwort Löschen" Button hinter den Radiobuttons).
Der Server bekommt vom Browser dann einen von zwei bis vier möglichen Werten. Das können Zahlen sein oder Strings, das hast Du mit dem value Attribut der Radiobuttons in der Hand.
Wie Du das in der DB speicherst, ist davon komplett unabhängig. Das UI designst Du nach Bedienbarkeit, und die Ablage in der DB designst Du nach den Erfordernissen der weiteren Verarbeitung.
Rolf
Hallo Rolf,
in einem Programm würde ich die einzelnen Lampenzustände speichern.
da wäre ich d'accord. Je ein Boolean für Rot und Grün.
In die Datenbank würde ich nur gültige Werte legen, d.h. den Zustand "ROT-GRÜN" einer kaputten Ampel würde ich gar nicht speichern.
Wieso nicht? Ich würde hier keine Wertung vornehmen, sondern stur speichern, was vom Frontend geliefert wird.
Es sei denn, ich muss... Und nun hypothetisieren wir doch wieder.
Eben. Was ist, wenn es um eine Art Serviceprotokoll geht, aus dem über eine nachgelagerte Auswertung (unter anderem) Fehler isoliert und identifiziert werden sollen?
Um zu Deinem "Ja/Nein" zurückzukommen - wenn ein Anwender mir eine Frage mit JA oder NEIN beantworten muss, würde ich ihm keine Checkboxen vorsetzen, sondern eine Liste von Radiobuttons.
Genau. Mit den Labels "Ja", "Nein", "Vielleicht". Oder so ähnlich.
Immer eine Handbreit Wasser unterm Kiel
Martin
Hallo Der,
Wieso nicht? Ich würde hier keine Wertung vornehmen, sondern stur speichern, was vom Frontend geliefert wird.
Das hängt von der Fachlichkeit ab. Je nachdem hast Du ein unterschiedliches fachliches Datenmodell, und in der DB speicherst Du das Businessmodell, nicht die UI Werte. Die UI Werte können dem Modellinhalt entsprechen, müssen aber nicht.
FALLS Du die Aufgabe bekommst, die aktuellen Eingaben im UI speichern zu können, egal ob fachlich plausibel oder nicht, dann machst Du ein Datenmodell dafür und speicherst dieses. Das dürfte aber die Ausnahme sein.
Ist aber wurscht - es läuft immer auf's Gleiche hinaus: Die DB enthält das erforderliche fachliche Modell. Das UI präsentiert dem Anwender eine Sicht darauf. Eine solche Sicht kann sich nicht beliebig weit, aber doch ziemlich vom fachlichen Modell entfernen und trotzdem noch sinnvoll sein.
Deswegen gibt's keine Universalregel. Es gibt auch keine universelle Vorgehensweise. Wenn ich auf der grünen Wiese starte, beginne ich mit Usecases. "Was soll meine Anwendung können". Aus den Usecases entwickle ich normalerweise ein fachliches Modell, das die Daten aller Usecases konsistent aufnehmen kann. Daraus leite ich zum Anwender hin die UIs ab, als eine für den jeweiligen Usecase optimierte Sicht auf die Daten. Und ich leite zur DB hin das DB-Schema ab, das für die jeweilige DB optimale Zugriffe bietet.
Diese Methode ist teamorientiert. Man baut gemeinsam das Fachmodell, und dann kann man sich für die UIs und die DB aufteilen. Wenn man als Einzelkämpfer unterwegs ist, mag das anders aussehen.
Allerdings - man sollte das nicht zu strikt tun, sonst landet man beim Wasserfallmodell der 60er Jahre. Wasserfall ist für physische Bauten sinnvoll, wo es irre teuer ist, Komponenten abzureißen und neuzubauen. Bei Software ist das anders, deswegen kann man iterativ vorgehen. Dazu gibt's diverse, mehr oder weniger agile Vorgehensweisen. Und man sollte sich nicht schämen, wenn man einen Teil der Anwendung neu schreibt, nur weil man Fachanforderungen im Backlog findet, die mit dem aktuellen Modell nicht realisierbar sind. Das ist ganz normal. Software ist keine Raketentechnik. Dinge neu zu entwickeln ist billiger, als die 100% Lösung vorzuplanen. Solche Pläne erweisen sich fast immer als unbrauchbar. Fachvorgaben sind bewegliche Ziele. Man sollte nur drauf schießen, wenn sie nahe genug sind.
Rolf
@@Rolf B
Die DB enthält das erforderliche fachliche Modell. Das UI präsentiert dem Anwender eine Sicht darauf. Eine solche Sicht kann sich nicht beliebig weit, aber doch ziemlich vom fachlichen Modell entfernen und trotzdem noch sinnvoll sein.
Unbedingt.
Ich würde sogar sagen: Eine solche Sicht sollte sich [in vielen Fällen] ziemlich vom fachlichen Modell entfernen.
Nutzer haben i.d.R. ein anderes mentales Modell von der Anwendung als deren Entwicklerinnen.
Dem sollte man Rechnung tragen und Nutzerinnen nicht das mentale Modell der Entwickler aufzwingen, was zu mieser UX führt und sogar dazu, dass Nutzer entnervt aufgeben und die Anwendung nicht benutzen.
😷 LLAP
Hallo Gunnar,
weswegen man das UI auch nicht von den Entwicklern designen lassen sollte. Was aber oft genug trotzdem passiert.
Rolf
Hallo,
Um zu Deinem "Ja/Nein" zurückzukommen - wenn ein Anwender mir eine Frage mit JA oder NEIN beantworten muss,
Oder anders gesagt, wenn auf eine Ja/Nein-Frage auch „Ja und Nein“ geantwortet werden können soll, so ist die Frage falsch formuliert...
Gruß
Kalk
Moin,
Um zu Deinem "Ja/Nein" zurückzukommen - wenn ein Anwender mir eine Frage mit JA oder NEIN beantworten muss,
Oder anders gesagt, wenn auf eine Ja/Nein-Frage auch „Ja und Nein“ geantwortet werden können soll, so ist die Frage falsch formuliert...
was uns wieder vor Augen führt, dass die meisten Menschen sich mit logischen Aussagen schwer tun.
Kassiererin an der Supermarktkasse: Zahlen Sie bar oder mit Karte?
Kunde: Ja.
Immer eine Handbreit Wasser unterm Kiel
Martin
Hallo Der,
dieser Kunde muss aber ein Mathematiker gewesen sein.
Die Aussage war
Rolf
Hallo Rolf,
dieser Kunde muss aber ein Mathematiker gewesen sein.
weit gefehlt! Vielleicht ein Erbsenzähler ...
Die Aussage war
- korrekt
- eindeutig
- und nutzlos
Zugegeben, ja. Dieser Kunde war ich. Mehrmals schon. 😉
Immer eine Handbreit Wasser unterm Kiel
Martin
Hallo,
Die Aussage war
- korrekt
- eindeutig
- und nutzlos
Zwei davon erkenne ich an. Eine möchte ich vielleicht anzweifeln.
Gruß
Kalk
@@Der Martin
was uns wieder vor Augen führt, dass die meisten Menschen sich mit logischen Aussagen schwer tun.
Kassiererin an der Supermarktkasse: Zahlen Sie bar oder mit Karte?
Kunde: Ja.
Der Kunde kaufte 6 Brote?
😷 LLAP
Hi there,
Wie würdet ihr die Werte abspeichern? Ich ziehe aktuell -1, 0, 1 als Int vor. Das Problem dabei ist, dass sind Zahlen, die ohne Bezug nichts aussagen.
sorry, aber da muß ich nachhaken - was sagt denn true oder false ohne Bezug aus?
Auch wenn es etwas weit hergeholt ist, aber Wittgenstein sagt, ein Symbol steht für das, wofür es verwendet wird - ich halte da Deine Bedenken irgendwie für ein "First-World"-Scheinproblem...
Es gibt Softwarepattern. Was sagen die ohne Bezug aus? Es gibt Arrays. was sagen die ohne Bezug aus?
Würde ich ein Neuling sein und sagen ich hab da was mit true und false wie behandle ich das. Dann wäre die Antwort schnell "total simple Boolean" - alles gut. Man hat eine Variable, die ist entweder true oder false. Kann man in der Datenbank leicht speichern, man kann es im Programmcode mittels einfachem if leicht abfragen. Benennt man die Variable auch noch entsprechend kann man sogar aus dem Quellcode heraus sehen um was es geht.
Und genau das versuche ich jetzt nicht bei 2 Möglichkeiten sondern bei 3 Möglichkeiten. Gibt es hier eine Intelligente Lösung die immer funktioniert?
Es gab ja schon den Vorschlag zwei Variablen zu nehmen die jeweils ein Boolean sind. Klar ist das eine Lösung, aber ist sie auch smart? Bei der Abfrage im Programmcode müsste man bei einem if beide Variablen prüfen. Würde man meinen Vorschlag gehen und ein Array nehmen mit [-1,0,1], dann würde man in dem if wieder nur eine Sache prüfen. Dafür sind die Zahlen nichts sagend - also doch nicht smart.
Vielleicht ist true, false, null die beste Lösung? Könnte man auch ziemlich locker in der Datenbank abspeichern. Problem ist dabei nur, wenn die Angaben nicht dem tatsächlichen zustand entsprechen sondern wieder nur synonyme sind ähnlich der Array Lösung. Wenn z.b. true für grün steht, false für rot und null für beides. Das kann man aus dem Programmcode ohne Kommentare nicht herauslesen.
Bei 4 Möglichkeiten würde ich eventuell wieder auf 2 Boolean oder doch auf ein Array zurückgreifen. Aber das war hier ja nicht gefragt ;).
Gruß / Nicht Gruß / T-Rex
@@T-Rex
Würde man meinen Vorschlag gehen und ein Array nehmen mit [-1,0,1], dann würde man in dem if wieder nur eine Sache prüfen. Dafür sind die Zahlen nichts sagend - also doch nicht smart.
Smart ist sprechender Programmcode. Du speicherst Zahlenwerte in der Datenbank, verwendest aber im Programmcode Bezeichner. Die Zahlenwerte kommen nur genau einmal im Programmcode vor:
Gunnar Bittersmannconst ROT = -1;
const GRUEN = 1;
const BEIDES = 0;
😷 LLAP
das könnte man machen, indem man 0, 1 und 2 nimmt.
<?php
$bool = 2 // BOOL wird auf "undefined" gesetzt
IF ($bool == 2){ // Wenn BOOL 2 ist...
ECHO undefined}; // Gebe "undefined" aus
?>