Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Приветствую! Пилю свою простую CMS на Laravel, пригодную для большинства сайтов и легко расширяемою(ну, как минимум для меня). Подобрал более менее удачную структуру БД, но мне не дает покоя мысль о том как ее можно улучшить. В общем в примитиве все выглядит так :
имеем таблицу pages элементы которой могут ссылаться на эту же таблицу,
имеем поля
page_id - для связи элемента дабы иметь возможность создавать иерархическую структуру,
url - для ссылок,
full_url - заполняется и правиться автоматически исходя из full_url родителя, у корневых элементов url = full_url. При правке url элемента содержащего дочерние элементы, все full_url у дочерних элементов правятся,
resource_type - для того что бы отделить обычные страницы от статей, новостей и прочего.(используется в основном в админке, так же позволяет выбирать все элементы определенного типа)
То есть благодаря подобной структуре мы при получении запроса можем стразу сказать есть ли подобная страница на сайте и выдать 404 если что не так.
Так вот, сейчас обдумываю как эту структуру можно улучшить, добавить категории со связью многие страницы ко многим категориям и вообще хотелось бы продумать эту систему далее, сделать более универсальной. Проблема добавления категорий заключается в том что по сути у категории не может быть url при текущей структуре, а значит должна быть страница этой категории.
В целом мне подобная организация уже начинает казаться тупиковой, буду благодарен за советы по расширению структуры или как иначе организовать хранение страниц в базе, а так же указания на публикации, статьи и книги посвященные данной тематике(не проектировке БД в целом, а для такого узко направленного случая).
Изменено AwokeN (16.03.2015 20:19:43)
Не в сети
Мне очень понравилась устройство БД у Wordpress, все просто и при этом в этой БД можно реализовать почти все, что захочешь, не создавая новых таблиц.
Изучаю Laravel, до этого дела с фреймворками не имел.
Печальные познания в английском.
Не в сети
Мастер 
в целом для CMS есть два основных способа создания универсальной структуры.
1) WordPress-way.
в вордпрессе всё является постом: прицепленные изображения - это посты, страницы - это посты. фактически реальные блогопосты - это посты с типом "пост". и имеется две таблицы: posts и posts_meta. мета содержит пары ключ-значение, привязанные к постам, и позволяет иметь в постах любые поля. включая поля типа "связь с другим постом", где другим постом может быть например, изображение.
категории и тэги - это отдельная штука типа "таксономия". таксономии могут быть как иерархическими так и нет (используется структура данных nested set), и пост может быть привязан к любому количеству элементов любых таксономий.
2) drupal-way.
в друпале записи имеют фиксированную структуру, а мета-данные привязываются через fields. поля, в отличие от вордпресса, хранятся каждый в своей таблице. фактически добавляя новое поле - мы создаём новую таблицу в базе. это ускоряет выборку - поскольку не нужно больше грузить данные из одной огромной таблицы, но с другой - для записей с большим количеством полей у нас получается запрос подчас с десятками лефт-джойнов.
остальные CMS, насколько я представляю, используют вариации одного из этих двух способов. например, наш отечественный динозавр битрикс использует в своих "инфоблоках" оба и позволяет переключаться между ними в настройках.
Не в сети
Спасибо за подробное разъяснение, по сути я получается двигался в сторону вордпресса. Нужно будет подробнее изучить как там все устроено - я как то работал с ним, но заглядывать под капот к нему всегда было неприятно.
Да, теперь вижу почему он настолько универсален, и понимаю что поддержку подобного хранения данных тоже можно было бы устроить.
Не в сети
Есть еще системы TYPO3 и Neos CMS. Там струкутра сайта - это дерево страниц, подобно файловой системе. На каждую страницу вы можете вставлять различные элементы контента. Это могу быть текст, изображения, формы, плагины и т.д. Компонуя различные элементы контента можно создавать любые страницы. Плюс ко всему, каждая страница имеет определенные свойства. Это могут быть сегмент ссылки ЧПУ, метатеги, название в меню, шаблон страницы (внешний вид) и еще много чего. Такой подход позволяет создавать действительно очень гибкие сайты.
MODx тоже использует дерево страниц, но у него нет элементов контента, которые вставляются на страницу. Это сильно уменьшает его возможности.
Не в сети
В CMS лучше сделать десяток таблиц, нужных в любом сайте. В конкретный проект - недолго и добавить нужное кол-во таблиц.
Какие я бы советовал таблицы:
areas - области страниц (шапка, футер и др.)
emails - адреса, куда сайт будет слать уведовления (например, о сообщении с формы обратной связи)
feedbacks - сообщения с форме обратной связи
items - пункты меню
languages - языки (человеческие) сайта
pages - страницы сайта
galleries - фотогалереи
photos - фотографии фотогалереи
galleries_in_pages - связь
photos_labels - подписи к картинкам фотогаалереи
Структуру таблиц могу прислать, если интересно
Не в сети
В CMS лучше сделать десяток таблиц, нужных в любом сайте. В конкретный проект - недолго и добавить нужное кол-во таблиц.
Какие я бы советовал таблицы:
areas - области страниц (шапка, футер и др.)
emails - адреса, куда сайт будет слать уведовления (например, о сообщении с формы обратной связи)
feedbacks - сообщения с форме обратной связи
items - пункты меню
languages - языки (человеческие) сайта
pages - страницы сайта
galleries - фотогалереи
photos - фотографии фотогалереи
galleries_in_pages - связь
photos_labels - подписи к картинкам фотогаалереиСтруктуру таблиц могу прислать, если интересно
Если не сложно, скиньте пожалуйста структуру таблиц.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)