меня всё время беспокоит один отвлечённый вопрос

допустим, есть форум по типу винградовского. есть отдельная таблица постов, есть отдельная таблица разделов, есть таблица топиков, есть таблица статей. также допустим на сайте введено множество сущностей, которые также представлены списком в БД - таблицей: сохранённые изображения, ролики, сохранённые ссылки, список тэгов и т.д. и т.п. сущностей можно придумать много

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

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

вопрос: что лучше, создавать под каждую связь свою таблицу (table `image_link`: `image`,`entity`,`id`)
или иметь одну таблицу на все связи (table `common_linx`: `entity1`, `id1`, `entity2`, `id2`)

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

Стандартная дилемма - универсальность против эффективности. Общего ответа имхо нет.

ну, мне тут универсальность ни к чему, главное - эффективность

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

а вот с точки зрения эффективности - что лучше?

Денормализация

  

не тереби его

Частное решение под частный случай, пожалуй, всегда эффективнее общего решения под общий случай.


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

хорошо:

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

не от балды же требования выставляются

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

Это сообщение отредактировал(а) Zloxa - 7.3.2013, 09:54

спасибо, твой совет неоценим