У меня на сайте имеются разделы. Их около 7 (Анекдоты, картинки, загадки и тд.)
Таблицы под каждый раздел немного отличаются друг от друга, немного)

Я решил на главной странице сделать так, чтобы выводились последние материалы из ВСЕХ 7-ми таблиц.

Подскажите, как лучше быть?
1. Создать 1 таблицу, и впихнуть туда 7 мелких? Чтобы была каша? Но зато для вывода потребовалась бы 1 несложный запрос?
2. Либо же оставить эти 7 таблиц по отдельности, и как-то одним запросом выводить материалы сразу из 7 таблиц?

Если выбирать второй вариант, то вот как я соединяю таблицы:

mysql_query("SELECT id FROM joke UNION SELECT id FROM zagadki");

Вроде работает, но мне сказали что лучше избегать JOIN-ы, а UNION это походу тоже самое что и джоин?

Возможно в моём случае джоин не так страшен, так как нет никакой связи между строками первой таблицы и второй в виде tb1.id = tb2.user_id

Кто что может сказать? Как мне лучше поступить? И второй вариант будет ли ложить БД, если нужно селектить 7 таблиц? Либо же всё запихать в 1 таблицу, и делать 1 селект запрос без джоинов?

Смотря как часто обновляются эти 7 таблиц, если редко, то можно создать одну таблицу и каждые 5-30 минут обновлять её.

У этих 7 таблиц связи есть какие? Если нет, то зачем их объединять, делайте запросы к каждой таблице по отдельности, указывая DESC и LIMIT

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

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

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

Ну сами данные в таблицах обновляются очень редко, я бы даже сказал не обновляются, а добавляются)
Просто если людей будет заходить на сайт очень много, и каждый вместо 1 запроса будет брать ещё +6 дополнительных, то это мне кажется плохо...

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

AllesKlar
Тоесть ты хочешь сказать лучше объеденить все таблицы вместе, и сделать кашу?

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

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

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

AllesKlar

Этот файл будет находиться в памяти. Даже на диск нагрузки не будет.

_____________
Все будет офигенно. Кому-то сразу, кому-то постепенно.

AllesKlar
Тоесть 1 таблицу делать?
Просто если человек зайдёт на страницу одного типа, то ему придётся всю эту таблицу селектить, чтобы отобрать нужный материал)

Тоесть так бы он селектил только 1 таблицу с 1000 записями, а так он будет селектить тоже одну таблицу, но уже с 7000 записями, и отбирать из них type = 1

Тоесть всё равно вариант с 1 таблицей лучше всего?

Нормализованные таблицы + индексы. И хоть 1 000 000 записей
Помимо прочего, СУБД тоже не дураки пишут, (зависит от базы) в большинстве случаев запрос будет закеширован тоже

_____________
[продано копирайтерам]

AllesKlar
Ну у меня индексы только на id стоят)
...
А можно как-то с тобой связаться?) ну ася там, или ВК?
Ну или хотябы скайп - но не желательно

Karamba666
Нельзя, конечно же.
Формат форума подразумевает помощь, советы. ты принимаешь решение и делаешь сам. участники помогают, критикуют. Ты набираешься опыта и однажды сам начинаешь помогать другим.

Либо ты постишь свою проблему в разделе Проекты http://phpforum.su/index.php?showforum=112 с указанием бюджета.
На форуме много толковых ребят, которые за денюжку сделают вместо тебя все в лучшем виде.
Мне же подобные "шабашки" лет 10 как не интересны.

Я же... советом помогу, а частная беседа, после трудовой недели, в выходной... не понянешь финансово

Без обид.

Я тебе сказал: выкладывай структуру таблиц. народ подтянится, коллективным разумом сделают тебе из ... твоей базы конфетку.

_____________
[продано копирайтерам]

Вот как раз здесь хорошо подойдет MongoDB, поскольку картинки, истории, анекдоты - это скорее всего конечные сущности (то есть документы в чистом виде). И никак друг с другом или еще как-то особо не связаны, чтобы хотеть реляционку. Получится один или два "синтетических" джойна, причем легких. Чисто для маппинга к категориям ну и еще там чего-нть, ХЗ чего там в проекте.

Зато schemaless решение позволит очень легко удалять/добавлять поля из/в "схему", тем самым обеспечивать столько различных сущностей, сколько потребуется. Хоть сотню. А контролировать можно хоть через entity, хоть специальными документами - контрактами, назовем их так. Они же могут быть и категориями, кстати. Смотря насколько абстрактно всё делать. Единственное с чем вероятно возникнут сложности это не с выборкой, а с отображением (внезапно) одной кучей. Вот где будет хитрая задачка-то! Тут нужно покумекать с шаблонизатором, реализовать своего рода sass-овские миксины. Либо фетчить различные файлы по условию. Но тут хардкод, без него обойтись проблематично, слушай... =( Запихивать в контракт отдельным полем/свойством partial которым он должен рендериться? Думать надо.


Кстати, выборка из нескольких sibling таблиц вообще через джойны не делается. А UNION это не джоин