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

Question

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

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

Answer 1

Так много других аспектов влияют на ответ на ваш вопрос. Каков размер стола? ширина? сколько строк? Что такое шаблон использования? Существуют ли разные схемы использования для разных подмножеств столбцов в таблице? (т. е. два столбца попадают 1000 раз в секунду, а остальные 50 столбцов - только один или два раза в день?). Этот сценарий будет основным кандидатом для разделения (разделения) таблицы по вертикали (два столбца в одной таблице, остальные по другому)

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

Answer 2

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

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

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

Answer 3

Конечно, это зависит от типа dbms и ваших фактических данных. Но обычно более маленькие (более узкие) таблицы быстрее, чем меньше более крупных (более широких) таблиц.

Answer 4

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

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

Answer 5

Вы создаете базу данных "только для чтения", например хранилище данных? Если это так, хранение данных «предварительно объединено» может иметь смысл. Для повседневных баз данных OLTP необходимо учитывать производительность и простоту вставки, обновления и удаления. Кроме того, как насчет запросов, которые хотят только данные, которые были бы в одной или двух из меньших таблиц? Теперь им приходится перебирать большой толстый стол, полный вещей, которые им не нужны.

Стоит помнить, что объединение таблиц - это то же самое, что и приличная СУБД - они очень хороши в этом.

Answer 6

То, что верно для оптимизации SELECTS, часто не так хорошо для оптимизации INSERTS, UPDATES и DELETES, и, таким образом, именно с этим подходом. Разбиение данных на должным образом нормализованные таблицы снижает издержки на изменение данных.

Хотя в хранилище данных или в системе поддержки принятия решений мы часто храним предварительно объединенные данные (как говорит Тони), обычно это происходит только в контексте предварительно вычисленного резюме (например, материализованного представления), а не для данных на атомном уровне детализации. Причина этого заключается в том, что вставка повторяющихся длинных символьных строк (например, «Имя поставщика») в таблицу измерений уменьшает общее требуемое пространство хранения и количество физических чтений, необходимых для извлечения данных. Соединения, как правило, являются эквивалентными, и они выполняются практически бесплатно для больших наборов данных.

Answer 7

Помните также, что существует жесткое ограничение на количество данных, которые могут быть сохранены в одной записи. (не зная, какая у вас база данных, я не могу сказать, что это.) Слишком много столбцов, и вы достигнете этого предела. Кроме того, если у вас есть столбцы, такие как phone1, phone2, phone3, то вам нужно нормализовать. Если вам потребуется добавить столбец, если количество элементов, которые нужно вставить в запись, изменится (например, если вам нужно 4, а не 3 телефонных номера), вместо этого необходимо выполнить нормализацию.

Answer 8

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