Проектирование многотабличной базы данных: Проектирование многотабличной базы данных

Предыдущая: Разработка простого запроса

Далее:Дополнительные параметры дизайна запроса

/en/access/more-query-design-options/content/

Создание запроса на основе нескольких таблиц

Иногда процесс построения и использования запросов в Access сводится к простому выбору полей из таблицы, возможному применению некоторых критериев и последующему просмотру результатов. Но что, если, как это часто бывает, нужные вам данные разбросаны по нескольким таблицам? К счастью, вы можете создать запрос, объединяющий информацию из нескольких источников. В этом разделе рассматриваются некоторые сценарии, в которых вы извлекаете данные из более чем одной таблицы, и демонстрируется, как вы это делаете.

Что ты хочешь сделать?

• Используйте данные из связанной таблицы, чтобы улучшить информацию в запросе.

• Соедините данные в двух таблицах, используя их связи с третьей таблицей.

• Просмотрите все записи из двух похожих таблиц

Использование данных из связанной таблицы для уточнения информации в запросе

У вас могут быть случаи, когда запрос, основанный на одной таблице, дает вам необходимую информацию, но извлечение данных из другой таблицы поможет сделать результаты запроса еще более четкими и полезными. Например, предположим, что у вас есть список идентификаторов сотрудников, которые появляются в результатах вашего запроса. Вы понимаете, что было бы полезнее просмотреть имя сотрудника в результатах, но имена сотрудников находятся в другой таблице. Чтобы имена сотрудников отображались в результатах запроса, необходимо включить в запрос обе таблицы.

Используйте мастер запросов для создания запроса из основной таблицы и связанной таблицы

1. Убедитесь, что таблицы имеют определенную связь в окне «Связи».

   Как?

   1. Об инструментах базы данных , в группе Показать/скрыть щелкните Отношения .

   2. org/ListItem»>

      На вкладке Проект в группе Взаимосвязи щелкните Все взаимосвязи .

   3. Определите таблицы, которые должны иметь определенную связь.

      • Если таблицы видны в окне «Связи», убедитесь, что связь уже определена.

        Отношение отображается как линия, соединяющая две таблицы в общем поле. Вы можете дважды щелкнуть линию связи, чтобы увидеть, какие поля в таблицах связаны связью.

      • Если таблицы не отображаются в окне «Связи», их необходимо добавить.

        На вкладке Design в группе Показать/скрыть щелкните Имена таблиц .

        Дважды щелкните каждую из таблиц, которые вы хотите отобразить, а затем щелкните Закрыть .

   4. Если вы не найдете связи между двумя таблицами, создайте ее, перетащив поле из одной таблицы в поле другой таблицы. Поля, в которых вы создаете связь между таблицами, должны иметь одинаковые типы данных.

      Примечание.  Можно создать связь между полем типа данных «Счетчик» и полем типа «Число», если это поле имеет размер длинного целочисленного поля. Это часто будет иметь место, когда вы создаете отношения «один ко многим».

      Появится диалоговое окно Редактировать отношения .

   5. Нажмите Создайте , чтобы создать связь.

      Дополнительные сведения о параметрах, доступных при создании отношения, см. в статье Создание, изменение или удаление отношения.

   6. Закрыть окно Отношения .

2. На Создать , в группе Запросы щелкните Мастер запросов .

3. В диалоговом окне Новый запрос щелкните Мастер простых запросов , а затем щелкните OK .

4. В поле со списком Таблицы/запросы щелкните таблицу, содержащую основную информацию, которую вы хотите включить в свой запрос.

5. В списке Доступные поля щелкните первое поле, которое вы хотите включить в свой запрос, а затем нажмите кнопку со стрелкой вправо, чтобы переместить это поле в список Выбранные поля . Сделайте то же самое с каждым дополнительным полем из этой таблицы, которое вы хотите включить в свой запрос. Это могут быть поля, которые вы хотите вернуть в выходных данных запроса, или поля, которые вы хотите использовать для ограничения строк в выходных данных путем применения критериев.

6. org/ListItem»>

   В поле со списком Таблицы/запросы щелкните таблицу, содержащую связанные данные, которые вы хотите использовать для улучшения результатов запроса.

