Я давно собирался написать о том, почему метки (они же ярлычки, они же тэги) являются не только удобным способом классификации сообщений в блоге и инструментом эффективного поиска. За этим механизмом скрывается намного более мощная идея. Идея структурирования данных «на лету». Сейчас стало модным к любому понятию приписывать слово dynamic. Так вот метки – это механизм реализации динамических структур данных. Только мы, вскормленные на реляционной модели данных, об этом совершенно не задумываемся.
Как выглядит процесс проектирования структур данных последние дцать лет? Очень крутой специалист, именуемый аналитиком, собирает различные объекты, относящиеся к автоматизируемой задаче. Сравнивает их друг с другом, выписывает свойства и проводит классификацию. В результате появляется набор классов, имеющих определенные свойства и состоящие друг с другом в некоторых отношениях: клиент-заказ-позиция-товар и т.д. Дальше все это раскладывается в структуру базы данных и набор бизнес-объектов. Пока все хорошо. Плохо будет потом, когда у вас на предприятии заведутся десятки различных бизнес-приложений, с разными структурами данных для представления одних и тех же бизнес объектов. Еще хуже станет в тот момент, когда вы решите осуществить интеграцию таких бизнес приложений.
Причем здесь метки? Дело в том, что они играют ту же самую роль, что и вторичные ключевые поля в реляционных базах данных, а именно логически связывают друг с другом различные записи. Вторичный ключ – это поле в таблице, содержащее идентификатор какой-либо записи из другой таблицы. Проще говоря, ссылка. Например, если в таблице городов запись города Москва имеет идентификатор 77, то в таблице номерных знаков автомобилей, в поле города регистрации всех московских авто будет написано не слово «Москва», а цифра 77.
Разница между ссылками в базе данных и метками лишь в том, что структура базы данных вашего приложения создавалась неизвестным программистом в далеком прошлом, а добавить к информационному объекту новую метку вы можете в любой момент. Это позволяет сохранять отношения между объектами, о которых разработчик приложения даже и не подозревал. Причем изменять структуру можно в ходе всего цикла использования информационного ресурса.
Еще одно замечание. Для придания метке уникальности во всемирном масштабе, лучше использовать не слова и выражения русского или английского языка, а URI. Метка превращается в ссылку и, волшебным образом, круг создания всемирного хранилища данных замыкается.
Я всеми лапами за метки, но структурирование уже самих меток и релевантное описание объектов метками наталкивается на “человеческий фактор”. Люди одно и то же описывают различными метками, что затрудняет поиск на больших объемах данных. То есть нужна “редакционная политика” при разметке, следование этой политике всеми участниками внесения инфы в базы и преемственность системы меток от одного поколения к другому. А все, что завязано на работу человеческого мозга, скорее, приведет к хаосу, чем к порядку)))
Я даже думаю, что нужен специальный человек, в обязанности которого будет входить контроль соблюдения договоренностей и исправление меток.
Ага. и карта меток размером в стену)))