How to develop form interfaces for schema-less databases?

Question

If you are using an SQL database, it's very straightforward to develop a user interface for CRUD operations. Since the schema is defined, it's obvious how many inputs you need in a form, etc.

But when using a schema-less NoSQL approach for storage, how do you build interfaces since you don't know exactly what to expect from the types of data being stored? For example if you had a database of cars:

var cars = [

{ model: "BMW", color: "Red", manufactured: 2016 },

{ model: "Mercedes", type: "Coupe", color: "Black", manufactured: “1-1-2017” }

];

If you needed to create a user interface so you could access and edit this data, you have no clue how many inputs you need since there is no schema. How do UI developers solve this problem?

Do you have a bunch of if statements to test if every possible attribute exists in the record before showing the proper inputs?

// psuedo code
if ($car.hasKey("model") ) {
  // Show the "Model" input form element
}

if ($car.hasKey("type") ) {
  // Show the "Type" input form element
}

if ($car.hasKey("color") ) {
  // Show the "Color" input form element
}

if ($car.hasKey("manufactured") ) {
  // Show the "Manufactured" input form element
}

Answer 1

If you needed to create a user interface so you could access and edit this data, you have no clue how many inputs you need since there is no schema. How do UI developers solve this problem?

You solve this by reasoning from feature requirements. Emphatically, you do not try to generate forms (automatically or otherwise) from schemas: that is a recipe for poor UX even if you do have a comprehensive, canonical and unequivocal schema to hand.

Instead: you know what your 'use cases' are (you ask users) and then you build exactly those.

So the question becomes:

1. What do you do when your data item/instance does not contain a particular object/field/key which you did expect?
2. What do you do when your instance contains fields which you do not know what to do with?

The answer for #1 is pretty straightforward, and basically just the same as dealing with schema changes: assume/present sane defaults or handle null values gracefully. That is: permit your users to add such fields later where they make sense and do not choke on objects that lack them.

The answer for #2 is more complicated and it is going to depend heavily on the application and its environment (for example: is it the sole consumer of the data, or are there other consumers to consider as well). One option could be normalisation: you prune such extraneous fields on saving, so objects become normalised over time as they are updated by the users. An alternative could be preservation: you keep any fields you do not know as-is, and you take pains to preserve them through every layer of your application.