7. Добавьте поля, которые вы хотите использовать для улучшения результатов запроса, в список Выбранные поля и нажмите Далее .

8. Под номером Вам нужен подробный или общий запрос? , щелкните либо Деталь , либо Сводка .

   Если вы не хотите, чтобы ваш запрос выполнял какие-либо агрегатные функции ( Sum , Avg , Min , Max , Count , StDev или Var 9043 ), выберите деталь запроса. Если вы хотите, чтобы ваш запрос выполнял агрегатную функцию, выберите сводный запрос. После того, как вы сделаете свой выбор, нажмите Следующий .

9. Щелкните Готово , чтобы просмотреть результаты.

Пример, в котором используется образец базы данных «Борей»

В следующем примере вы используете мастер запросов для создания запроса, который отображает список заказов, стоимость доставки для каждого заказа и имя сотрудника, который обрабатывал каждый заказ.

Примечание.  В этом примере необходимо изменить учебную базу данных «Борей». Вы можете сделать резервную копию образца базы данных Northwind, а затем следовать этому примеру, используя эту резервную копию.

Используйте мастер запросов для создания запроса

org/ItemList»>

1. Откройте образец базы данных «Борей». Закройте форму входа.

2. На вкладке Создать в группе Запросы щелкните Мастер запросов .

3. В диалоговом окне Новый запрос щелкните Мастер простых запросов , а затем щелкните OK .

4. В таблицах/запросах 9В поле со списком 0437 щелкните Таблица: Заказы .

5. org/ListItem»>

   В списке Доступные поля дважды щелкните OrderID , чтобы переместить это поле в список Выбранные поля . Дважды щелкните Плата за доставку , чтобы переместить это поле в список Выбранные поля .

6. В таблицах/запросах 9В поле со списком 0437 щелкните Таблица: Сотрудники .

7. В списке Доступные поля дважды щелкните Имя , чтобы переместить это поле в список Выбранные поля . Дважды щелкните Фамилия , чтобы переместить это поле в список Выбранные поля . Нажмите Далее .

8. org/ListItem»>

   Поскольку вы создаете список всех заказов, вы хотите использовать подробный запрос. Если вы суммируете стоимость доставки по сотруднику или выполняете какую-либо другую агрегатную функцию, вы используете сводный запрос. Щелкните Детали (показывает каждое поле каждой записи) , а затем щелкните Далее .

9. Щелкните Готово , чтобы просмотреть результаты.

Запрос возвращает список заказов, каждый из которых имеет свою стоимость доставки, а также имя и фамилию сотрудника, который его обрабатывал.

Верх страницы

Соедините данные в двух таблицах, используя их отношения с третьей таблицей

Часто данные в двух таблицах связаны друг с другом через третью таблицу. Обычно это так, потому что данные между первыми двумя таблицами связаны отношением «многие ко многим». Часто хорошей практикой проектирования баз данных является разделение отношения «многие ко многим» между двумя таблицами на два отношения «один ко многим», включающих три таблицы. Вы делаете это, создавая третью таблицу, называемую соединительной таблицей или таблицей отношений, которая имеет первичный ключ и внешний ключ для каждой из других таблиц. Затем создается отношение «один ко многим» между каждым внешним ключом в соединительной таблице и соответствующим первичным ключом одной из других таблиц. В таких случаях вам необходимо включить в свой запрос все три таблицы, даже если вы хотите получить данные только из двух из них.

Создайте запрос на выборку, используя таблицы с отношением «многие ко многим»

1. org/ListItem»>

   На вкладке Создать в группе Запросы щелкните Дизайн запроса .

2. Дважды щелкните две таблицы, содержащие данные, которые вы хотите включить в запрос, а также соединительную таблицу, которая их связывает, а затем щелкните Закрыть .

   Все три таблицы отображаются в рабочей области разработки запросов, объединенные соответствующими полями.

3. Дважды щелкните каждое из полей, которые вы хотите использовать в результатах запроса. Затем каждое поле появляется в сетке дизайна запроса.

4. В сетке дизайна запроса используйте строку Criteria для ввода критериев поля. Чтобы использовать критерий поля без отображения поля в результатах запроса, снимите флажок в поле Показать строку для этого поля.

