Схема базы данных. Создайте один большой стол или много?

Question

Я пытаюсь решить, как лучше хранить объекты, которые имеют очень похожие свойства. Основное отличие состоит в том, что каждый объект ссылается на другие объекты. Я собирался настроить базу данных как:

entity_a (1-1,000 Records) [Data rarely changes] 
id|created|updated|entity_b_id|category_id|name|entity_b_id|entity_c_id|entity_d_id 

entity_b (10,000-1,000,000 Records) [Data changes constantly] 
id|created|updated|entity_b_id|category_id|name|entity_c_id|entity_e_id|entity_f_id 

entity_c (10,000-10,000,000 Records) [Data changes constantly] 
id|created|updated|entity_b_id|category_id|name|entity_a_id|entity_f_id 

entity_d (0-1,000 Records) [Data rarely changes] 
id|created|updated|entity_b_id|category_id|name 

entity_e (1-100 Records) [Data rarely changes] 
id|created|updated|entity_b_id|category_id|name|entity_a_id|entity_b_id 

entity_f (0-50,000 Records) [Data frequently changes] 
id|created|updated|entity_b_id|category_id|name|entity_c 

entity_g (10-100 Records) [Data rarely changes] 
id|created|updated|entity_b_id|category_id|name 

entity_h (10-1,000 Records) [Data rarely changes] 
id|created|updated|entity_b_id|category_id|name|entity_e_id 

entity_i (1-10 Records) [Data rarely changes] 
id|created|updated|entity_b_id|category_id|name 

Но это было предложено, что было бы легче управлять одной большой стол, как:

ent (20,000-11,000,000 Records) 
id|created|updated|ent_id(b)|category_id|name|ent_id(a)|ent_id(b)|ent_id(c)|ent_id(d)|ent_id(e)|ent_id(f) 

Обеспокоенность этим вторым способом является размер таблицы, как id будет int (11), и будет шесть столбцов этих идентификаторов, которые будут в основном заданы как 0.

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

Любая помощь была бы очень признательна.

Answer 1

Я думаю, что трудно предсказать фактическое исполнение одного и другого, поскольку оно зависит от многих вещей.

Несколько соображений:

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

Если у вас есть запросы, которые выбираются на другие вещи, чем общие столбцы, например: entity_a with entity_c IN(something), вам понадобится индекс в столбце entity_c.

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

Если вы делаете много СОЕДИНЕНИЙ, я уверен, что нормализованная форма выполняется быстрее.

Мой совет: использовать нормализованную форму. Если вы видите проблемы с производительностью, вы можете посмотреть это решение.

Вы также можете пойти на гибридное решение. Поскольку b и c часто меняются, а другие нет: создайте две таблицы. Или дайте b и c его собственный стол, но сохраните остальных в одном.