Как разработать интерфейсы форм для баз данных без схемы?

Если вы используете базу данных SQL, очень просто разработать пользовательский интерфейс для операций CRUD. Поскольку схема определена, очевидно, сколько входных данных вам нужно в форме и т. Д.

Но при использовании подхода NoSQL без схемы для хранения, как вы строите интерфейсы, если вы точно не знаете, чего ожидать от типов хранимых данных? Например, если у вас была база автомобилей:

var cars = [

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

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

];

Если вам нужно было создать пользовательский интерфейс, чтобы вы могли получать доступ к этим данным и редактировать их, вы не представляете, сколько входов вам нужно, поскольку схемы нет. Как разработчики пользовательского интерфейса решают эту проблему?

У вас есть набор if операторов, чтобы проверить, существуют ли в записи все возможные атрибуты, прежде чем показывать правильные входные данные?

// 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
}

user-interface crud nosql database schemaless
person Jake Wilson    schedule 09.03.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если вам нужно было создать пользовательский интерфейс, чтобы вы могли получать доступ к этим данным и редактировать их, вы не представляете, сколько входов вам нужно, поскольку схемы нет. Как разработчики пользовательского интерфейса решают эту проблему?

Вы решаете это, исходя из требований к функциям. Совершенно очевидно, что вы не пытаетесь генерировать формы (автоматически или иным образом) из схем: это рецепт плохого UX, даже если у вас под рукой есть исчерпывающая, каноническая и недвусмысленная схема.

Вместо этого: вы знаете, каковы ваши «варианты использования» (вы спрашиваете пользователей), и затем вы создаете именно эти.

Возникает вопрос:

  1. Что вы делаете, если ваш элемент данных / экземпляр не содержит определенного объекта / поля / ключа, которого вы ожидали?
  2. Что вы делаете, когда ваш экземпляр содержит поля, которые вы не не знаете, что делать?

Ответ на вопрос №1 довольно прост и в основном такой же, как и при изменении схемы: принять / представить разумные значения по умолчанию или изящно обрабатывать нулевые значения. То есть: разрешите вашим пользователям добавлять такие поля позже, где они имеют смысл, и не подавитесь объектами, у которых они отсутствуют.

Ответ на № 2 более сложный, и он будет сильно зависеть от приложения и его среды (например: является ли он единственным потребителем данных или есть ли другие потребители, которых следует учитывать). Одним из вариантов может быть нормализация: вы обрезаете такие посторонние поля при сохранении, чтобы объекты со временем нормализовались по мере их обновления пользователями. Альтернативой может быть сохранение: вы сохраняете любые поля, которые вы не знаете, как есть, и прилагаете усилия, чтобы сохранить их на всех уровнях вашего приложения.

person user268396    schedule 09.03.2017