5. Чтобы отсортировать результаты на основе значений в поле, в сетке дизайна запроса щелкните По возрастанию или По убыванию (в зависимости от того, каким образом вы хотите отсортировать записи) в строке Сортировать для этого поля.

6. На вкладке Design в группе Results нажмите Прогон .

   Access отображает выходные данные запроса в режиме таблицы.

Пример, в котором используется образец базы данных «Борей»

Примечание. В этом примере необходимо изменить образец базы данных «Борей». Вы можете сделать резервную копию образца базы данных Northwind, а затем следовать этому примеру, используя резервную копию.

Предположим, у вас есть новая возможность: поставщик в Рио-де-Жанейро нашел ваш веб-сайт и может захотеть иметь с вами дело. Однако они работают только в Рио и близлежащем Сан-Паулу. Они поставляют все категории продуктов питания, которые вы брокер. Это довольно крупный бизнес, и они хотят, чтобы вы заверили их в том, что вы можете предоставить им доступ к достаточному количеству потенциальных продаж, чтобы они окупились: объем продаж не менее 20 000 реалов в год (около 9 долларов США).,300.00). Можете ли вы предоставить им рынок, в котором они нуждаются?

Данные, необходимые для ответа на этот вопрос, находятся в двух местах: в таблице «Клиенты» и в таблице «Сведения о заказе». Эти таблицы связаны друг с другом таблицей Orders. Отношения между таблицами уже определены. В таблице «Заказы» у каждого заказа может быть только один клиент, связанный с таблицей «Клиенты» в поле «Идентификатор клиента». Каждая запись в таблице «Сведения о заказе» связана только с одним заказом в таблице «Заказы» в поле «Идентификатор заказа». Таким образом, у данного клиента может быть много заказов, каждый из которых имеет много деталей заказа.

В этом примере вы создадите перекрестный запрос, отображающий общий объем продаж за год в городах Рио-де-Жанейро и Сан-Паулу.

Создайте запрос в режиме конструктора

1. Откройте базу данных «Борей». Закройте форму входа.

2. На вкладке Создать в 9Группа 0436 Запросы , нажмите Дизайн запроса .

3. Дважды щелкните Клиенты , Заказы , а затем Детали заказа .

   Все три таблицы отображаются в рабочей области разработки запросов.

4. В таблице «Клиенты» дважды щелкните поле «Город», чтобы добавить его в сетку дизайна запроса.

5. В таблице макета запроса в столбце City в строке Criteria введите In («Рио-де-Жанейро», «Сан-Паулу») . В результате в запрос включаются только те записи, в которых клиент находится в одном из этих двух городов.

6. org/ListItem»>

   В таблице «Сведения о заказе» дважды щелкните поля «Дата доставки» и «Цена за единицу».

   Поля добавлены в сетку дизайна запроса.

7. В столбце ShippedDate в сетке дизайна запроса выберите строку Поле . Замените [ShippedDate] на Year: Format([ShippedDate],»yyyy») . Это создает псевдоним поля Year , который позволяет использовать только часть значения года в поле ShippedDate.

8. В столбце UnitPrice в сетке дизайна запроса выберите строку Поле . Замените [Цена за единицу] на Продажи: [Сведения о заказе].[Цена за единицу]*[Количество]-[Сведения о заказе].[Цена за единицу]*[Количество]*[Скидка] . Это создает псевдоним поля Sales , который вычисляет продажи для каждой записи.

9. На модели , в группе Тип запроса щелкните Crosstab .

   Две новые строки, Total и Crosstab , появляются в сетке дизайна запроса.

10. В столбце Город в сетке дизайна запроса щелкните строку Crosstab , а затем щелкните Заголовок строки .

    Это приводит к тому, что значения городов отображаются в виде заголовков строк (то есть запрос возвращает одну строку для каждого города).

11. В столбце Год щелкните строку Crosstab , а затем щелкните Заголовок столбца .

    Это приводит к тому, что значения года отображаются в виде заголовков столбцов (то есть запрос возвращает один столбец для каждого года).

12. В столбце Sales щелкните строку Crosstab , а затем щелкните Значение .

    Это приводит к тому, что значения продаж отображаются на пересечении строк и столбцов (то есть запрос возвращает одно значение продаж для каждой комбинации города и года).

