💡 Перевод статьи https://www.amliesolutions.com/bubble/advanced/bubble-data-concept/
Идея концепции данных и причина того, почему мы думаем, что это необходимо при обсуждении производительности базы данных, заключается в том, что нам нужно освободить себя от мысли, что тип данных должен каким-то образом идеально отражать запрос нашего клиента или то, как наши пользователи видят наше приложение. Сейчас объясним подробнее.
Каждый раз, когда у вас появляется идея для приложения или план проекта, который вы разработали с клиентом, у вас будет список различных типов, которые вам нужно сохранить в своей базе данных. Для примера будем иметь ввиду CRM, созданную для клиента. Предполагается, что база данных будет содержать такие данные как:
- Клиенты
- Продавцы
- Контакты
- Проекты
Это происходит чаще, чем вы думаете: настройка выполняется так быстро, что очень легко добавить все изначальные типы в качестве первого шага, чтобы просто запомнить это.
Но что, если мы остановимся на минуту и быстро взглянем на то, что мы настраиваем.
Что такое концепция данных?
Поначалу может быть несколько непонятно, зачем нам этот термин, когда Bubble уже познакомил нас с типом данных. Разница между ними заключается в следующем:Тип данных является то , что вы на самом деле сохранения в базе данных. У него есть имя и поля, которые вы ему задали, и обычно оно не меняется после того, как вы его настроили.
Концепция данных - это как Пользователь/клиент видит свои данные. Он отражает пользовательский опыт вашего приложения, но не обязательно отражает фактическую настройку вашей базы данных.
Причина, по которой мы разделяем эти две модели, заключается в том, что совпадение этих двух моделей не всегда выгодно. Помните, ваша задача как разработчика - не делать в точности то, что вам говорят ваши пользователи или клиенты, а создавать приложение, которое решает их проблему наилучшим образом. Иногда это означает настройку вашей базы данных другим способом, чем предлагает ваш клиент.
Разберём на простом примере.
Клиенты и продавцы - чем они отличаются?
Давайте посмотрим на две основные концепции данных: клиенты и поставщики .Для клиента нам обычно нужны поля:
- Имя
- Телефон
- Эл. адрес
- Адрес
- так далее
Теперь посмотрим на поставщика:
- Имя
- Телефон
- Эл. адрес
- Адрес
- так далее
Теперь, размышляя над требованиями, которые нам потребуются для этих двух Типов данных, мы наткнемся на одно и то же - оба этих типов данных должны удовлетворять следующим свойствам:
- Быстро находиться в поиске
- Быть видимыми
- Быть редактируемыми
- Иметь настройки правилами конфиденциальности
Вы тоже видите это? По сути, это одно и то же! Если подумать дальше в том же духе, разве не возможно, чтобы в какой-то момент продавец также мог быть клиентом?
Разные концепции данных, но тот же тип данных
Как мы видим здесь, есть веская причина просто объединить клиента и поставщика в один тип данных.Чтобы разделить два этих типа внутри одной таблицы, мы можем просто создать дополнительное поле Role и задавать нужную роль с использованием Option set, чтобы разделить их, и использовать список этих наборов опций, если нам нужна возможность для поставщика, чтобы он также мог быть клиентом.
Если бы мы думали о требованиях нашего клиента к данным как о типах данных , мы могли бы упустить эту возможность более эффективно настроить нашу базу данных. Поскольку мы использовали модель Data Concept и извлекли ее из базы данных, мы поняли, что способ, которым клиент или идея описывает определенный тип данных, не обязательно должен полностью иллюстрировать, как на самом деле выглядит ваша база данных.