Current File : //home/bitrix/www/bitrix/modules/main/lang/ru/admin/checklist/QM0010.html
<p>Информационные блоки, сгруппированные по типам, хранят данные проекта: новости, каталоги и другие деревья/списки. От правильной настройки информационных блоков зависят не только удобство управления системой, но и производительность сайта и стоимость его поддержки и сопровождения. (Чем "прозрачнее" схема данных, тем проще ее поддерживать и развивать.) Неиспользуемые возможности желательно отключать.</p>
<p>Проверяем настройки типов информационных блоков: " Контент > Информационные блоки > Типы информационных блоков".</p>
<ol>
<li>Названия типов должны отражать их роль в проекте. Название "Type12" - неудачное, "Новости регионов" (содержит внутри инфоблоки новостей регионов) - говорит само за себя.</li>
<li>В настройках каждого типа на вкладке "Основное" желательно указать названия разделов и элементов данного типа. Если элементами являются, допустим, товары, то название "Новости" для них явно некорректно.</li>
<li>На вкладке "Дополнительно" проверяем, чтобы флаг экспорта в RSS был установлен, когда экспорт действительно необходимо выполнять.</li>
</ol>
<p>Проверяем настройки каждого информационного блока: " Контент > Информационные блоки > Типы информационных блоков > Название инфоблока".</p>
<ol>
<li>Место хранения значений свойств (в общей таблице или отдельной таблице) выбирается в зависимости от решаемых задач и объема данных. Если в списке/дереве ожидается достаточно большой объем данных (сотни тысяч - миллионы элементов), рекомендуется хранить свойства в отдельной таблице. Для повышения эффективности выборок рекомендуется задавать для данных таблиц отдельные индексы на используемые в выборках поля.Однако, если число свойств у объектов может превысить максимальное число столбцов в таблице базы данных или требуются сквозные выборки объектов из множества инфоблоков, то рекомендуется использовать место хранения "в общей таблице".
</li>
<li>Проверяем, что инфоблок используется только на том сайте, на котором требуется выборка его данных.</li>
<li>Индексация разделов и элементов для поиска включается тогда, когда планируется искать по информации в данном инфоблоке. В противном случае для повышения производительности индексацию рекомендуется отключить.</li>
<li>Если объекты инфоблока не участвуют в документообороте или бизнес-процессах - рекомендуется отключить участие.</li>
<li>Режим просмотра разделов и элементов выбирается исходя из удобства администрирования и ожидаемого объема данных. Если данных ожидается много (сотни тысяч объектов и разделов и больше) - рекомендуется использовать "раздельный" режим просмотра.
</li>
<li>На вкладке "Поля" проверяем значения свойств объектов по умолчанию. Правильная настройка значений по умолчанию повысит удобство администрирования системы и работы с данными.</li>
<li>На вкладке "Свойства" обращаем внимание на удобочитаемые названия, адекватные решаемой задаче типы свойств и читаемые коды. Если для свойства задано название "Prop10" и код свойства "C9" - это легко запутает как менеджера сайта, так и в будущем программиста, осуществляющего доработку системы. Важно подобрать правильный тип свойства: например если требуется хранить дату, то обычно лучше использовать тип "Дата/Время", а не тип "Строка" и т.п.</li>
<li>Если требуется фильтрация по свойству элемента инфоблока в административном разделе, целесообразно в настройках свойства разрешить его вывод в фильтре - это сделает работу редактора информации более эффективной (например, список Партнеров необходимо часто фильтровать по дате регистрации Партнера и его типу т.п. - настраиваем эту возможность).</li>
<li>Аналогично проверяются настройки на вкладке "Поля разделов".</li>
<li>На вкладке "Торговый каталог" значения должны быть установлены только в случае использования данных режимов в проекте. В противном случае, для улучшения производительности, их лучше отключить.</li>
<li>На вкладке "Доступ" проверяем адекватность уровней доступа для групп пользователей. Например, инфоблок "Секретные ключи", не должен быть доступен группе "Зарегистрированные пользователи". Уровень доступа группы к инфоблоку также должен соответствовать решаемой группой задаче - например, если группа "Операторы ключей" должны только видеть ключи и не редактировать, то им не нужно предоставлять доступ "излишний" к инфоблоку - "Изменение" или "Полный доступ". Если требуется модерация внесенных данных перед их публикацией, то целесообразно назначить группе право на инфоблок - "Документооборот" (или использовать бизнес-процессы).</li>
<li>На вкладке "Подписи" проверяем их логическое соответствие. Например, если в инфоблоке хранятся данные об автомобилях, то подписи не должны описывать апельсины.</li>
<li>На вкладке "Журнал событий" можно включить регистрацию в системном журнале фактов модификации данных в инфоблоке. Если регистрация по, допустим, соображениям информационной безопасности, необходима, она должна быть включена.</li>
<li>В больших проектах с десятками типов и сотнями инфоблоков рекомендуется составить логическую модель данных с названиями инфоблоков, их свойств и связей между ними (еще лучше ее распечатать и повесить на стену). Это существенно упростит ориентацию в проекте как редакторов сайта, так и разработчиков, сократив время на поиск нужной информации и минимизировав риск логических ошибок. Также модель также поможет ответить на вопрос, можно ли удалить данный элемент инфоблока без последствий (на элемент могут ссылаться другие элементы и при удалении исходного может нарушиться логика работы проекта).</li>
</ol>
Mini Shell