1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

XML vs SQL :)

Тема в разделе "WASM.HEAP", создана пользователем UbIvItS, 6 янв 2019.

  1. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.467
    делаем таблицы и распихаем данные по ним + явный бонус, что меж таблицами можно устанавливать зависимость и прикручивать индексацию для ускорения операций. впрочем, для твоего примера имеет смысл бодание хмл вс хтмл :grin: на сравнительно малых файлах, конечно же, сикуль преимуществ показывать не будет. Однако, он есмь масштабируемая вещь и при росте кол-ва данных да усложнение структур он свой норов показывает в самом лучшем виде. а хмл -- это всего лишь текстовая форма и поиск нужной строки в среднем требует прочтения 50% хмл файла.

    Дажь возьмём файл в 1000 строк, то ужо на цикле в 1000 итераций получаем надобность прочитать 500 000 строк $i¢¡ :crazy:
     
  2. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.143
    два взаимоисключающих понятия... древовидную структуру в sql ты не построишь так, как ты это можешь сделать в xml или json...
     
  3. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.467
    никакого расхождения тут нет == древовидная структура порождается чрез зависимость меж таблицами.. более того, можно делать самые разные зависимости (на древовидных структурах свет клином не сошёлся :) ) и тем самым получать буст на наиболее частых операциях. короче, получаем баланс меж общим объёмом бд и скоростью её работы.
     
  4. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.143
    если "сикуль" представим в текстовом виде, то представь тот фрагмент кода в текстовом виде "сикуля"...

    таблицы имеют строго определенный набор полей, ты не можешь задать несколько объектов имеющих разные аттрибуты, но вложенные в один элемент древовидной структуры... в xml или json ты можешь это сделать...

    одно из основных предназначений xml и json - представление различных структур данных, в том числе древовидных... кроме того иерархия виджетов (иерархия, которую удобно описывать с помощью xml) - древовидная структура...

    xml не является базой данных, это формат сериализации/представления данных... и никто в здравом уме никогда не станет использовать xml как базу данных... это как сравнивать апельсины и зажигалку...
     
  5. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.467
    Код (C):
    1. CREATE TABLE "funcs" (
    2.     "name" TEXT,
    3.     "body" TEXT,
    4.     "func_id" INTEGER PRIMARY KEY NOT NULL
    5. );
    6. CREATE TABLE "label" (
    7.     "id" TEXT,
    8.     "caption" TEXT,
    9.     "func" INTEGER NOT NULL
    10. );
    11. CREATE TABLE "button" (
    12.     "id" TEXT,
    13.     "caption" TEXT,
    14.     "func" INTEGER NOT NULL
    15. );
    каждый класс/объект получает свою таблицу, тч сборка/сравнение/загрузка/.. страницы может всячески оптимизироваться.
    можно любую бд делать практически на лету == никто тебе не мешает впихнуть доп. таблицы с нужным перечнем структур/атрибутов/фунок + саму бд можно всегда физически и логически оптимизировать, а вот переписывать целиком хмл для добавления новых разделов -- еть топорная операция и оптимазить её от слова СОВСЕМ ДА НИКАК :)
    в том-то и дело, что сикуль идеально может справляться с задачами хмл в различных масштабах данных :grin:
     
  6. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.143
    ты создал несколько таблиц, которые вообще не связаны с моим примером... при этом никаких данных ты не добавлял... повтори пример полностью и убедись, что в xml куда удобнее это описывать...

    окей, у тебя есть виджет Label с набором из 58 аттрибутов, каждый аттрибут может иметь значения по-умолчанию, то есть в xml ты указываешь только те параметры виджета, которые тебе нужны... создай тоже самое на sql... попробуй добавить в таблицу строку, у которой 2, 30 и 53 аттрибут имеет значение, остальные принимают значение по-умолчанию...

    абсолютно ничего подобного... проблема не в xml, а в твоей голове...
     
  7. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    С реляционными БД надо поосторожнее. Они имеют свойство распухать от чрезмерного количества индексов и тормозить из-за чрезмерной нормализации.
    И да, в реляционных БД древовидные структуры делать сложнее, чем в XML/JSON. И далеко не все реляционные СУБД поддерживают рекурсивные SQL-запросы для обхода дерева. Да и степень свободы для обхода дерева напрямую кореллирует с количеством костылей, добавленных в SQL, при помощи которых этот обход и реализуется.
     
  8. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.467
    это как ещё они не связаны??? Хочешь заполнить == заполняй :) что касается "удобней описывать", тут речь-то не о том идёт: хмл не есть средство работы с данными, это всего лишь одна из форм структурированного аутпута и никакой особой магией обладать не может, ибо не более-чем текст.
    Код (Text):
    1. CREATE TABLE "funcs" (
    2.     "name" TEXT,
    3.     "body" TEXT,
    4.     "func_id" INTEGER PRIMARY KEY NOT NULL
    5. );
    6. CREATE TABLE "label" (
    7.     "id" TEXT,
    8.     "caption" TEXT,
    9.     "ext_id" INTEGER NOT NULL,
    10.     "func" INTEGER NOT NULL
    11. );
    12. CREATE TABLE "button" (
    13.     "id" TEXT,
    14.     "caption" TEXT,
    15.     "ext_id" INTEGER NOT NULL,
    16.     "func" INTEGER NOT NULL
    17. );
    "ext_id" INTEGER NOT NULL == вот и расширяй параметры лейбла и батона ad infinitum :grin:
    бд, к примеру, может работать в многопоточном режиме, а обработка одного хмл в несколько потоков == еть за гранью Добра да Зла :)
    Твоя ремарка сугубо риторическая.. опять же повторюсь == сикуль есмь средство работы с данными в различных масштабах, а хмл в общем и целом всего лишь текст с последовательным доступом :)
    --- Сообщение объединено, 9 янв 2019 ---
    впрочем, у ext_id опцию "not null" лучше убрать.
     
  9. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.143
    у меня уже нет сил, я как со стеной разговариваю... не Инде единым васм полнится... ну вот когда появятся графические фреймворки, которые будут использовать sql вместо xml... когда веб перейдет на использования sql вместо html... когда веб сервисы будут использовать sql для сериализации и передачи данных вместо xml и json... вот тогда и поговорим... а на данный момент, сударь, извольте мастурбировать на свой sql, я не решусь вам мешать...
     
  10. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.467
    sql is backend, xml is frontend :)
    Ты слишком лично воспринимаешь обсуждение деталей вопроса :) Вообще, акь хухль обеспечивает столь шикарную скорость обработки запросов неужто хмл???:crazy::laugh1::laugh2::laugh3: используется схема расширяемой детализации https://storage.googleapis.com/pub-.../68a74a85e1662fe02ff3967497f31fda7f32225c.pdf
     
  11. CheckOut

    CheckOut New Member

    Публикаций:
    0
    Регистрация:
    14 фев 2018
    Сообщения:
    24
    По мне так yaml удобнее xml. Во-первых, потому что имеет полезные фичи, которых в xml нету (комменты к примеру), а во вторых т.к. структура его основана на отступах, делает файлы более организованными.
     
  12. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.143
  13. CheckOut

    CheckOut New Member

    Публикаций:
    0
    Регистрация:
    14 фев 2018
    Сообщения:
    24
  14. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    YAML - гуано ещё то.
     
  15. CheckOut

    CheckOut New Member

    Публикаций:
    0
    Регистрация:
    14 фев 2018
    Сообщения:
    24
    Обоснуйте, иначе звучит как "<что угодно> - гуано ещё то."
     
  16. xSQL

    xSQL New Member

    Публикаций:
    0
    Регистрация:
    22 сен 2018
    Сообщения:
    7
    Может вообще mongodb заюзать?
     
  17. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.143
    ну как такового в стандарте нет комментов... но обычно в объекте просто добавляют строковое поле _comment, если это нужно... и некоторые парсеры поддерживают си-лайк комментарии, но таких мало...
     
  18. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.543
    Адрес:
    г. Санкт-Петербург
    1. При чтении большого документа закопаетесь в пробелах, определяя уровень вложенности записи.
    2. JSON можно сжать сильнее, как раз за счёт удаления ненужных пробелов и переносов строк.
    3. Сериализация/десериализация не в один проход.
     
  19. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    4.467
    слишком экзотичный вариант для моей задачки == в сущности, склайт вполне идеален там: не надо отдельного сервача сикуля.. хотя пока непонятно с аким размером аутпута придётся иметь дело, при разбухании вопроса можь и на мускуль придётся перелезть. впрочем, основной вопрос даже не в выборе варианта сикуля аль нон-сикуля, а в самой возможности уложить расчёты на пределы стационарной макинки. Иначе же понадобится распределёнка и/ль облачка. :)
     
  20. CheckOut

    CheckOut New Member

    Публикаций:
    0
    Регистрация:
    14 фев 2018
    Сообщения:
    24
    1. Для чтения больших документов существуют удобные текстовые редакторы, понимающие формат yaml и способные сворачивать блоки. Чай не в нулевых живем и не одним vim едины.
    2. и 3. Эти минусы являются минусами только в конкретном случае, а именно при передачи по сети, причем при постоянном метании данных туда-сюда, то бишь json само собой более лучший выбор для работы с внешними API. Но YAML и не предназначался для этого, yaml больше предназначен для конфигурационной настройки софта.

    Из плюсов yaml:
    1. Поддержка комментариев из коробки;
    2. Поддержка сложных типов данных;
    3. Начиная кажется с версии 1.2 yaml это надмножество json и парсер yaml будет понимать оба формата, это бывает очень удобно;
    4. Всякие полезные плюшки в виде наследования, ссылки и т.д

    Ну и повторюсь, выбор между yaml и json, по крайней мере для меня, зависит от того, для чего я буду использовать этот формат. Для конфигурационных файлов, я последнее время выбираю именно yaml, для формата ответа всяких веб API - json.