Цитата(bars80080 @ 4.3.2013, 12:15  ) |
| меня всё время беспокоит один отвлечённый вопрос |
не тереби его
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > выбор системы связей |
| Автор: bars80080 4.3.2013, 12:15 | ||
| меня всё время беспокоит один отвлечённый вопрос допустим, есть форум по типу винградовского. есть отдельная таблица постов, есть отдельная таблица разделов, есть таблица топиков, есть таблица статей. также допустим на сайте введено множество сущностей, которые также представлены списком в БД - таблицей: сохранённые изображения, ролики, сохранённые ссылки, список тэгов и т.д. и т.п. сущностей можно придумать много все сущности могут ссылаться друг на друга. к примеру, одна картинка может относиться, как сообщению, так и к статье, также на неё могут ссылать некоторые теги. а на один гиперлинк могут ссылаться разные посты и статьи. далее, демонстрировать сущность можно под разным соусом. к примеру, можно показать последние несколько сообщений, относящиеся к статье под самой статьёй. а можно показывать те же посты просто в общем потоке сообщений в теме форума. в разных представлениях требуется разный сопроводительный набор окружения. к примеру, в первом случае требуется только набор ссылок, связывающий посты с картинками, а во втором почти все любые связи постов: с другими темами, статьями, картинками, гиперлинками, авторства и т.п. вопрос: что лучше, создавать под каждую связь свою таблицу (table `image_link`: `image`,`entity`,`id`) или иметь одну таблицу на все связи (table `common_linx`: `entity1`, `id1`, `entity2`, `id2`) соответственно, по первому принципу потребуется по запросу на каждую требуемую связь, а их может требоваться и с десяток одновременно. по второму принципу запрос всегда будет один:
|
| Автор: Akina 4.3.2013, 13:04 |
| Стандартная дилемма - универсальность против эффективности. Общего ответа имхо нет. |
| Автор: bars80080 4.3.2013, 17:54 |
| ну, мне тут универсальность ни к чему, главное - эффективность даже на раздробленном варианте можно сделать один скрипт на пхп (я отталкиваюсь от него всегда), который обеспечит единую точку доступа и код практически не придётся переписывать при добавлении новых сущностей. надо будет только добавить одну переменную в список выбираемых параметров а вот с точки зрения эффективности - что лучше? |
| Автор: baldina 4.3.2013, 18:20 | ||
http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
не тереби его |
| Автор: Zloxa 7.3.2013, 08:51 | ||||
Частное решение под частный случай, пожалуй, всегда эффективнее общего решения под общий случай.
Если речь стоит о построении эффективного приложения, лучше сконцентрироваться на том что нужно и пилиться под нужды, обеспечивать возможность реализации нужд. От того, на сколько четко будут определены и выделены первостепенные нужды на этапе проектирования, мне кажется, по большей части зависит успех и стоимость решения. Требования универсальности и гибкости, с моей точки зрения, возникают именно в результате неспособности четко выделить то, что же именно нужно. Так и появляются паровозы с крыльями на гусеничном ходу, которые ни летать не могут, ни по рельсам ездить и в грязи увязают. |
| Автор: bars80080 7.3.2013, 09:36 |
| хорошо: демонстрировать сущность нужно под разным соусом. к примеру, нужно показать последние несколько сообщений, относящиеся к статье под самой статьёй. и нужно показывать те же посты просто в общем потоке сообщений в теме форума. не от балды же требования выставляются |
| Автор: Zloxa 7.3.2013, 09:51 |
| bars80080, ну и пили, собсна структуру так чтобы она позволяла эффективно решать нужные задачи. Если нужно для этого выделить отдельную избыточную сущность - выделяй. Если при этом нужно будет загемороиться согласованностью - гемморойся. Это ведь нужно.  |
| Автор: bars80080 7.3.2013, 11:54 |
| спасибо, твой совет неоценим |