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

Question

У меня есть 5 баз данных, которые представляют разные регионы страны. В каждой базе данных есть несколько сотен таблиц, каждая с 10 000-2 000 000 записей транзакций. Каждая таблица является представлением клиента в соответствующем регионе. Каждая из этих таблиц имеет одинаковую схему.

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

Есть ли лучший способ?

EDIT

В ответ на комментарии (я также опубликовал это как ответ на ответ):

В большинстве случаев я не буду удалять таблицы, они останутся для исторических целей. Как я написал в комментарии к одному ответу, идея состояла в том, чтобы сократить время, которое требуется меньшим клиентам (у одного только 10 000 записей), чтобы запросить их собственную историю. Приблизительно 1000 клиентов имеют в среднем 1 000 000 строк (и их число растет). Если бы я добавил все записи в одну таблицу, в этой таблице было бы почти миллиард записей. Я также думал, что планирую на будущее, потому что, когда мы получаем, скажем, 5000 клиентов, у нас нет одной гигантской таблицы, содержащей все записи транзакций (это может быть ошибкой в ​​моем представлении). Так что же, лучше не делить записи, как я сделал? Должен ли я смешать все это в одном столе? Поможет ли индексация по идентификатору клиента задерживать запрос данных для небольших клиентов?

Answer 1

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

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

---

Изменить, чтобы ответить на комментарий к этому сообщению:

Одна таблица с 10 000 000 000 строк в ней будет работать нормально, если вы используете правильную индексацию. Серверы баз данных созданы для работы с такими объемами.

Производительность определенно не является веской причиной для разделения одной такой таблицы на тысячи меньших!

Answer 2

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

Почему вы вообще добавляете или удаляете таблицы? Это не должно происходить ни при каких нормальных обстоятельствах.

Answer 3

Согласен с Бранном,

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

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

Answer 4

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

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

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

Вот несколько сообщений на эту тему.

Каковы преимущества использования единой базы данных для КАЖДОГО клиента?

http://msdn.microsoft.com/en-us/library/aa479086.aspx

Answer 5

2 решения 1. Напишите хранимую процедуру, которая создаст для вас представление, проанализировав все имена таблиц в 5 базах данных, и создайте представление с помощью union, как вы это сделали бы вручную.

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