Дизайн базы данных: разделение записи в блоге на несколько страниц

Question

Какова лучшая стратегия базы данных для разбиения на страницы записи блога или содержимого страницы, когда некоторые записи могут быть одной страницей, а некоторые могут занимать несколько страниц? Примечание. Контент будет похож на статью, а не на список элементов.

Метод, который я сейчас рассматриваю, заключается в хранении всего содержимого в одном текстовом поле и использовании разделителя страниц, например {pagebreak} . После извлечения содержимое будет разделено на массив разделителем страницы, а затем на странице отобразится соответствующий индекс. Это лучший способ или есть лучший подход?

Answer 1

Самый простой способ (сейчас, но вы заплатите позже) - сохранить всю статью в одном текстовом поле, но вы отказываетесь от некоторого управления отображением, потому что вам может понадобиться добавить немного html в этот текст. Если вы добавите html в текст, у вас будет много данных для исправления, если вы когда-нибудь измените внешний вид вашей веб-страницы. Это не может быть проблемой

Как правило, я стараюсь не помещать html в базу данных. Возможно, вам лучше использовать XML для определения вашей статьи и хранить ее в одном текстовом поле, чтобы ваше приложение могло правильно отображать содержание в динамическом ключе. Вы можете хранить разрывы страниц в XML или позволить приложению читать всю статью и динамически разбивать ее на основе вашего текущего внешнего вида.

Вы можете использовать мою схему "CMS для бедняков" (ниже), если вы не хотите использовать XML. Это даст вам больший контроль над форматированием, чем метод «весь текст в одном поле».

это просто дикая догадка, основанная на вашем вопросе

таблица:

Articles
--------
ArticleID        int  --primary key
ArticleStatus    char(1) --"A"ctive, "P"ending review, "D"eleted, etc..
ArticleAuthor    varchar(100)  --or int FK to a "people" table
DateWritten      datetime
DateToDisplay    datetime
etc...

ArticleContent
--------------
ArticleID     int  --primary key
Location      int  --primary key, will be the order to display the article content, 1,2,3,4
ContentType   char(1)  --"T"ext, "I"mage, "L"ink, "P"age break


ArticleContentText
------------------
ArticleID      int  --primary key
Location       int  --primary key
FormatStyle    char(1)  --"X"extra large, "N"ormal, "C"ode fragment
ArticleText    text

ArticleContentImage
-------------------
ArticleID      int  --primary key
Location       int  --primary key
AtricleImagePath  varchar(200)
AtricleImageName  varchar(200)

Вы все еще можете поместить всю статью в одно поле, но вы можете разделить ее, если она содержит различные типы «вещей».

Если у вас есть статья о PHP-коде с примерами, «метод с одним полем» заставит вас поместить html в текст для форматирования примеров кода. с этой моделью вы сохраняете что к чему и позволяете приложению отображать это правильно. Вы можете добавлять и расширять различные типы, вставлять разрывы страниц, удалять их. Вы можете хранить свое содержимое в нескольких строках «ArticleContentText», каждая из которых представляет разрыв страницы, или включать строки «ArticleContent», которые определяют разрывы страниц. Вы можете позволить приложению читать всю статью, а затем отображать только то, что оно хочет.

Answer 2

Я думаю, что ваша текущая идея будет лучшим вариантом. Упрощает перемещение разрывов страниц, если вы когда-либо захотите, или их вставку при первоначальном написании статьи. Также позволяет вам иметь опцию печати страницы, где вся статья находится в 1 поле.

Answer 3

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

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

Answer 4

Мне кажется, это хорошее решение. Таким образом, вы будете иметь свою статью как единое целое и иметь возможность разбивать ее на страницы при необходимости.

Answer 5

Вам гораздо лучше оставить подобное форматирование на стороне клиента. Пусть база данных хранит ваши данные, а ваше приложение представляет их пользователю в правильном формате.