13. В столбце Продажи щелкните строку Итоги , а затем щелкните Сумма .

    Это приводит к тому, что запрос суммирует значения в этом столбце.

    Вы можете оставить строку Totals для двух других столбцов со значением по умолчанию Group By , потому что вы хотите видеть каждое значение для этих столбцов, а не агрегированные значения.

14. На вкладке Design в группе Results щелкните Run .

Теперь у вас есть запрос, возвращающий общий объем продаж по годам в Рио-де-Жанейро и Сан-Паулу.

Верх страницы

Просмотр всех записей из двух похожих таблиц

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

Предположим, вы аналитик, работающий с данными учащихся. Вы начинаете инициативу по обмену данными между вашей школой и другой школой, чтобы обе школы могли улучшить свои учебные программы. Для некоторых вопросов, которые вы хотите изучить, было бы лучше просмотреть все записи из обеих школ вместе, а не записи каждой школы по отдельности.

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

Чтобы просмотреть все записи из двух таблиц с одинаковой структурой, используйте запрос на объединение.

Запросы на объединение не могут отображаться в представлении «Дизайн». Вы создаете их с помощью команд SQL, которые вы вводите на вкладке объекта представления SQL.

Создайте запрос на объединение, используя две таблицы

1. org/ListItem»>

   На вкладке Создать в группе Запросы щелкните Дизайн запроса .

2. На вкладке Design в группе Query Type щелкните Union .

   Запрос переключается с представления «Дизайн» на представление SQL. На данный момент вкладка объекта представления SQL пуста.

3. В представлении SQL введите SELECT , а затем список полей из первой таблицы, которую вы хотите включить в запрос. Имена полей должны быть заключены в квадратные скобки и разделены запятыми. Когда вы закончите вводить имена полей, нажмите ENTER. Курсор перемещается вниз на одну строку в представлении SQL.

4. org/ListItem»>

   Введите FROM , а затем имя первой таблицы, которую вы хотите включить в запрос. Нажмите Ввод.

5. Если вы хотите указать критерий для поля из первой таблицы, введите ГДЕ , затем имя поля, оператор сравнения (обычно знак равенства ( = )) и критерий. Вы можете добавить дополнительные критерии в конец предложения WHERE, используя ключевое слово AND и тот же синтаксис, что и для первого критерия; например, ГДЕ [ClassLevel]=»100″ AND [CreditHours]>2. Когда вы закончите указывать критерии, нажмите ENTER.

6. Введите UNION и нажмите клавишу ВВОД.

7. org/ListItem»>

   Введите SELECT , а затем список полей из второй таблицы, которую вы хотите включить в запрос. Вы должны включить те же поля из этой таблицы, что и из первой таблицы, и в том же порядке. Имена полей должны быть заключены в квадратные скобки и разделены запятыми. Когда вы закончите вводить имена полей, нажмите ENTER.

8. Введите FROM , а затем имя второй таблицы, которую вы хотите включить в запрос. Нажмите Ввод.

9. Если хотите, добавьте предложение WHERE, как описано в шаге 6 этой процедуры.

10. Введите точку с запятой ( ; ), чтобы обозначить конец запроса.

11. На вкладке Design в группе Results щелкните Run .

    Ваши результаты отображаются в режиме таблицы.

Верх страницы

См. также

Объединение таблиц и запросов

Сравнение многотабличных и однотабличных подходов к проектированию модели данных DynamoDB

DynamoDB — это преобладающая база данных общего назначения в бессерверной экосистеме AWS. Низкие операционные издержки, простота подготовки и настройки, возможность потоковой передачи, оплата по мере использования и обещание почти бесконечного масштабирования делают его популярным выбором среди разработчиков, создающих приложения с использованием Lambda и API Gateway, в отличие от более традиционного маршрута СУБД.

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

Каковы основные различия между каждым подходом?

Давайте начнем с обзора того, что каждый включает в себя:

