Что лучше? Наличие 100 таблиц с каждыми 1000 строк или 10 таблиц с каждыми 10000 строк?

Question

С 10 таблицами у меня не было бы соединений. С 100 таблицами у меня было бы одно соединение на запрос. Что бы показать лучшую производительность?

Answer 1

Я бы не принял проектное решение таким образом, если бы не измеренные данные производительности.

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

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

Если вы считаете, что производительность неприемлема, при необходимости денормализуйте.

Ваш вопрос слишком общий и общий, чтобы принять черно-белое решение.

Answer 2

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

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

Answer 3

Объединения влияют на производительность. Но также наличие избыточных данных - плохая практика. Обновление и вставка данных в таких случаях будет очень проблематичным.

Answer 4

Начнем с правильной схемы. Одна таблица с 100 000 строк, если все, что у вас есть, это одна логическая сущность ....

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

Если все, что вас волнует, это чтение производительность , тем не менее, опять же, ваш лучший выбор - это одна таблица с 100 000 строк - и, кстати, не беспокойтесь об использовании реляционной базы данных, нет Дык, просто храните данные в памяти.

Answer 5

Меньше объединений означает более быстрые запросы выбора. Но если вы делаете какие-либо вставки или обновления, вы, скорее всего, заплатите за аномалии данных или гораздо более дорогие вставки / обновления.

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