Есть проект, который планируется воскресить. Не хайлоад, конечно, но на миддл-лоад есть надежды.
Сроков и дэдлайнов нет, потому можно спокойно позаниматься долгосрочными инвестициями в качество кода и архитектуры.
И вот возник вопрос, как лучше хранить статьи. Разрываюсь между тремя вариантами:
1. В поле "content" лежит весь текст. Где-то в тексте вставлен тег "". Из БД всё выбирается в полном виде, и потом обрезается до этого тега во View.
2. Два отдельных поля - "announcement" и "body". В "announcement" - начало статьи, в "body" - продолжение.
3. Два отдельных поля - "announcement" и "content". В "announcement" - тизер к статье, в "content" - текст. Этакий "журнальный" вариант.
Вот и всё думаю, к какому варианту склониться. В плане реализации - все просты. Но как будет обстоять дело в дальнейшей эксплуатации?
Поделитесь опытом, дамы и господа, будьте столь любезны.
Во мне он тоже больше всего нравится.
При этом "content" можно вообще хранить в другой таблице или БД, что, как мне кажется, благоприятно отразится на общей производительности.
Первый однозначно плохой: двойная (как минимум) большая выборка, из которой на каждом этапе нужна лишь часть информации. Вывод: лишние ресурсы бекенда на разрезание и обработку, плохой cache БД, завышенный трафик между БД и бекендом.
Второй и третий имеют право на жизнь) Если хотите сделать аналог хабраката - то и второй и третий подходят, но я бы выбрал третий, чтобы в любое время можно было обойтись одним sql запросом.
Но, на самом деле, к производительности это почти никак не относиться)
Третий вариант. Анонс не всегда будет началом, иногда придётся его переписать. Бывает, что присылают статьи с изображениями/таблицами вначале. Или результаты спортивных состязаний. Нет необходимости их включать в анонс, однако они идут вначале.
На этапе заполнения можно предложить автозаполнить поле анонса по первым нескольким предложениям (по умолчанию), но однозначно это поле должно быть отдельным.
Простой
Простой
Средний
Простой
Простой