1. Несколько таблиц — Одна таблица для каждого типа объектов. Каждый элемент (строка) сопоставляется с одним экземпляром этой сущности, а атрибуты (столбцы) одинаковы для каждого элемента. Это то, как большинство людей привыкли думать о моделях данных, и, по моему неподтвержденному опыту, это наиболее распространенный подход.
2. Одна таблица — Одна таблица обслуживает все приложение или службу и содержит несколько типов сущностей. Каждый элемент имеет различные атрибуты, установленные для него в зависимости от его типа сущности. Я считаю, что этот подход менее распространен (по крайней мере, с точки зрения статей и примеров кода в Интернете), и его определенно сложнее понять большинству новичков в DynamoDB. Но что особенно важно, именно этот подход поддерживает команда AWS DynamoDB (несколько безоговорочно) в своих официальных документах:

В приложении DynamoDB следует поддерживать как можно меньше таблиц. Для большинства хорошо разработанных приложений требуется только одна таблица .

Основными преимуществами дизайна с одной таблицей являются более высокая производительность чтения и записи в масштабе и более низкие расходы на оплату счетов за облако. В основе его шаблона проектирования лежит концепция «перегрузки индекса». Это означает, что один индекс (как глобальный вторичный, так и локальный вторичный) в вашей одной таблице может использоваться для поддержки нескольких различных шаблонов запросов. Это позволяет выполнять SQL-подобные запросы JOIN, в результате чего несколько связанных сущностей извлекаются за одно обращение к базе данных. Этот шаблон невозможен в одной сущности на табличную модель. Во-вторых, поскольку индексы многоцелевые, в целом требуется меньше индексов. Это означает, что при выполнении записи требуется обновлять меньше индексов, что приводит как к более быстрой записи, так и к снижению затрат на выставление счетов.

Я ценю, что это было очень краткое введение в дизайн с одной таблицей, поэтому, если вы совершенно не знакомы с этим и все еще задаетесь вопросом: «Как вы можете втиснуть разные сущности в одну и ту же таблицу базы данных?», Пожалуйста, ознакомьтесь с ссылками. в разделе ресурсов ниже.

Мой опыт работы с обоими подходами

До середины 2019 года я когда-либо использовал многотабличный подход к моделированию данных только в DynamoDB и вообще в базах данных NoSQL в целом (ранее я регулярно использовал MongoDB). С тех пор я работал над несколькими новыми проектами, в которых используется модель данных с одной таблицей для поддержки приложений, ориентированных на транзакции.

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

Прежде чем будут подготовлены какие-либо таблицы базы данных или написана хотя бы одна строка кода, в первую очередь необходимо спроектировать модель данных. В официальной документации DynamoDB указано следующее общее руководство для любого типа дизайна NoSQL:

.

… вам не следует начинать разработку схемы, пока вы не знаете, на какие вопросы она должна будет ответить. Понимание бизнес-проблем и вариантов использования приложений очень важно.

Это второе предложение поразило меня, когда я впервые прочитал его. Я работаю почти исключительно над гибкими проектами, где изменения, связанные с отзывами клиентов, являются нормой. Значит ли это, что DynamoDB (и NoSQL в целом) полностью исключены для меня в этих проектах? Короткий ответ на этот вопрос — «нет», и существуют стратегии управления изменениями (о которых я расскажу позже), но никуда не деться от того факта, что с DynamoDB больше возможностей для создания больших планов, чем с использованием базы данных SQL. Но преимущества «безсерверности» DynamoDB по сравнению с РСУБД, которые я описал во вступительном абзаце выше, перевешивают влияние этих предварительных усилий по проектированию, ИМХО.

Что касается инструментов, я использую электронную таблицу для определения своего проекта, и многие эксперты DynamoDB делают то же самое. AWS недавно выпустила новый инструмент DynamoDB NoSQL Workbench, который на момент написания этой статьи находится в предварительной предварительной версии, но мы надеемся, что он обеспечит немного больше структуры для процесса проектирования моделирования данных.

Итак, каков процесс создания вашей модели данных? У Джереми Дейли есть отличный список из 20 шагов для проектирования модели DynamoDB с использованием подхода с одной таблицей, который я рекомендую вам проверить, так как он быстро читается. В частности, шаги 11–14 должны дать вам представление о требуемом уровне строгости:

Принятие решения о составе ваших индексных полей является ключевым для всего процесса проектирования и потребует многих итераций. Вам необходимо рассмотреть все ваши шаблоны доступа для всех сущностей, чтобы придумать окончательный дизайн.

