По сути, изображение ниже представляет компоненты на главной странице сайта, над которым я работаю, где повсюду будут размещаться новостные компоненты. Фрагменты sql представляют, как я думаю, что они должны работать, хотя я был бы очень признателен за советы по бизнес-логике от людей, которые раньше работали с новостными сайтами. Вот как я это себе представляю:
Вопрос № 1 : Имеет ли смысл логика sql? Есть какие-нибудь предостережения / недостатки, которые вы можете увидеть?
Моя схема будет выглядеть примерно так:
articles:
article_id int unsigned not null primary key,
article_permalink varchar(100),
article_name varchar(100),
article_snippet text,
article_full text
article_type tinyint(3) default 1
Я бы хранил все статьи (основные, второстепенные, остальные) в одной таблице, я бы классифицировал их по столбцу type, который будет соответствовать номеру в моей таблице news_types (для примера Я использовал буквальный текст, так как это легче понять).
Вопрос № 1.1 : Можно ли полагаться на одну таблицу для разных типов статей?
Новостная статья может иметь 3 типа изображений:
- 1x исходный размер изображения, который будет отображаться только на странице с постоянной ссылкой
- 1x основное изображение, которое будет отображаться в разделе главной страницы # 1
- 1x дополнительное изображение, которое будет отображаться в разделе домашней страницы # 2
Пока я хочу, чтобы каждая статья соответствовала одному изображению, а не нескольким. Пользователь может публиковать изображения для статьи в столбце article_full TEXT.
Вопрос # 1.2 : Я не уверен, как мне следует включать изображения статей в мою схему, является ли это обычным делом для схемы, основанной на 2 таблицах, подобных этой?
article_image_links:
article_id article_image_id
1 1
article_images:
article_image_id article_image_url
1 media.site.com/articles/blah.jpg
Требования к данным:
Исходя из того, как у меня есть логика sql, должны быть какие-то данные, чтобы вещи могли отображаться ..
- должен быть хотя бы один
main тип статьи
- должно быть не менее четырех
featured статей типа, которые находятся ниже основного
Вопрос № 1.3 : Стоит ли создавать особые случаи, если данные отсутствуют? Например, если нет основной статьи, следует ли выбрать самую последнюю, или я должен требовать, чтобы кто-то всегда указывал основную статью?
Вопрос # 1.4 : В администраторе, когда пользователь отправляет сообщение, по умолчанию у меня будет выпадающий список, в котором указывается тип статьи, normal будет предварительно выбран и будет иметь опция для main и featured. Поэтому, если пользователь в какой-то момент решит изменить тип статьи, он / она сможет это сделать.
Вопрос # 1.5 : Мои избранные статьи и основные статьи работают только в последнюю дату. Если пользователь хочет, например, указать более старую статью по какой-либо причине в качестве основной статьи, должен ли я создать собственную логику или просто сказать ему обновить дату статьи, чтобы она была позже последней?