NoCode Hero Hub

Концепция данных в Bubble

💡 Перевод статьи https://www.amliesolutions.com/bubble/advanced/bubble-data-concept/

Идея концепции данных и причина того, почему мы думаем, что это необходимо при обсуждении производительности базы данных, заключается в том, что нам нужно освободить себя от мысли, что тип данных должен каким-то образом идеально отражать запрос нашего клиента или то, как наши пользователи видят наше приложение. Сейчас объясним подробнее.

Каждый раз, когда у вас появляется идея для приложения или план проекта, который вы разработали с клиентом, у вас будет список различных типов, которые вам нужно сохранить в своей базе данных. Для примера будем иметь ввиду CRM, созданную для клиента. Предполагается, что база данных будет содержать такие данные как:
  • Клиенты
  • Продавцы
  • Контакты
  • Проекты
На первый взгляд они выглядят как четыре разных типа данных в Bubble, и во многих случаях первое, что делают начинающие разработчики - это вводят их все в свою базу данных. Можно сказать, что Bubble используется как блокнот для записи.
Это происходит чаще, чем вы думаете: настройка выполняется так быстро, что очень легко добавить все изначальные типы в качестве первого шага, чтобы просто запомнить это.
Но что, если мы остановимся на минуту и быстро взглянем на то, что мы настраиваем.

Что такое концепция данных?

Поначалу может быть несколько непонятно, зачем нам этот термин, когда Bubble уже познакомил нас с типом данных. Разница между ними заключается в следующем:
Тип данных является то , что вы на самом деле сохранения в базе данных. У него есть имя и поля, которые вы ему задали, и обычно оно не меняется после того, как вы его настроили.
Концепция данных - это как Пользователь/клиент видит свои данные. Он отражает пользовательский опыт вашего приложения, но не обязательно отражает фактическую настройку вашей базы данных.

Причина, по которой мы разделяем эти две модели, заключается в том, что совпадение этих двух моделей не всегда выгодно. Помните, ваша задача как разработчика - не делать в точности то, что вам говорят ваши пользователи или клиенты, а создавать приложение, которое решает их проблему наилучшим образом. Иногда это означает настройку вашей базы данных другим способом, чем предлагает ваш клиент.
Разберём на простом примере.

Клиенты и продавцы - чем они отличаются?

Давайте посмотрим на две основные концепции данных: клиенты и поставщики .

Для клиента нам обычно нужны поля:
  • Имя
  • Телефон
  • Эл. адрес
  • Адрес
  • так далее

Теперь посмотрим на поставщика:
  • Имя
  • Телефон
  • Эл. адрес
  • Адрес
  • так далее

Теперь, размышляя над требованиями, которые нам потребуются для этих двух Типов данных, мы наткнемся на одно и то же - оба этих типов данных должны удовлетворять следующим свойствам:
  • Быстро находиться в поиске
  • Быть видимыми
  • Быть редактируемыми
  • Иметь настройки правилами конфиденциальности

Вы тоже видите это? По сути, это одно и то же! Если подумать дальше в том же духе, разве не возможно, чтобы в какой-то момент продавец также мог быть клиентом?

Разные концепции данных, но тот же тип данных

Как мы видим здесь, есть веская причина просто объединить клиента и поставщика в один тип данных. 

Чтобы разделить два этих типа внутри одной таблицы, мы можем просто создать дополнительное поле Role и задавать нужную роль с использованием Option set, чтобы разделить их, и использовать список этих наборов опций, если нам нужна возможность для поставщика, чтобы он также мог быть клиентом.

Если бы мы думали о требованиях нашего клиента к данным как о типах данных , мы могли бы упустить эту возможность более эффективно настроить нашу базу данных. Поскольку мы использовали модель Data Concept и извлекли ее из базы данных, мы поняли, что способ, которым клиент или идея описывает определенный тип данных, не обязательно должен полностью иллюстрировать, как на самом деле выглядит ваша база данных.
База данных
Made on
Tilda