Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Возможность нахождения многочисленных данных на одном уровне

Читайте также:
  1. DFD - диаграмма потоков данных
  2. o возможность использования высококвалифицированных специалистов.
  3. XML и реляционные базы данных
  4. XVI-18. Согласно распределению Больцмана и барометрической формуле с ростом высоты над уровнем моря
  5. А.10. Управление Уровнем Услуг
  6. А.Г. Лукашенко. Из выступления на IV Всебелорусском народном собрании.
  7. АВТОМАТИЗИРОВАННЫЕ БАНКИ И БАЗЫ ДАННЫХ

Если одни и те же данные неоднократно повторяются в пределах объекта, вложенные элементы несомненно предпочтительней. Например, в рассмотренном выше примере объект contacts содержит множество объектов contact. Понятно, что в этом случае каждый контакт должен быть описан в элементе-потомке элемента contacts.

Однако, в реальной жизни при внесении изменений разработчики часто уходят от этого принципа проектирования. Рассмотрим, как это может происходить: сначала вы определяете, что у каждого Flazbar имеется прикрепленный к нему flizbam (а flizbam описывается одной величиной). Кажется вполне разумным сберечь дополнительное наполнение вложенных элементов и создать атрибут flizbam для тега Flazbar. Однако, затем - после того, как вы уже написали великолепный рабочий код для обработки несколькими Flazbar - вы узнаете, что в некоторых случаях у Flazbar могут быть два flizbam. Но это не проблема: вы вносите незначительные изменения в установленный код и просто переписываете DTD:

<!ATTLIST Flazbar flizbam CDATA #REQUIRED

flizbam2 CDATA #IMPLIED>

После исправления кода ваши старые XML-документы по-прежнему допустимы, и новые работоспособны. Немного погодя вы обнаруживаете, что у Flazbar может быть третий flizbam...

Трудно не соблазниться этим коварным принципом проектирования. Однако, данные и объекты развиваются, и единичные предметы часто становятся двойными или многочисленными. По этой причине некоторые XML-программисты сторонятся атрибутов, но мне кажется, это уже слишком. Мой совет - тщательно продумайте на этапе проектирования, не появится ли позднее у единичной величины элементы одного уровня. Если есть все причины полагать, что в будущем появится множество элементов одного уровня, используйте вложенные элементы с самого начала. Если же вы уверены, что объект данных будет оставаться уникальным, придерживайтесь атрибутов.


Дата добавления: 2015-08-27; просмотров: 60 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Важен ли порядок следования данных| Важность удобочитаемости

mybiblioteka.su - 2015-2024 год. (0.007 сек.)