так во-первых удобнее, во-вторых расширяемее (в случае нужды добавления только для постов к примеру нового поля), да и идеологически правильнее. Спасибо за совет, честно скажу, я читаю книги, как только есть свободное время.В Drupal так же. Полагаю, во всех CMS так же, иначе сложно было бы добавить возможность создавать новые типы на лету.mc-bear писал(а): Вот сижу и не знаю что и думать, авторы WordPress'а олухи не грамотные или то что они засунули посты, страницы и атачменты в одну таблицу это хорошо продуманный шаг
А кому она не нужна? Конечно же умеренно тратя производительностьaser писал(а):Тут действительно наверное стоит исходить из соображений для чего это делается:
1. Нужна ли расширяемость.
Тут пока не очень соображаю как это может играть роли.aser писал(а):2. Количество записей каждого из типов.
2. Количество записей каждого из типов по отношению к другим.
Опять же, если есть возможность использовать кеш, разве кто-то откажется?aser писал(а):3. Использование кеша.
Опять же не вижу разницы во времени. Плюс время есть, т.к. разработка для будущих проектов. Так что не к спеху.aser писал(а):4. Время которое есть на реализацию проекта.
Это и хорошо, т.к. для таких объектов как новости, записки блога, расширяемость и кеш самое то.aser писал(а):Думаю что на цвет и вкус тут товарищей нет. Друпал и ВПрес ставили задачу легкой расширяемости, а кеш позволяет снизить нагрузку до того что не важно насколько сложные запросы.
Если делается сайт с нуля с прописанными четко требованиями зачем мудрить?А кому она не нужна? Конечно же умеренно тратя производительность
Ну смотрите если в базе статей у вас изначально будет висеть > 100 000 статей c пополнением > 200 статей в сутки, в блоге > 2000 с пополнением > 10 в суткиТут пока не очень соображаю как это может играть роли.
Ну если вы делаете презентацию расчитаную на 100 человек в день, то зачем тратить свое время и лишние ресурсы, MySQL и не сложная структура сама все за вас сделаетОпять же, если есть возможность использовать кеш, разве кто-то откажется?
Ну тут думаю что вы ответили сами на свой вопросЭто и хорошо, т.к. для таких объектов как новости, записки блога, расширяемость и кеш самое то.
Отчасти согласен, у меня все компании хранятся в одной таблице, разделенные только по типу (по которому и "выцарапываются" из базы). НО я считаю, что это актуально лишь в том случае, когда все записи абсолютно идентичны по полям.Razunter писал(а):А по-моему, так гибче хранить одной таблицей, когда есть еще таблица "типы" и таблицы для полей... Да, громоздко, но на сложных сайтах иначе получается очень неудобно - редактировать все 20 типов материалов, у каждого свои вьювы, модели, контроллеры...
Хотя для простых сайтов, конечно, лучше отдельными.
) был поднят вопрос про литературу по проектированию БД. Можно всё таки привести примеры подобных книг?
