Решение о том, следует ли мне разбить таблицу

Question

Я создаю сайт с несколькими языками

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

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

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

Будет ли это приносить мне прирост производительности в Microsoft SQL?

Answer 1

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

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

Answer 2

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

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

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

Не оптимизируйте проблему, пока у вас не возникнет проблема.

Answer 3

Я рекомендую проверить эти две вещи:

• индексируется ваша таблица правильно? Если нет, проиндексируйте его.
• В настоящее время вы видите проблему с производительностью (при условии ее правильной индексации)?

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

Answer 4

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

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

Answer 5

Согласен - я предпочитаю решать проблемы, которые являются актуальными проблемами.

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