Выбираем систему управления контентом для небольшого

Выбираем систему управления контентом для
небольшого предприятия.
Выбираем CMS систему управления контентом для небольшого предприятия
Введение
Современный бизнес в значительной степени построен на максимально эффективном использовании
информации, представленной в различных формах, имеющей различную природу и форму. При этом
сбор и наполнение информационных хранилищ является только одной из составляющих ее
использования. Не менее важным является дальнейшее использование этой информации для ведения
бизнеса.
Управление контентом (Content Management System, CMS) является одним из важных направлений в
деятельности многих компаний. Выбор системы для управления контентом является достаточно
сложной задачей, решению которой посвящено много отечественных и зарубежных исследований.1,2
и многие другие. Однако, существующие западные руководства не учитывают российской специфики
как в технической реализации (например проблемы поиска на русском языке), так и в области
применения.
Данный документ, предназначенный для ИТ-менеджеров и руководителей бизнес подразделений, ставит
своей целью помочь им в выборе системы управления контентом. Для этого будут показаны отдельные
возможности системы, возможные варианты их реализации с описанием, как это влияет на создаваемые
решения.
Мы будем говорить о создании корпоративных сайтов для малого и среднего бизнеса, когда полная
стоимость реализации проекта находится в среднем в пределах 3-10 тыс. у.е. (включая стоимость
внедрения). На сегодняшний день это наиболее широкий класс проектов по числу внедрений. При этом
используются либо свободно распространяемые CMS, либо коммерческие CMS, со стоимостью, не
превышающей 1000-1500 у.е. за лицензию.
Выбрав данную ценовую категорию, мы оставляем за рамками исследования промышленные системы
управления контентом известных западных производителей (IBM, Microsoft CMS, Vignette и т.д.),
поскольку их стоимость выходит за рамки установленные для данного исследования. Остается большое
количество решений российских web-студий. На текущий момент разработано и используется несколько
сотен CMS. Сравнение ряда систем по характеристикам по данным Business-Site.RU3 показывает, что
почти все системы обладают примерно одинаковой функциональностью. Именно поэтому важно не
обсуждать функциональные различия между множеством похожих систем, а сфокусироваться на
объяснениях технологических особенностей CMS и том, как это сказывается на их применении в
проектах.
С нашей точки зрения, это позволит компаниям и специалистам, принимающим решение о выборе
системы управления контентом, сделать выбор, наиболее подходящий для их конкретной задачи.
1
2
3
http://www.documentum.co.uk/products/collateral/ecm/ecm_15min_guide.pdf
http://admin.viewcentral.com/events/uploads/vcwp/vc_execbrief.pdf
http://business-site.ru/
Лицензия для ФИТ НГУ
2
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Лицензионное соглашение
Специальная лицензия для учебных заведений.
Данная копия исследования предназначена для учебных и научных целей и лицензирована для
факультета информационных технологий НГУ. Данная лицензия разрешает цитирование данных и
текста данного отчета с обязательным указанием авторства. Данная копия может использоваться
в научном и учебном процессе. Разрешается помещать ее на интернет и интранет сайтах, имеющих
отношение к данному учебному заведению.
Запрещается передача данного исследования другим организациям и сотрудникам других организаций и
использование ее в коммерческих целях.
Лица, не относящиеся к данному учебному заведению и заинтересованные в полной копии этого
исследования, могут самостоятельно загрузить персональную бесплатную копию с сайта
www.elashkin.com.
Если вы не согласны с условиями лицензии, то вам следует удалить копии этого отчета и отказаться от
его использования. Продолжение использования этого исследования автоматически означает согласие с
условиями лицензирования.
При использовании данных этого отчета, ссылка на Elashkin Research обязательна.
Лицензия для ФИТ НГУ
3
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
О компании
Компания Elashkin Research занимается исследованиями компьютерных технологий и российского
рынка enterprise решений. Специфика этого сегмента заключается в тесной интеграции компьютерных
технологий, бизнес процессов и экономических показателей. При этом огромное значение придается
пониманию технологий и путей внедрения технологий в бизнес процессы. Новые технологии,
используемы в enterprise системах, зачастую весьма сложны для понимания, а часто еще не достаточно
формализованы. Между тем, стоимость ошибки в прогнозе может быть весьма высока.
Основным качеством любой компании, исследующей этот рынок, является глубокое понимание
технологий, потребностей заказчика и существующих на рынке тенденций. Такой подход к
исследованиям компании Elashkin Research и тесное сотрудничество с лучшими экспертами ведущих
производителей и разработчиков современных enterprise технологий и решений делают компанию
Elashkin Research лидером этого рынка.
Более подробную информацию и другие отчеты вы можете найти на нашем сайте www.elashkin.com.
Об авторе
Заостровцев Николай Викторович
Закончил ВМиК МГУ в 1996 г.
В качестве руководителя группы разработки имеет более чем десятилетний опыт разработки нескольких
сотен заказных интернет и интранет проектов. Основной фокус этих работ был сосредоточен на
системах управления контентом и создание сайтов на их основе. В настоящее время область интересов
сосредоточена на системах управления корпоративной информацией.
Вы можете связаться с автором по e-mail: NikolayZ@elashkin.com
Лицензия для ФИТ НГУ
4
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Содержание
Лицензионное соглашение
3
1.
Общая информация
1.01
Что такое CMS?
1.02
Работа сайта на базе CMS
1.03
Причины использования CMS?
1.04
Существующие на рынке решения
6
6
7
7
8
2.
Возможности CMS
2.01
Публикация информации нетехническими специалистами.
2.01.1 Визуальное редактирование текста
2.01.2 Публикация изображений в тексте
2.01.3 Перенос данных из офисных приложений..
2.01.4 Резюме
2.02
Разделение данных и их представления.
2.02.1 Система публикации HTML-страниц
2.02.2 Системы с фиксированной структурой.
2.02.3 Системы с гибко настраиваемой структурой.
2.02.4 Резюме
2.03
Совместная работа
2.03.1 Документооборот
2.03.2 Разграничение прав
2.03.3 Поддержка одновременной работы
2.03.4 Типичные ситуации организации процесса публикации
2.03.5 Резюме
2.04
Поисковые возможности.
2.04.1 Поиск по сайту
2.04.2 Поиск по информации сайта.
2.04.3 Резюме
10
10
10
11
13
14
15
15
16
16
17
18
18
18
18
18
19
20
20
22
23
3.
Резюме
24
4.
Приложение. Подходы к реализации динамических типов данных.
4.01
Пары ключ/значение
4.02
Использование BLOB для хранения информации
4.03
Использование фиксированного списка полей
4.04
Динамически изменяемая структура базы данных
4.05
Резюме
25
25
26
26
27
28
5.
Copyright и торговые марки
29
Лицензия для ФИТ НГУ
5
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
1.
Общая информация
Для того, чтобы детально рассматривать отдельные возможности CMS и различия между ними,
попробуем дать определение CMS и ее функциональности.
1.01
Что такое CMS?
Система управления контентом – это программное обеспечение, которое позволяет публиковать и
изменять опубликованную на сайте информацию самостоятельно, без привлечения разработчиков сайта.
При этом подразумевается, что от пользователей такой системы не требуется специальных знаний
технологий, отличающихся от обычно используемых в офисных процессах (текстовый редактор,
интернет и т.п.). При этом не следует считать, что такая система не требует обучения персонала, но это
обучение касается порядка работы в системе, а не изучение новых технологий.
Большинство CMS можно разделить на back-office, т.е. инфраструктурную систему, обеспечивающую
функциональность и хранение информации, и front-office, интерфейс с пользователем. В большинстве
современных CMS back-office базируется на той или иной СУБД, может включать сервера приложений и
портальное решение, а front-office имеет веб-интерфейс и допускает использование стандартных
офисных пакетов редактирования документов (текстовые редакторы, электронные таблицы, средства
создания презентаций, почтовые системы и т.п.). При этом вся функциональность, сложность разработки
и администрирования сосредоточены в back-office, а пользовательские свойства в front-office.
Лицензия для ФИТ НГУ
6
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
1.02
Работа сайта на базе CMS
Обобщенная типичная схема работы сайта, использующего CMS, представлена на рис. 1.
Рис. 1 Схема работы сайта с использованием CMS.
В системе присутствует два хранилища. В первом (обычно реляционная СУБД) хранятся все данные,
которые публикуются на сайте. Во втором (обычно файловая система) хранятся элементы представления
– шаблоны, графические изображения и т.д.
Кроме внешнего представления сайта, каким его видят все пользователи, есть как минимум два
специализированных рабочих места.
Первое рабочее место – для разработчиков сайта. С его помощью они задают структуру сайта, структуру
контента, определяют внешний вид сайта, настраивают шаблоны представления информации. Этот
инструментарий обычно не полностью автоматизирован. Для настройки сайта разработчики частично
работают через средства CMS, часть информации размещается напрямую.
Второе рабочее место – для владельцев сайта. Оно позволяет сотрудникам компании самостоятельно
размещать информацию на сайте, без участия разработчиков. Менеджеры заказчика работают только
через специализированное рабочее место.
1.03
Причины использования CMS?
В настоящее время большинство организаций имеет в том или ином виде собственный веб сайт. Гораздо
меньшее число компаний имеет внутреннюю интранет систему. Часто возникает вопрос: почему не
создать еще один сайт для внутреннего использования и хранить необходимые документы там? В чем
заключаются преимущества использования CMS? Такие вопросы чаще всего возникают из-за того, что
Лицензия для ФИТ НГУ
7
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
сложности администрирования и управления ИТ инфраструктуры вообще и управления сайтом
компании обычно скрыты от пользователей. Большинство современных сайтов компаний созданы на
основе статических страниц. В результате размещение информации на таких сайтах скрыто от обычных
пользователей. Вместе с тем, эта операция требует знания основ программирования и языка HTML. При
этом вероятность ошибок, особенно для обычных пользователей весьма высока.
Использование CMS предоставляет следующие преимущества:
1.
2.
3.
4.
5.
6.
Оперативное обновление информации - информацию публикует сотрудник, владеющий
информацией, без дополнительных посредников в виде технических специалистов.
Снижение стоимости поддержки – обновление информация производится самостоятельно, нет
необходимости оплачивать труд собственного или внешнего web-мастера.
Предоставление дополнительных сервисов пользователю – часть сервисов – поиск, форумы,
голосования и т.д., требуют интерактивного взаимодействия с пользователем. Они уже
реализованы в рамках CMS.
Уменьшение сроков и стоимости разработки – наиболее востребованная функциональность уже
реализована в CMS и может быть сразу использована.
Повышение качества разработки – при разработке полностью или частично используются
готовые модули, которые уже прошли неоднократное тестирование.
Снижение стоимости дальнейших модификаций – CMS позволяют разделить данные и их
представление. Это позволяет гораздо проще изменить внешний вид сайта, чем в случае со
статическим сайтом.
Чтобы обеспечить данные преимущества, CMS должна решить следующие основные задачи:
1. Публикация информации нетехническим специалистом.
2. Разделение данных и их представления.
3. Организация совместной работы при публикации информации.
4. Поисковые возможности.
5. Другие сервисы – форумы, голосования, анкеты и т.д.
Поскольку реализация простых сервисов – форумов, голосования, вопросов\ответов (FAQ), анкет и т.д.
практически не отличается в существующих CMS, то мы вынесли эту тему за пределы нашего
исследования и в дальнейшем остановимся на более пристальном рассмотрении вариантов реализации
первых четырех задач.
1.04
Существующие на рынке решения
CMS – один из наиболее конкурентных рынков приложений сегодня. В миру существует несколько
тысяч или десятков тысяч подобных приложений. Выделим три основных класса таких приложений:
1. Системы крупных производителей
2. Системы с открытым исходным кодом
3. Российские разработки
Существует определенное количество приложений от крупных производителей в основном
предназначенных для крупных (enterprise) предприятий и организаций.
Наиболее известными приложениями такого класса являются Microsoft Content Management Server,
Documentum, Plumtree Portal, IBM WebSphere Portal и т.д.
Стоимость внедрения проектов на базе данных решений составляет от 50 000 euro. Поэтому сфера их
применения очень узкая и ограничивается в основном созданием интранет-решений для крупных
предприятий.
Другим достаточно большим классом являются open source системы. Преимуществами таких систем
является доступность, наличие исходного кода, возможность локализации. Однако их использование
связано с определенного рода проблемами:
1. Отсутствие техподдержки – системы предлагаются в основном без технической поддержки и
все проблемы, связанные с использованием таких систем разработчик должен решать
самостоятельно.
2. Узкая сфера применения – чаще всего продукт явился побочным результатом решения одной из
Лицензия для ФИТ НГУ
8
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
собственных задач. Например, разработчики создали сайт-сообщество (community) для общения
между собой. И далее решение, на котором работает этот сайт, предлагается как CMS.
Очевидно, что подобное решение может хорошо решать задачи создания такого же рода сайтов,
но может быть совершенно неприспособленно для решения задач другого плана (электронная
коммерция, b2b и т.д.)
Наиболее известными примерами таких систем являются OpenCMS, PhpNuke, PostNuke, Portal Starter Kit
и т.д. Более подробно ознакомиться с существующими open source системами вы можете на сайте
opensourceCMS.com4. Сравнение некоторых open source систем вы можете найти в документе на сайте
TechRepublic5. Следует отметить, что open source CMS решения наиболее близки к предмету данного
исследования, т.к. лежат в близкой ценовой области, но отличаются по бизнес модели и методам
внедрения.
Еще одним интересным классом являются российские разработки. Эти продукты созданы в основном
различными web-студиями, имеющими большой опыт в реализации сайтов разных типов. Данные
решения занимают промежуточную нишу. Практически все решения являются коммерческими, но с
достаточно низкой стоимостью (100-3000$) и могут быть использованы для создания сайтов разных
типов.
Наиболее популярными решениями этого класса являются Optimizer, QPublisher, Saitistika, Bitrix и
другие.
Поскольку этот класс решений является самым популярным при создании сайтов в России, рассмотрим,
как приложения этого класса решают описанные в предыдущем разделе задачи.
4
5
http://www.opensourcecms.com/
http://techrepublic.com.com/5100-6329-5077441.html
Лицензия для ФИТ НГУ
9
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
2.
Возможности CMS
2.01
Публикация информации нетехническими специалистами.
Когда разработчики CMS заявляют о том, что после создания сайта в дальнейшем обновление
информации может осуществлять нетехническими специалистами, это означает, что имеется
определенный web-интерфейс, который позволяет размещать информацию, используя определенные
визуальные инструменты редактирования, а также импортировать информацию из офисных
документов. Под Web-интерфейсом понимается специализированное рабочее место, доступное через
интернет, с использованием стандартной программы просмотра Интернет– Internet Explorer.
Ключевыми моментами является то, что
1. Возможно визуальное редактирование текста - есть WYSIWYG (What You See Is What You Get)
– редактор, позволяющий размещать текст и выполнять простейшее форматирование
документа, без наличия специальных технических знаний.
2. Возможно одновременно с текстом размещать и различные изображения – графики, диаграммы
и т.д.
3. Возможен перенос данных из офисных приложений - ведь информация, которая должна
публиковаться чаще всего не создается специально для сайта, а уже существует в компании в
виде определенного документа, обычно в формате Microsoft Word. Необходимо перенести эту
информацию, включая элементы форматирования, без лишних сложностей.
2.01.1
Визуальное редактирование текста
Что представляет собой данная возможность? Неужели каждый разработчик CMS самостоятельно
разрабатывает визуальный редактор? Конечно, нет! Поддержка визуального редактирования данных во
всех системах реализована практически одинаково.
В состав Microsoft Internet Explorer входит элемент управления, который позволяет выполнять подобное
редактирование. Разработчики осуществляют вызов этого элемента управления и далее пользуются
результатами его труда. Выглядит это примерно следующим образом (рис. 2):
Лицензия для ФИТ НГУ
10
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Рис. 2 Визуальный редактор
Поскольку используются встроенные возможности Microsoft Internet Explorer (MSIE), то практически
все системы управления накладывают жесткое ограничение – для публикации информации можно
использовать только Internet Explorer. При этом, поскольку в клиентской части визуальное
редактирование не требуется, на него никаких ограничений не накладывается, и пользователи вашего
сайта могут использовать любую программу просмотра Интернет.
В последних версиях Microsoft Internet Explorer появилась возможность не вызывать отдельный элемент
управления, а позволять осуществлять редактирование прямо в тексте страницы, переводя определенные
части страницы в состояние редактирования. Принцип тот же самый, возможности те же.
2.01.2
Публикация изображений в тексте
Достаточно часто возникает необходимость, одновременно с текстом разместить и изображения –
картинку, график, диаграмму. Причем разместить не в фиксированном месте страницы – в начале или в
конце, а непосредственно в тексте, рядом с определенным описанием.
Описанный в предыдущем разделе редактор не владеет информацией о том, где и каким образом
хранятся изображения. Поэтому он позволяет размещать в произвольном месте текста ссылку на
изображение. Выглядит это примерно так (рис. 3):
Лицензия для ФИТ НГУ
11
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Рис.3 Пример использования в тексте изображения.
При этом необходимо указать адрес на сервере (URL), где находится изображение. Как изображение
попадет на сервер – находится вне компетенции данного редактора.
Разработчик может модифицировать данный функционал, позволив пользователю изначально
разместить изображения либо в общую библиотеку, либо привязать их к конкретному документу, а
далее уже при редактировании выбирать, какое изображение включить.
В случае использования общей библиотеки возможно повторное использование одних и тех же
изображений, однако, при большом их количестве затруднен поиск, а также удаление ненужных. В
случае связывания изображений с конкретным документом, повторного использования нет (для системы
одно и то же изображение, присоединенное к двум документам, будет двумя разными), но это упрощает
выбор и гарантирует автоматическое удаление изображений одновременно с самим документом.
На рисунке 4 ниже продемонстрирована одна из подобных реализаций, когда при вставке картинки она
выбирается из списка изображений, присоединенных к данному документу.
Лицензия для ФИТ НГУ
12
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Рис.4 Одна из реализаций выбора изображений из документа.
Рисунок 1
2.01.3
Перенос данных из офисных приложений..
Что имеют в виду разработчики, говоря о том, что можно переносить данные из офисных приложений?
То, что Вам предоставляется возможность перенести данные из офисного документа на сайт, с
сохранением не только информации, но и определенных элементов форматирования текста (списки,
таблицы, курсив и т.д.).
Как это обычно происходит? Выполняется следующая последовательность действий:
1. Открываете офисное приложение, например, Microsoft Word.
2. Выделяете требуемый текст, копируете его в буфер обмена.
3. Создаете документ в системе управления контентом.
4. Вызываете в ней визуальный редактор.
5. Вставляете текст из буфера обмена.
Все готово, текст перенесен, с сохранением форматирования. Правда, особой заслуги разработчиков тут
нет. Естественно, что, как и в случае, с визуальным редактором, каждый разработчик не создает свой
новый конвертор из Word в HTML. Используются стандартные средства, предоставляемые Microsoft.
Когда Word размещает текст в буфере обмена, он сам выполняет преобразование текста в HTML, а
редактор просто берет готовый HTML и отображает.
В этом и скрыта определенная проблема. Когда Word преобразует документ в HTML, то он:
1. Пытается максимально сохранить форматирование. Включая стили, размеры шрифтов и т.д.
2. Использует собственные таблицы стилей.
Лицензия для ФИТ НГУ
13
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Например, абзац на предыдущей странице при переносе из Word в HTML выглядит таким образом:
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt">Что имеют ввиду разработчики, говоря о том, что можно переносить данные
из офисных приложений? То, что Вы можете воспользоваться стандартным буфером обмена <SPAN lang=EN-US style="mso-ansilanguage: EN-US">Windows</SPAN>, чтобы перенести данные из офисного приложения в <SPAN lang=EN-US style="mso-ansilanguage: EN-US">Web</SPAN>, с сохранением форматирования.</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt">Последовательность действий выглядит следующим образом:</P>
<OL style="MARGIN-TOP: 0cm" type=1>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Открываете офисное приложение,
например, <SPAN lang=EN-US style="mso-ansi-language: EN-US">Microsoft</SPAN><SPAN lang=EN-US> </SPAN><SPAN
lang=EN-US style="mso-ansi-language: EN-US">Word</SPAN>.</LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Выделяете и копируете в буфер
обмена текст, который необходимо перенести. </LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Создаете документ в системе
управления контентом.</LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Вызываете в ней визуальный
редактор.</LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt">Вставляете текст из буфера
обмена.</LI></OL>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt">Все готов, текст перенесен, с сохранением форматирования. <SPAN
style="mso-spacerun: yes"> </SPAN>Правда, особой заслуги разработчиков тут нет. Все за них сделал <SPAN lang=EN-US
style="mso-ansi-language: EN-US">Microsoft</SPAN>. Это его стандартные средства. Когда <SPAN lang=EN-US style="mso-ansilanguage: EN-US">Word</SPAN> размещает текст в буфере обмена, он сам выполняет преобразование текста в <SPAN lang=ENUS style="mso-ansi-language: EN-US">HTML</SPAN>, а редактор просто берет готовый <SPAN lang=EN-US style="mso-ansilanguage: EN-US">HTML</SPAN> и отображает.</P>
Когда в страничке отображается данный текст, то форматирование будет соответствовать тому, что
было в Word, но может сильно отличаться от внешнего вида вашего сайта. В результате часть текста
может быть написана одним шрифтом, часть другим. Внешний вид сайта начнет искажаться.
Это общая проблема и избежать ее можно двумя способами:
1. Разработчик CMS знал об этой проблеме и, при сохранении документа, удаляет из текста
специализированные элементы разметки, которые добавляет Word.
2. Пользователю приходится бороться с этим самостоятельно. А именно – переносит только
данные, а потом вручную выполняет форматирование в визуальном редакторе. Для этого
используется промежуточная программа, которая не поддерживает работу с буфером обмена в
формате HTML. Например, блокнот (Notepad). Текст из Word, через буфер обмена попадает в
Notepad, при этом пропадает форматирование. Потом из Notepad копируется в визуальный
редактор и заново выполняется его форматирование.
2.01.4
Резюме
Системы управления контентом действительно позволяют нетехническому специалисту публиковать
информацию на сайте и выполнять простейшие операции по форматированию текста. Выделить текст
курсивом на сайте ничем не сложнее, чем выполнить аналогичную операцию в Microsoft Word. И данная
возможность во всех системах реализована практически одинаково.
Если Вы планируете при публикации информации размещать изображения внутри текста сообщений, то
необходимо обратить внимание на реализацию этой возможности. Если при этом будут часто
использоваться одни и те же изображения, то оптимальным будет вариант с включением изображений из
библиотеки. Если размещаемые изображения обычно используются только в одном месте, то
оптимально будет использовать вариант с привязкой изображений к конкретному документу. И выбор
быстрее и об удалении заботиться не нужно.
Если Вы планируете импортировать информацию из офисных документов, то стоит обратить внимание
на то, позаботился ли разработчик об автоматическом удалении излишних элементов разметки из
документа. Иначе Вам придется отдельно переносить информацию и потом повторно выполнять
разметку текста, уже используя редактор сайта.
Лицензия для ФИТ НГУ
14
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
2.02
Разделение данных и их представления.
Прежде всего, договоримся об используемой терминологии:
• Документ – единица публикуемой информации. Документом может быть одного из типов
документов, используемых на сайте - новость, статья, товар и т.д.
• Атрибут – один из признаков документа. Каждый документ обладает набором признаков –
атрибутов. Например, для новости атрибутами являются название, автор, аннотация, текст, дата
создания.
• Тип документа – обобщенное понятие документов, обладающих одинаковыми
характеристиками. Например, «новость». Мы описали, какими атрибутами обладают документы
типа «новость» и далее создаем документы этого типа.
• Структурированные данные – представление данных, при котором каждый атрибут документа
представлен отдельно и с ним могут выполняться независимые операции.
Как было отмечено ранее, одним из преимуществ использования CMS является структурирование
информации и разделение содержимого и его представления (данных и дизайна).
Для чего это необходимо?
1. Гарантия сохранения внешнего вида - при разделении информации и ее представления
оператор вводит значение каждого атрибута в отдельное поле и может быть уверен, что оно
отобразиться в нужном месте, как определено в настройках отображения. Например, мы хотим,
чтобы имя автора статьи всегда отображалось под названием, было выровнено вправо и
выделено жирным шрифтом. Если оператор вводит только значение, то он уверен, что данные
будут отображены где нужно и как нужно. Иначе он обязан помнить о принятом стиле и
вручную выполнять данное форматирование.
2. Возможность предоставления дополнительного сервиса – когда атрибуты хранятся отдельно, с
ними можно выполнять дополнительные операции. Например, если у нас автор статьи хранится
как отдельное поле, то очень легко предоставить возможность просмотреть все статьи данного
автора. Это выполняется автоматически. Если имя автора хранится в тексте статьи, то
формирование списка статей автора является отдельной ручной операцией.
3. Возможность интеграции с внешними системами – быстрый экспорт новостей или товаров для
обмена с другими ресурсами – сайтами, внутренними системами и т.д.
4. Снижение стоимости смены дизайна – для изменения внешнего вида сайта нет необходимости в
ручной переработке каждого документа. Изменяются только шаблоны отображения и вся
информация может быть быстро представлена в другом виде. А, как показывает практика, раз в
два-три года сайт обязательно меняет свой внешний вид.
5. Возможность использования одной информации в разных дизайнах – это особенно используется
последнее время при создании информационных систем холдингов, когда вся информация
хранится в центральной системе, но может быть показана, как на сайте холдинга, так и на сайте
отдельного предприятия, но в разных дизайнах.
Если посмотреть, как и в какой мере текущие CMS-системы решают эти задачи, то можно выделить
следующие классы систем.
• Система публикации HTML-страниц.
• Система с фиксированной структурой.
• Система с гибко настраиваемой структурой документов.
2.02.1
Система публикации HTML-страниц
Разработчик позволяет через web-интерфейс осуществлять публикацию одного типа документа –
страница. Под страницей обычно понимается тип документа, содержащий название (заголовок
страницы) и собственно текст страницы. Текст страницы может быть изменен пользователем с помощью
встроенного WYSIWYG-редактора.
В данных системах все атрибуты находятся внутри HTML. Разделения данных и их представления не
производится. Описанные выше задачи не решаются.
Лицензия для ФИТ НГУ
15
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Менеджеру, осуществляющему публикацию, необходимо будет постоянно думать о внешнем виде
сайта, о поддержке единого внешнего вида и т.д.
Такие системы можно рассматривать как системы для управления очень небольшими простыми
сайтами. Однако, в таком случае лучше взять более продвинутые в этом отношении промышленные
средства, такие как Microsoft FrontPage, MacroMedia Contribute и т.д. С их помощью аналогичная задача
решается более удобно.
2.02.2
Системы с фиксированной структурой.
В системах этого класса разработчики выделили наиболее используемые типы документов и заранее
описали и зафиксировали их структуру. Например, есть понятие новость, статья, товар. Для каждого
типа определен список атрибутов.
Если предложенные разработчиком типы документов полностью соответствуют задачам создаваемого
сайта, то все отлично. Система решает полностью задачи по структуризации информации и разделению
данных и представления.
Но, если ваши потребности несколько отличаются, то есть два варианта.
Первый – Вы используете стандартный тип «HTML-страница», как в системах, описанных в
предыдущем разделе. При этом эти для этих данных принципы структуризации и разделения данных и
представления действовать не будут.
Второй – разработчик специально для вашего проекта вносит изменения в систему и добавляет
необходимые вам типы документов.
При принятии решения об использовании систем такого класса надо четко описать все типы
документов, которые будут публиковаться на сайте, посмотреть, насколько они соответствуют типам,
предлагаемых системой, и уточнить у разработчика, сколько будут стоить добавление недостающих
типов документов.
2.02.3
Системы с гибко настраиваемой структурой.
Системы этого класса еще больше приспособлены для решения задач публикации информации. Они
позволяют динамически добавлять новые типы документов в систему, определять их атрибуты. Система
автоматически подстраивается под новые типы и сразу после изменений структуры можно начинать
публикацию документов вновь созданных типов.
Эти системы также можно разбить на подклассы по тому, что понимается под атрибутом. Возможны
следующие варианты:
• Поле одного из предопределенных типов (строка, число, дата и т.д.)
• Поле, значение которого можно выбирать из справочника
• Связь с документом другого типа.
Рассмотрим простую ситуацию. Мы публикуем на сайте новости с других ресурсов, и необходимо
сохранять информацию об источнике. Как нам указать источник информации?
Если у нас поддерживаются только предопределенные типы, то мы заводим поле «Источник» и для
каждого документа указываем название источника. При этом, несмотря на то, что список источников
фиксирован, нам каждый раз приходится вносить название источника вручную. При этом:
• Возможны опечатки и разное написание одного и того же источника.
• Поскольку возможно разное написание, то такая операция, как, например, «получить список
всех новостей с определенного источника», может быть выполнена не совсем корректно.
Если в системе поддерживаются справочники, то мы можем завести справочник источников, один раз
внести туда информацию и далее выбирать значение поля «Источник» из справочников. Это
значительно удобнее и надежнее. Однако в справочниках обычно каждое значение представляет собой
просто строку. Т.е. если мы захотим про источник сохранить расширенную информацию, например,
Лицензия для ФИТ НГУ
16
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
«Адрес источника», «Комментарии» и т.д., то это уже сделать не получится.
Наиболее гибкой является система, которая позволяет устанавливаться связи между разными типами
документов. В таком случае Вам достаточно завести два новых типа – «Статьи», «Источники», для
каждого определить необходимый набор атрибутов и установить связь между статьей и источником.
Другими примерами использования связей могут быть связь заявки с товаром или услугой, связь резюме
и вакансии. Все эти примеры очень легко реализуются в случае поддержки связей между типами.
Системы такого класса отлично решают задачи публикации информации любых типов. Неужели идеал
достигнут? Конечно, нет!
1. Есть несколько подходов к технической реализации динамических типов документов. В
зависимости от выбранного разработчиком подхода, система будет иметь свои ограничения.
Подробнее подходы к реализации динамических типов рассмотрены в приложении 1.
2. Такие системы сложнее модифицировать. Когда требуется не просто публикация информации,
а еще и выполнение специализированных действий, то разработчику гораздо сложнее
выполнить изменения, чем в системах предыдущего класса. Понадобилась простая вещь –
чтобы в свойствах товара поле «общая сумма» автоматически вычислялось на основе полей
«сумма заказа», «сумма доставки», «скидка». Когда для каждого типа документов существует
собственный обработчик, то выполнить эту операцию не составляет проблем. В гибких
системах работает общий обработчик, и его модификация под специализированные задачи
представляет собой более сложную операцию.
2.02.4
Резюме
Таким образом, когда мы смотрим на систему с точки зрения, насколько она решает наши задачи по
структурированию информации и разделению дизайна и содержимого, то стоит ответить на вопросы:
1. Какие типы документов будут размещены на сайте?
2. Какими атрибутами обладает каждый из типов документов?
3. Существуют ли связи между типами документов и какие именно?
4. Какие специализированные операции, кроме публикации, необходимо выполнять с данными
документами?
5. Как эти типы документов будут поддержаны в предлагаемой CMS и каким образом?
Независимо от ответов на эти вопросы, существует очень мало областей применения для систем
публикации HTML. В таком случае, лучше обратить внимание на готовые коммерческие западные
продукты.
Если вам требуется публикация информации разных типов, то наиболее удобным вариантом будут
системы, поддерживающие гибкую структуру, особенно со связями между документами. Это позволит
создать систему гораздо быстрее и дешевле.
Если на сайте будут использоваться типы документов, для которых необходимо выполнять
специализированные действия, то выбор будет между системами с фиксированной и гибкой структурой.
В обоих случаях потребуются те или иные доработки системы и необходимо будет сравнить, кто из
разработчиков предложит более интересные условия. Для систем с фиксированной структурой
доработок больше, но они проще. Для гибких систем доработок меньше, но они сложнее.
Лицензия для ФИТ НГУ
17
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
2.03
Совместная работа
Функционал, предоставляемый разработчиками для поддержки совместной работы операторов при
публикации информации, можно разбить на следующие блоки:
• Документооборот
• Разграничение прав
• Поддержка одновременной работы
2.03.1
Документооборот
Под документооборотом понимается наличие возможности реализовать определенный процесс
публикации документов на сайте. Обычно он реализовываться в одном из следующих вариантов:
• Возможность скрыть часть документов от пользователя. В таком варианте система
предоставляет возможность установить у документа специальный флаг (обычно «Видимость»,
«Публикация»), который позволяет скрыть часть документов от пользователя. Т.е. в процессе
подготовки документа он уже хранится на сайте, но еще не видим пользователю.
• Поддержка процесса утверждения документа. После того, как документ, по мнению автора,
готов к опубликованию на сайте, он должен пройти утверждение (Approval) у вышестоящих
сотрудников. Система позволяет указать одного или несколько сотрудников, чье утверждение
должен пройти документ. Дополнительно может настраиваться условие публикации - должен ли
документ для публикации получить подтверждение всех указанных сотрудников по очереди или
достаточно подтверждения одного сотрудника из списка.
• Поддержка процесса согласования документа. Система позволяет задавать произвольные
стадии, которые должен проходить документ, какие операции можно выполнять на какой
стадии, кем из сотрудников и т.д. Системы такого класса способны выполнять функции
простейшей системы документооборота компании.
2.03.2
Разграничение прав
Под разграничением прав понимается возможность регулировать, кто имеет право выполнять какие
операции. Система может строиться по разным принципам:
• По типам информации – одни сотрудники занимаются публикацией новостей, другие
занимаются обработкой заказов и т.д.
• По разделам – раздел «Политика» ведется одними, раздел «Экономика» другими. Сотрудник
осуществляет полное администрирование раздела, независимо от типа информации.
• Комбинация этих вариантов.
2.03.3
Поддержка одновременной работы
Когда публикация информации на сайте осуществляется несколькими сотрудниками, то возможна
ситуация, когда два сотрудника по тем или иным причинам правят один и тот же документ. Это может
происходить как на разных стадиях его прохождения, так и на одной. Чтобы избежать возможных
конфликтов, система должна поддерживать как минимум операции – «взять на редактирование»,
«завершить редактирование». Чтобы в единый момент времени более одного человека не правили один
документ.
А, чтобы дать возможность откатить изменения, необходимо, чтобы система хранила все версии
документов. Если кто-то внес некорректные изменения, то всегда можно не только выяснить, кто это
сделал, но и вернуть документ к корректному состоянию.
2.03.4
Типичные ситуации организации процесса публикации
Мы кратко рассмотрели возможности, которые предоставляют разработчики для поддержки совместной
работы, специально не углубляясь в их детализацию, ведь, бизнес-процессы в каждой компании свои и
требования свои. Рекомендовать можно только зная тот процесс, который будет принят в конкретной
компании. Но можно выделить достаточно типичные ситуации.
Ситуация 1. Единый центр публикации информации.
На сайте публикуется информация разных подразделений, но сбором и размещением информации
занимается выделенный человек или подразделение – менеджер проекта или отдел маркетинга.
Остальные подразделения могут являться источником информации, однако не являются
Лицензия для ФИТ НГУ
18
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
заинтересованной стороной. Кроме того, окончательное подтверждение все равно должен дать отдел
маркетинга. При этом для других подразделений работа с сайтом воспринимается как дополнительная
лишняя нагрузка. В результате назначенный человек собирает информацию обычными каналами,
принятыми в компании, после чего проверяет и размещает на сайте.
Ситуация 2. Существует и налажен внутренний документооборот.
В компании внедрена и работает система документооборота. В таком случае любая информация уже
проходит все необходимые стадии. Например, пресс-релиз прошел во внутренней системе
документооборота все стадии и принят. Будут ли ответственные лица после согласования во внутренней
системе повторно согласовывать его на сайте? Скорее всего, нет. Поэтому остаются два варианта:
1. Согласованный документ направляется ответственному менеджеру, и он размещает его.
Ситуация сводится к предыдущей.
2. Внутренняя система и сайт интегрированы, документ автоматически размещается на сайте.
Тогда от CMS не требуется не только наличие цепочки принятия, но и вообще возможности
публикации информации. Зато предъявляются большие требования по интеграции.
Ситуация 3. Управление информационным проектом.
Создается команда людей, которым необходимо создать информационный проект. Например, средство
массовой информации. За каждую тему отвечает отдельный сотрудник. При этом команда создается
только под этот проект, и вся информация создается только в рамках сайта.
В первом и втором случае функциональность для поддержки совместной работы не используется, и ее
наличие может только замедлять работу.
В третьей ситуации функциональность поддержки совместной работы действительно необходима и
используется. Фактически сайт используется не только как средство публикации информации, но и как
средство автоматизации внутренней деятельности.
Из практики создания нескольких сотен сайтов можно сказать, что практически всегда мы имеем дело
именно с первой ситуацией. Независимо от того, как планируется вести работу, в конечном итоге все
сводится именно к такому варианту.
В идеале, мы все идем ко второй ситуации. Внутренняя система автоматизации налажена, пресс-релиз
после создания подписывается цифровой подписью, проходит всю цепочку согласований и
утверждений, окончательно утверждается также цифровой подписью, а потом по заданным правилам
автоматически уходит на сайт, информационным агентствам, партнерам и т.д. Сайт принимает
подписанный цифровой подписью документ, по своим правилам определяет формат и место публикации
и размещает его. Человек уже не участвует. Пропадает необходимость не только в поддержке
совместной работы, но и в интерфейсе публикации, как таковом.
2.03.5
Резюме
Предлагаемая разработчиками функциональность по поддержке совместной работы в большинстве
случаев оказывается невостребованной. В теории все выглядит красиво и правильно, но реально она
применяется только тогда, когда используется в специализированных интернет-проектах.
Чтобы понять, требуется ли в вашем проекте поддержка совместной работы, необходимо ответить на
следующие вопросы:
1. Какая информация будет размещена на сайте?
2. Источники данной информации?
3. Можно ли эту информации получить из внутренней системы или она создается только для
сайта?
4. Кто принимает решение о публикации той или иной информации на сайте? Каким образом
будет даваться подтверждение о разрешении публикации?
Скорее всего, если мы говорим не о разработке специализированного информационного ресурса, а о
сайте компании, выяснится, что информация должна публиковаться либо автоматически, либо
собирается и публикуется выделенным подразделением.
Лицензия для ФИТ НГУ
19
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
2.04
Поисковые возможности.
Казалось бы, что уже давно поиск является неотъемлемой частью любого сайта и все вопросы давно
решены. На самом деле организация поиска по сайту не такое простое дело.
В реализации поиска есть ряд моментов, которые зависят не только от выбранных средств, но и от
выбранных подходов к реализации поиска.
В данной работе рассмотриваются два основных подхода к организации поиска. Условно назовем их
так:
1. Поиск по сайту
2. Поиск по информации сайта
Проанализируем, чем в каждом из подходов, отличаются ответы на следующие вопросы:
1. Что мы получаем в результатах поиска?
2. Как происходит обновление индекса?
3. Какие есть ограничения на формирование ссылок?
4. Можно ли одновременно искать по контексту и атрибутам?
5. Как происходит индексация разделов с ограниченным доступом?
6. Как отображаются ссылки на документы с ограниченным доступом?
7. Будет ли осуществляться поиск по присоединенным бинарным документам?
8. Учитывается ли при поиске морфология русского языка?
2.04.1
Поиск по сайту
Для организации такого варианта поиска используется внешняя поисковая система.
Рис. 5 Структурная схема поисковых систем.
Внешняя поисковая система состоит из двух модулей:
• Crawler – (обходчик, «паук») – программа, которая периодически сканирует сайт, т.е. проходит
по всем доступным ему страницам сайта, скачивает их.
• Indexer – (индексатор) – программа, которая извлекает и индексирует тексты страниц.
Что получается в результатах поиска?
Результатом поиска является страница сайта, т.е. находится информация, как она выглядит на сайте.
Например, заголовок новости содержит слово «Выборы». При этом, в результатах поиска мы найдем не
только саму страницу новости, но и страницы со списком новостей. Ведь на тех страницах было
название этой новости, поэтому они тоже найдутся в результатах поиска. Кроме всего прочего может
найтись еще и страница, на которой в момент обхода в текстовом баннере содержалась данная строка.
Чтобы избежать индексации ненужного содержимого, например, текстовых баннеров, можно обрамлять
текст специальными инструкциями (NOINDEX), которые поддерживаются большинством поисковых
Лицензия для ФИТ НГУ
20
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
систем. Однако корректное их использование – на совести разработчика.
Как происходит обновление индекса?
По расписанию программы-обходчика. Он с определенной периодичностью сканирует сайт. При этом,
ему приходится обходить все страницы сайта. Индекс может перестраиваться не полностью, а частично,
в зависимости от того, изменилась страница или нет. Но для этого все равно нужно обойти и скачать все
страницы.
Какие есть ограничения на формирование ссылок?
Собственно на способ формирования ссылок ограничений нет. Ссылка может иметь произвольный вид.
Но для полной индексации текстов, нужно учитывать следующие моменты:
1. Любая страница должна быть доступна через явную ссылку. Например, если сделать навигацию
по архиву новостей через выбор формы, поисковик не сможет автоматически заполнять форму и
найти данные страницы.
2. Не должно быть «бесконечных» ссылок. Например, ссылка на следующий месяц в календаре
новостей должна быть только в случае, если новости есть. Если ссылка присутствует всегда, а в
тексте пишется, что «Новостей за данный месяц нет», то для поисковика это обычная страница.
Т.е. он будет переходить по ссылке «следующий месяц» до бесконечности. Индексация не
завершится никогда.
Можно ли одновременно искать по контексту и атрибутам?
Например, есть раздел «Книги» и нужно организовать поиск по автору, диапазону цен и фрагменту
текста в описании. При такой организации поиска это достаточно сложно.
Во-первых, большинство внешних поисковых систем производят поиск только по тексту.
Во-вторых, если они поддерживают поиск по дополнительным атрибутам (указанных в мета-тегах
страниц), то в любом случае все страницы сайта для него одинаковы. Нужно создавать объединенный
список атрибутов для всех разделов, прописывать их для всех страниц и т.д.
Как производится индексация разделов с ограниченным доступом?
Часто корпоративные сайты содержат специальные области с ограниченным доступом. Например,
раздел «Для дилеров». Если на сайте есть подобные разделы, то данный способ организации поиска
становится очень неэффективным. Проблема связана с самим принципом получения данных. Поисковая
система должна получить доступ к этим данным через сайт.
Чтобы получить доступ к данному разделу, необходимо пройти авторизоваться под пользователем,
имеющим соответствующие права. Далеко не все подобные поисковики умеют производить
авторизацию через форму (form-based).
А если есть несколько разделов для разных типов пользователей? Поддерживает ли поисковая система
возможность авторизации под несколькими разными пользователями через одну и ту же форму? Обычно
нет.
Как решить этот вопрос? Каждый разработчик выбирает свой способ. Один из наиболее
распространенных – создавать «внутренний» сайт без авторизации, на котором доступна вся
информация, и индексировать его. А в результатах поиска подменять ссылки с внутреннего сайта на
внешний.
Следует отметить, что системы управления контентом, использующие данные подход к поиску, обычно
не содержат средств поиска внутри рабочих мест публикации данных. Т.е. при большом объеме
информации сначала приходится находить нужный документ через клиентский сайт, а потом уже по
другим признакам искать его в системе публикации и исправлять.
Как отображаются ссылки на документы с ограниченным доступом?
Допустим, нам удалось проиндексировать документы, доступ к которым ограничен. Поскольку
поисковая система и система разграничения прав при таком подходе не связаны между собой, то в
результатах поиска чаще всего показываются заголовки всех документов, а при переходе в них уже
проверяются права доступа и выдается соответствующее сообщение.
Реализация подхода, когда документы полностью закрыты. Т.е. если нет права на просмотр, то нельзя
Лицензия для ФИТ НГУ
21
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
даже видеть заголовок, возможна, но будет зависеть от объема информации. Необходимо будет сначала
осуществить поиск, получить полный список документов, потом проверить для всех права доступа,
сформировать новый сокращенный список и далее уже с ним работать. Хорошо, если список содержит
несколько десятков или сотен документов. А если тысячи? Скорость работы зависит от объема
информации.
Будет ли осуществляться поиск по присоединенным бинарным документам?
Когда Вы разместили анонсы события и подробную информацию о нем в формате PDF, будет ли
производится поиск по тексту в присоединенном документе? Возможность полезная, ответа общего нет,
зависит от конкретной выбранной поисковой системы.
Учитывается ли при поиске морфология русского языка?
Учет морфологии русского языка значительно повышает качество поиска информации. Ее поддержка
зависит от конкретной выбранной поисковой системы.
2.04.2
Поиск по информации сайта.
В системах такого класса для организации поиска используются внутренние средства хранилища
данных.
Рис. 6 Схема поиска с помощью внутренних средств хранилища данных.
Т.е. база данных самостоятельно умеет осуществлять индексацию всей информации, включая текстовые
материалы.
При таком подходе индексации подвергается собственно сама информация, а не ее представление. Т.е. в
приведенном примере с новостью в результате найдется только новость, поскольку база не знает, где и в
каком виде эта новость встречается.
Что мы получаем в результатах поиска?
В результатах поиска мы получаем ссылки только на непосредственно сами документы, в которых
содержится требуемая информация.
Как происходит обновление индекса?
База данных самостоятельно отслеживает все изменения информации и автоматически обновляет
индексы. Обновление происходит по мере внесения изменений.
Какие есть ограничения на формирование ссылок?
Ограничения есть. Ведь в результатах поиска мы получаем просто набор документов из базы. Это
значит, что должно существовать однозначное правило, по которому для любого документа в базе
можно автоматически сформировать ссылку на этот документ на сайте.
Лицензия для ФИТ НГУ
22
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
Можно ли одновременно искать по контексту и атрибутам?
Естественно, поскольку индексация производится хранилищем, можно совмещать поиск по разным
атрибутам, с любыми ограничениями.
Как происходит индексация разделов с ограниченным доступом?
Точно так, как и для всей остальной информации. Система индексирует все данные, а какие из них кому
показывать – определяется на этапе отображения.
Как отображаются ссылки на документы с ограниченным доступом?
Поскольку система поиска и система разграничения прав доступа интегрированы и обе хранят
информацию в базе, то при поиске автоматически дополнительно накладывается ограничение по правам
доступа. Поэтому можно легко скрыть определенную информацию от тех пользователей, которым ее
видеть не положено.
Будет ли осуществляться поиск по присоединенным бинарным документам?
Зависит от конкретной системы. Например, MS SQL 2000 может автоматически производить
индексацию документов в форматах, поддерживающих IFilter Interface – Word, RTF, PDF и другие.
Учитывается ли при поиске морфология русского языка?
Также зависит от конкретной системы. По умолчанию MS SQL 2000 не поддерживает учет русской
морфологии, ее можно подключить с помощью RCO for BackOffice6.
2.04.3
Резюме
Удобные средства поиска важны для эффективной работы с сайтом.
Если вы создаете простой сайт, содержащий который содержит однотипную информацию,
предоставляемую всем пользователям, то подключением внешней поисковой системы будет
оптимально. Быстро и просто получаем нужный результат.
Если же необходим поиск по отдельным атрибутам, предоставление разной информации для разных
типов пользователей, публикация большого объема материалов, то необходимо использовать поиск
через внутреннюю систему.
6
http://www.rco.ru/product.asp?ob_no=12
Лицензия для ФИТ НГУ
23
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
3.
Резюме
Данное исследование рассматривает некоторые возможности, которые предоставляют системы
управления контентом для сайтов наиболее популярной ценовой категории. Большинство
существующих в данной ценовой категории весьма схожи, но детали их реализации могут различаться.
Рассмотрение деталей реализации и их влияния на реализацию проекта и было целью работы.
Следует признать, что выбор идеальной системы невозможен. Как было показано в отдельных разделах,
каждый из подходов к реализации возможностей имеет свои особенности. И при выборе системы
необходимо учитывать, как эти особенности могут повлиять на работу именно вашего сайта. Мы
надеемся, что вопросы, рассмотренные в этой работе, помогут вам определиться с выбором наиболее
подходящей вас системы управления контентом.
Лицензия для ФИТ НГУ
24
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
4.
Приложение. Подходы к реализации динамических типов данных.
Итак, если вы выяснили, что система управления сайтами поддерживает создание новых типов
документов со связями, это означает, что вы уже в достаточной степени гарантировали гибкостью
системы.
Однако этого еще не достаточно. Сравним некоторые варианты реализации этих возможностей с точки
зрения хранения информации. И посмотрим, как подходы к реализации влияют на предоставляемые
пользователям возможности.
Наиболее известны следующие подходы к созданию динамических типов:
• Пары ключ\значение
• Использование BLOB для хранения информации
• Использование фиксированного списка полей.
• Динамически изменяемая структура данных.
Рассмотрим эти подходы подробнее.
4.01
Пары ключ/значение
Одной из наиболее популярных реализаций такого подхода является примерно следующая структура:
Рисунок П1
Вся поддержка реализуется на базе четырех фиксированных таблиц.
• Entity – справочник типов документов
• Attributes – описания атрибутов, которые есть у документов данных типов.
• Object – собственно документы данных типов
• ObjectAttributes – хранение значения атрибутов для всех объектов.
Названия таблиц, полей и т.д., могут отличаться в разных реализациях, но суть подхода остается той же.
Основным является то, что все значения всех атрибутов хранятся в одной таблице в виде пар –
атрибут/значение.
Данная реализация является наиболее простой в реализации и поэтому популярной, однако имеет ряд
существенных недостатков.
1.
2.
Большое количество таблиц, участвующих в выборках. Допустим, Вам необходимо выбрать всю
информацию по одному товару. При этом товар имеет 10 атрибутов. В этой выборке будет
участвовать, как минимум, 11 таблиц. Одна таблица Object и 10 таблиц ObjectAttributes. Это при
условии, что информация по описаниям атрибутов у Вас уже выбрана заранее и закэширована.
Иначе придется включать еще и 10 таблиц Attributes. Итого – 21 таблица в выборке для
получения данных.
Значительный рост количества записей и объем таблицы с данными (ObjectAttributes). Если у
нас товар имеет 10 атрибутов, то для 100 тыс. Записей товаров, в таблице значений атрибутов
будет уже миллион записей.
Лицензия для ФИТ НГУ
25
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
В итоге мы получаем, что таблица со значениями атрибутов документов растет очень быстро и в каждой
выборке эта таблица включается столько же раз, сколько атрибутов необходимо получить.
С ростом количества записей это ведет к катастрофической потере производительности. В результате
такой подход хорошо работает только в системах с небольшим объемом информации.
4.02
Использование BLOB для хранения информации
Другой популярный подход заключается в использовании больших текстовых полей (BLOB), в которых
все атрибуты объекта хранятся в структурированном виде (чаще всего в XML).
Рисунок П2
Приложение сохраняет все свойства объекта в виде XML документа и записывает в текстовое поле в
таблице. Далее, при необходимости получения значения отдельных атрибутов, выбирается текстовое
поле, разбирается XML-документ и получаются значения.
Такой подход лишен одного из недостатков предыдущего подхода (с ростом количества записей
значений атрибутов), но имеет свои недостатки, также относящиеся в основном к производительности
систем.
1.
2.
Постоянные дополнительные преобразования XML-документов приводят к лишнему
расходованию ресурсов. Это может не быть критичным при работе с одиночными документами,
но приводит к замедлению работы при выборке сразу большого количества записей.
Базовое программное обеспечение не знает ничего о внутренней структуре документов.
Внутренняя структура известна только самому приложению. Это означает сложность или
невозможность использования встроенных средств, таких, как, например, индексирования для
осуществления быстрого поиска, контроля целостности и т.д.
4.03
Использование фиксированного списка полей
Схема реализации выглядит примерно так.
Рисунок П3
В таблице, где хранятся значения объектов, создано заранее определенное количество полей. Обычно
типа «строка» с ограничением по длине, либо типа sql_variant, если подобные типы поддерживаются
базовым программным обеспечением.
А в таблице описаний атрибутов содержится информация, что в поле с номером таким-то хранится
атрибут с таким-то названием и такого-то типа.
Вариацией данного подхода является хранение определенного количества параметров каждого типа,
например, 20 строковых параметров, 5 числовых, 5 дат и т.д.
Такой подход позволяет полностью избежать необходимости включения большого количества таблиц в
выборку, а также избежать значительного роста записей. Но также имеет свои недостатки.
При использовании для значения параметров полей строкового типа, мы получаем проблемы с
Лицензия для ФИТ НГУ
26
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
•
•
•
Ограничением по длине. Если поля 255 символов, а потребовалось сохранить поле длиной 256,
то это уже становится невозможным. Либо приходится использовать два поля и автоматически
соединять их значения.
Если у нас все параметры строковые то,
o Постоянные преобразования типов, причем выполнять проверку на соответствие типов
необходимо вручную.
o Сложности при использовании индексов. Все таки результат сравнения чисел 9 и 10 и
строк «9» и «10» отличаются.
Если у нас параметры разных типов, то может оказаться, что для какого то типа нужно 6
числовых атрибутов, а базовая система поддерживает не более 5. И т.д.
Подход хорош для случая, когда необходимо поддерживать очень большое количество произвольных
типов информации, поскольку позволяет разместить всех их в фиксированной структуре. Но с учетом
приведенных органичений.
4.04
Динамически изменяемая структура базы данных
Более сложный в реализации подход заключается в динамическом изменении структуры базы данных,
аналогично тому, как если бы все изменения программист выполнял вручную.
Примерная структура базы данных выглядит следующим образом (описание структуры взято на основе
Optimizer 2.5):
Рисунок П4
В таблице Entity хранится описание новых сущностей, которые создает пользователей. В
дополнительной таблице (Properties) хранятся мета-описания атрибутов. Та информация, которая нужна
системе для работы.
Для хранения конкретных экземпляров объектов есть две фиксированные таблицы – Object, хранящая
базовые параметры документа и ObjectLinks, в которой хранятся множественные связи.
Когда пользователь создает новую сущность, например, SampleType1, то автоматически создается
таблица с аналогичным именем.
При добавлении нового свойства автоматически создается новое поле в соответствующей таблице. При
этом поле создается именно того типа, который нужен пользователю. Т.е. используются все
возможности базового ПО по работе и поддержке типов, индексации, оптимизации выборок и т.д..
Когда создается связь один-ко-многим, то создается колонка в таблице, и связь с соответствующей
Лицензия для ФИТ НГУ
27
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
таблицей.
При создании связей многие-ко-многим, значения связей хранятся в общей таблице (можно было бы и
создавать отдельную, как бы сделал разработчик вручную, но это было одно из упрощений системы).
Такой подход значительно более сложен в реализации, поскольку при разработке надо решить много
задач:
• Полностью формализовать деятельность программиста и подменить ее
• Выполнить самостоятельно все проверки на типы/ограничения базы данных и т.д.
• Избежать возможных конфликтов имен
Основным недостатком данного подхода является платформозависимость. Фактически при реализации
используются особенности и ограничения той или иной СУБД.
Главные преимущества, которое дает данный подход - это производительность и гибкость системы.
Производительность обеспечивается тем, что при таком подходе, в определенной степени
формализована и подменена работа программиста. В результате создаваемая структура получается такой
же, как бы она создавалась вручную. Только за счет полной формализации и наличия мета-описаний
структуры, программное обеспечение системы управления сайтами может сразу работать с вновь
созданными типами. Сразу после заведения новой структуры, рабочее место для публикации позволяет
размещать документы данных типов.
Гибкость обеспечивается наличием связей и мета-описаний структуры. Можно в процессе работы
системы добавлять/изменять структуру и основные функции по публикации будут продолжать работать,
и данные не будут потеряны.
4.05
Резюме
Выбранный способ реализации поддержки динамических типов данных может оказать серьезное
влияние на функционирование выбранной системы. Системы, реализованные по первым двум схемам
можно рекомендовать только для проектов, содержащих небольшой объем информации. Если
планируется использование большого объема информации, то необходимо выбирать систему, которая
реализована по модели с фиксированным списком полей или динамическими типами.
Лицензия для ФИТ НГУ
28
2004 © Elashkin Research
Выбираем CMS систему управления контентом для небольшого предприятия
5.
Copyright и торговые марки
Авторские права на данное исследование принадлежат компании Elashkin Research.
Все упоминаемые изделия и названия компаний могут быть торговыми марками или
зарегистрированными торговыми марками соответствующих владельцев.
В работе использованы примеры и снимки экранов CMS “Optimizer” (http://www.optimizer.ru/) и
технологии анализа и поиска текстовой информации Russian Context Optimizer (http://www.rco.ru/).
Лицензия для ФИТ НГУ
29
2004 © Elashkin Research