делаем таблицы и распихаем данные по ним + явный бонус, что меж таблицами можно устанавливать зависимость и прикручивать индексацию для ускорения операций. впрочем, для твоего примера имеет смысл бодание хмл вс хтмл на сравнительно малых файлах, конечно же, сикуль преимуществ показывать не будет. Однако, он есмь масштабируемая вещь и при росте кол-ва данных да усложнение структур он свой норов показывает в самом лучшем виде. а хмл -- это всего лишь текстовая форма и поиск нужной строки в среднем требует прочтения 50% хмл файла. Дажь возьмём файл в 1000 строк, то ужо на цикле в 1000 итераций получаем надобность прочитать 500 000 строк $i¢¡
два взаимоисключающих понятия... древовидную структуру в sql ты не построишь так, как ты это можешь сделать в xml или json...
никакого расхождения тут нет == древовидная структура порождается чрез зависимость меж таблицами.. более того, можно делать самые разные зависимости (на древовидных структурах свет клином не сошёлся ) и тем самым получать буст на наиболее частых операциях. короче, получаем баланс меж общим объёмом бд и скоростью её работы.
если "сикуль" представим в текстовом виде, то представь тот фрагмент кода в текстовом виде "сикуля"... таблицы имеют строго определенный набор полей, ты не можешь задать несколько объектов имеющих разные аттрибуты, но вложенные в один элемент древовидной структуры... в xml или json ты можешь это сделать... одно из основных предназначений xml и json - представление различных структур данных, в том числе древовидных... кроме того иерархия виджетов (иерархия, которую удобно описывать с помощью xml) - древовидная структура... xml не является базой данных, это формат сериализации/представления данных... и никто в здравом уме никогда не станет использовать xml как базу данных... это как сравнивать апельсины и зажигалку...
Код (C): CREATE TABLE "funcs" ( "name" TEXT, "body" TEXT, "func_id" INTEGER PRIMARY KEY NOT NULL ); CREATE TABLE "label" ( "id" TEXT, "caption" TEXT, "func" INTEGER NOT NULL ); CREATE TABLE "button" ( "id" TEXT, "caption" TEXT, "func" INTEGER NOT NULL ); каждый класс/объект получает свою таблицу, тч сборка/сравнение/загрузка/.. страницы может всячески оптимизироваться. можно любую бд делать практически на лету == никто тебе не мешает впихнуть доп. таблицы с нужным перечнем структур/атрибутов/фунок + саму бд можно всегда физически и логически оптимизировать, а вот переписывать целиком хмл для добавления новых разделов -- еть топорная операция и оптимазить её от слова СОВСЕМ ДА НИКАК в том-то и дело, что сикуль идеально может справляться с задачами хмл в различных масштабах данных
ты создал несколько таблиц, которые вообще не связаны с моим примером... при этом никаких данных ты не добавлял... повтори пример полностью и убедись, что в xml куда удобнее это описывать... окей, у тебя есть виджет Label с набором из 58 аттрибутов, каждый аттрибут может иметь значения по-умолчанию, то есть в xml ты указываешь только те параметры виджета, которые тебе нужны... создай тоже самое на sql... попробуй добавить в таблицу строку, у которой 2, 30 и 53 аттрибут имеет значение, остальные принимают значение по-умолчанию... абсолютно ничего подобного... проблема не в xml, а в твоей голове...
С реляционными БД надо поосторожнее. Они имеют свойство распухать от чрезмерного количества индексов и тормозить из-за чрезмерной нормализации. И да, в реляционных БД древовидные структуры делать сложнее, чем в XML/JSON. И далеко не все реляционные СУБД поддерживают рекурсивные SQL-запросы для обхода дерева. Да и степень свободы для обхода дерева напрямую кореллирует с количеством костылей, добавленных в SQL, при помощи которых этот обход и реализуется.
это как ещё они не связаны??? Хочешь заполнить == заполняй что касается "удобней описывать", тут речь-то не о том идёт: хмл не есть средство работы с данными, это всего лишь одна из форм структурированного аутпута и никакой особой магией обладать не может, ибо не более-чем текст. Код (Text): CREATE TABLE "funcs" ( "name" TEXT, "body" TEXT, "func_id" INTEGER PRIMARY KEY NOT NULL ); CREATE TABLE "label" ( "id" TEXT, "caption" TEXT, "ext_id" INTEGER NOT NULL, "func" INTEGER NOT NULL ); CREATE TABLE "button" ( "id" TEXT, "caption" TEXT, "ext_id" INTEGER NOT NULL, "func" INTEGER NOT NULL ); "ext_id" INTEGER NOT NULL == вот и расширяй параметры лейбла и батона ad infinitum бд, к примеру, может работать в многопоточном режиме, а обработка одного хмл в несколько потоков == еть за гранью Добра да Зла Твоя ремарка сугубо риторическая.. опять же повторюсь == сикуль есмь средство работы с данными в различных масштабах, а хмл в общем и целом всего лишь текст с последовательным доступом --- Сообщение объединено, 9 янв 2019 --- впрочем, у ext_id опцию "not null" лучше убрать.
у меня уже нет сил, я как со стеной разговариваю... не Инде единым васм полнится... ну вот когда появятся графические фреймворки, которые будут использовать sql вместо xml... когда веб перейдет на использования sql вместо html... когда веб сервисы будут использовать sql для сериализации и передачи данных вместо xml и json... вот тогда и поговорим... а на данный момент, сударь, извольте мастурбировать на свой sql, я не решусь вам мешать...
sql is backend, xml is frontend Ты слишком лично воспринимаешь обсуждение деталей вопроса Вообще, акь хухль обеспечивает столь шикарную скорость обработки запросов неужто хмл??? используется схема расширяемой детализации https://storage.googleapis.com/pub-.../68a74a85e1662fe02ff3967497f31fda7f32225c.pdf
По мне так yaml удобнее xml. Во-первых, потому что имеет полезные фичи, которых в xml нету (комменты к примеру), а во вторых т.к. структура его основана на отступах, делает файлы более организованными.
ну как такового в стандарте нет комментов... но обычно в объекте просто добавляют строковое поле _comment, если это нужно... и некоторые парсеры поддерживают си-лайк комментарии, но таких мало...
1. При чтении большого документа закопаетесь в пробелах, определяя уровень вложенности записи. 2. JSON можно сжать сильнее, как раз за счёт удаления ненужных пробелов и переносов строк. 3. Сериализация/десериализация не в один проход.
слишком экзотичный вариант для моей задачки == в сущности, склайт вполне идеален там: не надо отдельного сервача сикуля.. хотя пока непонятно с аким размером аутпута придётся иметь дело, при разбухании вопроса можь и на мускуль придётся перелезть. впрочем, основной вопрос даже не в выборе варианта сикуля аль нон-сикуля, а в самой возможности уложить расчёты на пределы стационарной макинки. Иначе же понадобится распределёнка и/ль облачка.
1. Для чтения больших документов существуют удобные текстовые редакторы, понимающие формат yaml и способные сворачивать блоки. Чай не в нулевых живем и не одним vim едины. 2. и 3. Эти минусы являются минусами только в конкретном случае, а именно при передачи по сети, причем при постоянном метании данных туда-сюда, то бишь json само собой более лучший выбор для работы с внешними API. Но YAML и не предназначался для этого, yaml больше предназначен для конфигурационной настройки софта. Из плюсов yaml: 1. Поддержка комментариев из коробки; 2. Поддержка сложных типов данных; 3. Начиная кажется с версии 1.2 yaml это надмножество json и парсер yaml будет понимать оба формата, это бывает очень удобно; 4. Всякие полезные плюшки в виде наследования, ссылки и т.д Ну и повторюсь, выбор между yaml и json, по крайней мере для меня, зависит от того, для чего я буду использовать этот формат. Для конфигурационных файлов, я последнее время выбираю именно yaml, для формата ответа всяких веб API - json.