Основное различие схем между моделями с одной и несколькими таблицами заключается в том, что у одной таблицы будут атрибуты с общими именами, которые используются для формирования раздела таблицы и ключа сортировки. Это необходимо, поскольку разные типы сущностей, скорее всего, будут иметь разные имена полей первичного ключа. Общепринятым соглашением является использование атрибутов с именем 9.1096 pk и sk , которые соответствуют разделу таблицы и ключам сортировки соответственно. Подобные атрибуты с общими именами могут использоваться для составных ключей, составляющих GSI или LSI.

Управление инициализацией и конфигурацией

Итак, теперь у нас есть разработанные модели данных, теперь пришло время подготовить наши таблицы. Это, вероятно, самый простой шаг всего процесса разработки. DynamoDB имеет хорошую поддержку CloudFormation, что упрощает использование инфраструктуры как кода. С помощью нескольких строк YAML и команды развертывания CLI вы можете быстро подготовить свои таблицы и индексы DynamoDB вместе с соответствующими привилегиями управления доступом IAM менее чем за минуту. Я использую Serverless Framework, который позволяет встраивать сырой CloudFormation в ресурсов разделов.

В этой области подход с одной таблицей выигрывает с точки зрения меньшего количества конфигурации для управления и более быстрой подготовки — мне нужно только определить одну таблицу и передать ее имя в мои функции Lambda в качестве переменной среды. В многотабличном подходе у меня есть переменные конфигурации и среды для каждой отдельной таблицы. Незначительное преимущество во всей схеме вещей, но все же приятное.

Реализация доступа к данным в кодовой базе

Теперь ваша база данных развернута, и пришло время начать общение с ней из вашего приложения. Скорее всего, у вас будут объекты сущностей домена, которые вы передаете в своем коде (например, в полезной нагрузке запроса/ответа API или сообщениях SNS/SQS). Если вам нужно сохранить эти объекты в своей базе данных, вы можете использовать для этого один из SDK AWS DynamoDB более высокого уровня (например, DocumentClient для Node.js). Но здесь есть несколько ключевых различий между многостоловыми и одностоловыми конструкциями…

Запись объектов в базу данных

В дизайне с несколькими таблицами часто можно просто записать объект домена в памяти непосредственно в базу данных без какого-либо сопоставления. Поля вашего объекта станут атрибутами вашего элемента DynamoDB. Иногда вам может понадобиться создать объединенное составное поле, которое используется в индексе, чтобы обеспечить поддержку определенного требования фильтрации или сортировки. Однако в дизайне с одной таблицей всегда будет какое-то сопоставление, которое вам нужно выполнить во время записи. В частности, вам нужно будет добавить 2 новых поля pk и sk в объект домена, прежде чем сохранять его в DynamoDB. Если вы используете другие общие поля составного индекса, вам также нужно будет сделать то же самое для каждого из них. Значения этих полей должны соответствовать форматам, определенным в вашей электронной таблице модели данных. Я обнаружил, что обычно мне нужно объединить статический префикс (который однозначно идентифицирует тип объекта и предотвращает конфликты) с одним или несколькими полями из моего доменного объекта, которые мне нужно отфильтровать или отсортировать.

Частичные обновления предметов снова стали более сложными. Учитывая, что в дизайне с одной таблицей существует дублирование данных в каждом элементе , если вы используете API DynamoDB UpdateItem для обновления одного поля, вам необходимо проверить, используется ли это поле также в составном индексированном поле, и если да , также обновите значение составного поля. Я несколько раз забывал об этом, и это может быть довольно сложно исправить.

Чтение объектов из базы данных

Когда вы возвращаете элементы из DynamoDB (через вызовы GetItem или Query API), вы почти всегда захотите удалить составные индексированные поля, прежде чем, скажем, вернуть сущность вызывающему клиенту ваш API. К сожалению, вызовы API DynamoDB не позволяют заносить в черный список атрибуты, которые вы не хотите возвращать. Поэтому вместо этого вам нужно либо внести в список разрешенных все остальные поля, которые вы хотите вернуть (используя ProjectionExpression ) или вы делаете черный список в своем коде приложения после возврата запроса. Я обычно выбираю последний вариант, так как он требует меньше кода, несмотря на то, что он немного менее производительный (поскольку данных возвращается больше, чем мне нужно).

