Вопрос по архитектуре базы данных: 1 таблица на клиента или 1 уникальная таблица для всех клиентов

Question

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

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

У нас будет около 10 тысяч клиентов, у каждого из которых может быть около 50 тысяч продуктов.

Обработка продуктов может быть неодинаковой для каждого клиента, и мы также хотели бы предоставить план, где клиенты могли бы иметь доступ API к своим данным.

Наши клиенты продают продукты, и их структура таблиц SQL будет иметь такие столбцы, как:

• FEED_ID
• PRODUCT_ID
• PRODUCT_DESCRIPTION
• Цена
• Вес
• и т.д ...

Feed_ID используется для дифференциации происхождения этих продуктов и будет уникальным для каждого клиента - конечно.

3 варианта структуры реляционных таблиц, о которых мы думали:

1. У каждого клиента есть своя собственная база данных, и в этой базе данных он имеет 1 таблицу на каждый канал продукта

2. Все клиенты размещены в 1 уникальной базе данных, в которой у всех клиентов есть 1 таблица на фид - в этом случае 1 клиент может иметь 2 таблицы, если он представляет собой 2 разных фида продуктов.

3. Все клиенты размещаются в 1 уникальной базе данных, ОДНАКО, в этом 3-м решении у нас есть только 1 уникальная таблица, в которой размещается весь поток продуктов всех клиентов.

Какое решение вы бы использовали и почему вы считаете, что выбранное вами решение лучше?

Спасибо.

Answer 1

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

По поводу недостатков:

• Управлять им сложнее, но не так плохо - вы можете написать скрипт для создания столбцов / таблиц / индексов / и т.д. Вы не нужно делать это вручную.
• Будет сложно выполнить аналитику для таблиц 10K, хотя в любом случае это не лучшая идея смешивать это с производством. Я бы создал отдельную базу данных (или сервер) для аналитики, запустив некоторая ночная работа по обновлению таблиц отчетности.

Кроме того, если ваша таблица будет иметь сотни миллионов строк (10Kx50k?), Будет хорошей идеей разбить ее на более мелкие части независимо от того, какой вариант вы выберете. Если не по клиенту, то по региону или какой-либо другой большой группе (при условии, что вы строите на базе РСУБД)

Answer 2

Вы не предоставили достаточно информации. Почти при любых обстоятельствах (см. Ниже исключения) вам нужен один набор таблиц для всех клиентов. Вот несколько причин:

• Производительность. Распространение таблиц означает, что данные распределяются по большему количеству страниц данных, поэтому у вас есть много частично заполненных страниц данных. База данных больше, а обработка медленнее.
• Эффективность кодирования. Если все таблицы для клиентов имеют разные имена, тогда весь код является динамическим SQL. Это сложнее поддерживать.
• обслуживание. Добавление столбца или индекса очень трудоемко при наличии миллиардов похожих таблиц.
• Analytics. Когда подобные данные распространяются по таблицам, очень трудно ответить на такие вопросы, как «Какой клиент имеет больше продуктов?».
• Security. Предоставление прав доступа для одного набора таблиц менее подвержено ошибкам, чем для миллиардов таблиц.

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

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

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

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

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

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