Планирование данных
Я думаю, вам уже стало понятно, что без планирования Web-узел не создать. Этот вопрос остается в силе и для динамических узлов. Единственным отличием, по сравнению со статическими узлами, является то, что наряду с планированием содержания придется планировать и типы динамического материала, размещаемого на узле. Вам потребуется определить категории информации, помещаемой в базу данных. В случае с фотографом в базу данных нужно будет помещать примеры его работ. Категориями информации в данном случае будут набор фотографий, клиенты и посетители. Подкатегориями собрания работ будут портреты, пейзажи и т.п.
Быстрое и эффективное представление данных
При планировании данных нужно мыслить категориями компьютера и логически сформировать базу данных. Говоря терминами Web-дизайнеров, исключения только подтверждают истину. Например, дизайн книжной лавки в Web должен отражать схемы покупки. Каждый раз, когда посетитель входит на узел Araazon.com (один из крупнейших узлов электронной розничной торговли. – Прим, перев.), отображаемая страница изменяется. Узел Amazon всегда старается предложить книги, наиболее полно соответствующие вкусам посетителя. Представьте себе, что произойдет, если на первой странице посетителю предложить книги по огородничеству, а он раньше всегда покупал только триллеры. Естественно, посетитель задаст себе вопрос, действительно ли он попал на узел Amazon, и при чем тут садовые культуры. Ему придется потратить лишнее время на то, чтобы найти интересующую его тематическую литературу. Если такая ситуация будет повторяться постоянно, он может уйти с узла навсегда. Время – это то, что пользователи не хотят выбрасывать на ветер, перемещая курсор между различными категориями базы данных в поиске нужной информации.
Итак, для начала задайте себе несколько вопросов.
- Что будет храниться в базе данных? Не пытайтесь ответить обычным словом текст, так как это – достаточно широкое понятие. В нашем случае под текстом может пониматься описание продукции, список имен покупателей и даже пароли для входа на узел.
- Как выглядит каждый фрагмент информации? Здесь имеется в виду не тип шрифта и его размеры. Если элемент – это описание продукции, в базе данных он будет представлять собой текстовое поле. Например, если в этом поле будет храниться название продукции, оно должно иметь фиксированную длину. Если в поле должен храниться текст заранее неизвестной длины, оно должно иметь тип memo.
- Как будут представлены данные? К этому вопросу нужно подойти творчески, так как на динамических узлах данные обычно отображают в табличном виде. В данном случае в каждой ячейке таблицы должна содержаться определенная информация, сформатированная в понятном представлении.
- Имеется ли под рукой готовая модель, удовлетворяющая потребности? Модель – это определение того, как данные будут храниться в базе. В ней должны описываться поля, хранящие отдельные фрагменты информации, а также логические группы этих полей, специфичные для конкретной функции. Хорошим примером может стать карточка покупки на узле электронной коммерции. Когда выбирается какой-либо товар, данные помещаются в поля таблицы карточки покупки. Эти данные могут состоять из идентификатора товара, его цены и покупаемого количества. Естественно, при определении цены должны учитываться скидки, рекламные кампании и прочие параметры. Например, посетитель решил купить две белые майки по цене 10 долларов за штуку. Если при этом он решил еще купить двое брюк по 25 долларов за пару, окажется, что для хранения итоговой суммы покупки нужно отдельное поле. Модель доски объявлений, подходящая для узла фотографа, демонстрирующего свои работы, совершенно не годится для узла электронной коммерции, на котором он эти же работы продает. Самая большая ошибка, которую можно допустить в этом вопросе, – это скопировать знакомую модель и построить технологию вокруг нее. Такой путь не эффективен. Модель должна в точности соответствовать поставленным перед узлом задачам.
- Существуют ли повторы? Если да, то такие фрагменты данных нужно объединить. Например, если в базе должны храниться имена пользователей и их адреса, не имеет смысла создавать для них отдельную таблицу, если такая информация уже хранится в учетных записях. Информация о пользователе может быть повторно использована, когда он из разряда посетителей переходит в разряд покупателей (т.е. плательщиков) или когда он подписывается на информацию о рекламных акциях компании. Наличие десятка копий одной и той же информации указывает на неправильную организацию данных.
Планирование включает в себя вопросы настоящего и будущего. По мере изменения ассортимента продукции ошибки планирования выходят наружу и могут превратить вашу жизнь в сплошной кошмар. Гораздо проще спланировать добавление, например галстуков или рубашек еще на стадии создания модели. Будет чрезвычайно сложно и дорого вставить эту операцию в модель, которая это изначально не предусматривала. Если вам кажется, что вы не можете самостоятельно спланировать модель базы данных, которая в точности соответствует вашим потребностям, лучше обратиться к специалисту в этой области.