Что вы думаете о разбиении большой таблицы SQL на несколько на основе определенного идентификатора категории?

Question

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

Другими словами, было бы неправильно разделять таблицу по идентификатору веб-сайта?

Answer 1

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

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

Answer 2

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

• SQL для запросов не изменение.

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

• Можно реализовать самостоятельно резервное копирование / восстановление режимов на при необходимости на основе клиента.

• Легче «масштабировать», перемещая некоторые клиенты на другой сервер, если ты должен.

• Архитектура приложения проще как не должно быть четко осведомлен о клиенте фильтрация в каждом запросе.

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

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

Answer 3

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

В терминах SQL вы никогда не должны разбивать таблицу на основе ее чрезмерной длины (т. Е. Количества строк), но вы можете рассмотреть возможность разбивки таблицы на основе чрезмерной ширины (т. Е. Количества столбцов).

Answer 4

Вы имеете в виду, что хотите иметь BigTableForWebsite1, BigTableForWebsite2, BigTableForWebsite3 и т. Д. Вместо одного BigTableForAllWebsites? Это заставляет меня чувствовать себя немного плохо в моем желудке пурист-базы данных ...

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