5 ms·

You're assuming all the questions are being presented to the user at once. Imagine a UI that presents questions to a user one-by-one. If the user bails out of

You're assuming all the questions are being presented to the user at once. Imagine a UI that presents questions to a user one-by-one. If the user bails out of the survey early, the rest of the survey answers can be null.

MBCook 10y ago
In that case you can easily keep track of what step they got up to in the wizard. It's a different way to store the data, but would work just as well. I think the null vs empty argument works better when there are 40 boxes on screen at once. But again I'm not sure what semantic difference you'd find between 'they left it empty' and 'they never clicked into it'.
- ceejayoz 10y ago
  Keeping track of the step works until you move a field onto a different step in the wizard.
  - MBCook 10y ago
    First, it's a document store so you can store the way the form is constructed with it (i.e. order of elements, etc). Second, in Dynamo you could chose the absence of a key to represent "never got here" and a key with a null value to represent "they left this blank". You don't need an empty string.
    - Dylan16807 10y ago
      So using null to mean the opposite of what it normally means? I would recommend against anyone using that workaround.
      - MBCook 10y ago
        That depends on whether you see null as a marker of not having data or a marker of not knowing if there is data.
        Dylan16807 10y ago
        Both of those are data unknown, and both would normally be null. You don't distinguish between known unknowns and unknown unknowns at the database level. When you say "The user submitted an empty form field as their answer", you do have data. It's weird to use null for that. Since you can leave a key absent in DynamoDB, it basically has two ways to say "data unknown" and no way to say "knowingly left blank". You can repurpose null as you suggested, and it will work fine in isolation, but it will massively violate the principle of least surprise and could lead to painful bugs.

MBCook 10y ago

In that case you can easily keep track of what step they got up to in the wizard. It's a different way to store the data, but would work just as well. I think the null vs empty argument works better when there are 40 boxes on screen at once. But again I'm not sure what semantic difference you'd find between 'they left it empty' and 'they never clicked into it'.

ceejayoz 10y ago
Keeping track of the step works until you move a field onto a different step in the wizard.
- MBCook 10y ago
  First, it's a document store so you can store the way the form is constructed with it (i.e. order of elements, etc). Second, in Dynamo you could chose the absence of a key to represent "never got here" and a key with a null value to represent "they left this blank". You don't need an empty string.
  - Dylan16807 10y ago
    So using null to mean the opposite of what it normally means? I would recommend against anyone using that workaround.
    - MBCook 10y ago
      That depends on whether you see null as a marker of not having data or a marker of not knowing if there is data.
      - Dylan16807 10y ago
        Both of those are data unknown, and both would normally be null. You don't distinguish between known unknowns and unknown unknowns at the database level. When you say "The user submitted an empty form field as their answer", you do have data. It's weird to use null for that. Since you can leave a key absent in DynamoDB, it basically has two ways to say "data unknown" and no way to say "knowingly left blank". You can repurpose null as you suggested, and it will work fine in isolation, but it will massively violate the principle of least surprise and could lead to painful bugs.