Стратегии управления сложностью кода в однотабличном дизайне

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

В бессерверных приложениях я обычно структурирую свой код таким образом, чтобы обработчик Lambda передавался модулю модели/службы, который затем отвечал бы за доступ к данным, а также за взаимодействие с любыми другими нижестоящими службами (SNS и т. д.). Если ваш код доступа к данным становится достаточно сложным (что легко может произойти после введения составных полей), есть смысл использовать шаблон репозитория, при котором вы создаете модули, единственной обязанностью которых является выполнение операций DynamoDB для определенного типа объекта.

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

Миграция схемы

Это сценарий, о котором вас предупреждали официальные документы AWS. Те варианты использования в бизнесе, которые вы полностью понимали в начале проекта, изменились! Вам нужно внести изменения в существующие шаблоны доступа — возможно, изменить порядок сортировки или фильтр по другому полю. В целом, решение этой проблемы будет включать одно или оба из следующего:

• Создание нового индекса GSI/LSI, указывающего на новые поля (при желании также удаление существующего индекса, который больше не нужен)
• Написание сценария миграции, который сканирует таблицу и выполняет обновления для каждого элемента, например изменение значения составного индексированного поля.

После того, как новые индексы/составные индексированные поля будут установлены, можно будет развернуть обновления кода приложения. Затем вы можете запустить сценарий очистки, чтобы удалить старые составные поля/индексы.

Такой сценарий миграции может быть сложным в управлении, особенно в однотабличном проекте, который сильно зависит от составных индексированных полей. Операции полного сканирования таблицы могут занять много времени. Таким образом, во время работы ваша база данных будет находиться в несогласованном состоянии: некоторые элементы будут исправлены, а некоторые — нет. Возможно, вам придется написать свой сценарий таким образом, чтобы он мог работать с меньшими пакетами/разделами и убедиться, что он идемпотентный (например, путем сохранения состояния где-то, чтобы показать, какие миграции были применены или какие элементы уже были исправлены). Кроме того, я не смог найти каких-либо известных инструментов, которые в настоящее время помогают в этом так же, как Rails ActiveRecord Migrations работает с базами данных SQL.

Я еще не сталкивался с этой проблемой в рабочей среде после запуска, поэтому я не изучал подробно, какие решения в настоящее время доступны для этого. Если у вас есть хорошая стратегия управления миграцией схемы, сообщите мне об этом в комментариях.

Интеграция с другими хранилищами данных

Еще одна проблема, влияющая на схемы с одной таблицей, заключается в том, что некоторые управляемые службы со встроенной интеграцией для экспорта данных из DynamoDB (для аналитики) ожидают, что каждая таблица будет сопоставлена ​​с одной сущностью домена. Экспорт одной таблицы, содержащей объекты различной формы, просто не будет работать без специального промежуточного шага для выполнения преобразования. Примером этого является интеграция DynamoDB с Redshift. Это может быть то, что вам нужно учитывать при выборе подхода к дизайну.

Когда следует использовать любой из подходов?

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

Чрезмерно упрощенная официальная фраза AWS «Большинству хорошо разработанных приложений требуется только одна таблица» не передает нюансы этого решения, ИМХО. Это означает, что если вы не используете подход с одной таблицей, ваше приложение плохо спроектировано. Но их определение «хорошо спроектированного» учитывает только производительность, масштабирование и затраты на выставление счетов, игнорируя другие факторы, влияющие на общую стоимость владения приложением.

Итак, для меня все сводится к ответу на вопрос — что вы хотите оптимизировать:

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

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

Подход с несколькими таблицами является более удобным для разработчиков, имеющих опыт работы с РСУБД (а это большинство разработчиков). Добавление подхода к проектированию с одной таблицей увеличивает крутизну кривой обучения. Добавьте к этому жесткость, вызванную созданием перегруженных индексов, и накладные расходы, если необходимо выполнить какие-либо миграции, и я думаю, будет справедливо сказать, что для большинства команд они быстрее выпускали бы приложение, используя подход с несколькими таблицами

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

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