Если проекты, документы, статьи и показатели хранить одинаково как «страницы», со временем становится трудно искать, фильтровать, обновлять, связывать и архивировать содержание.
Коротко
1. соберите реальные примеры; 2. найдите повторяющиеся структуры; 3. отделите сущность от отображения; 4. определите обязательные поля; 5. определите жизненный цикл; 6. определите связи; 7. не создавайте новый тип без устойчивой причины.
Когда нужен отдельный тип
Если сущности:
- встречаются несколько раз;
- имеют устойчивые поля;
- имеют отдельные статусы;
- должны искать/фильтровать отдельно;
- имеют связи с другими сущностями.
Примеры
Проект
- название;
- назначение;
- аудитория;
- статус;
- роль Qaz Support;
- подтверждённый результат;
- внешний сайт.
Показатель
- название;
- определение;
- значение;
- единица;
- период;
- география;
- источник;
- методика;
- ограничения.
Документ
- название;
- тип;
- дата;
- версия;
- статус;
- файл;
- предыдущая версия.
Структурированное поле или текст?
Поле стоит выделить отдельно, если его нужно фильтровать, сортировать, переиспользовать, проверять, связывать или выводить в API.
Обязательные поля
Делайте обязательным только то, без чего сущность нельзя безопасно опубликовать.
Показатель без источника – блокировать.
Проект без измеренного общественного эффекта – допустим, потому что это необязательное поле.
Не привязывайте контент к дизайну
Плохие поля:
- текст в левой синей колонке;
- большой блок под картинкой.
Хорошие:
- ключевой результат;
- ограничение;
- источник.
Контент должен пережить редизайн.
Базовые типы Qaz Support
- Страница
- Материал базы знаний
- Решение
- Проект
- Показатель
- Источник
- Набор данных
- Методика
- Документ
Краткий итог
Отдельный тип нужен, когда у сущности есть собственные данные, собственные правила и собственный жизненный цикл.
Следующий материал: Как разобрать существующий сайт перед переработкой →