LINUX.ORG.RU
ФорумTalks

JSON теперь в SQL: SQL/JSON

 , , , ,


2

1

Монгокапец

Объектная модель данных теперь в SQL: хранение, запросы, прозрачная интеграция с реляционной схемой.

Part 6: SQL support for JavaScript Object Notation (JSON) https://standards.iso.org/ittf/PubliclyAvailableStandards/c067367_ISO_IEC_TR_...

Уже в Постгресе (то ли в последнем выпущенном, то ли в надвигающемся).

★★★★★

Было... Дада...

Deleted ()

В постгрессе, а также адаптированно, к примеру, в джанге, уже давно есть нативный JSON, монгу все-равно не бросят те, кто на ней сидит (кодом и мозгом).

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)

Олег Бартунов про это ещё год назад говорил, по его словам — постгря быстрее монги теперь в этом.

system-root ★★★★ ()

Я ещё лет 10 назад видел эту фичу в DB2 (там правда XML было, но это не важно). JSON в постгресе тоже уже давным давно есть. Я так понимаю, монгу масштабировать проще, чем постгрес, в этом её смысл, а не в хранении жсона.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

JSON в постгресе тоже уже давным давно есть

раньше был в виде расширения, а теперь это стандарт SQL - вслед за Постгресом когда-нибудь доползет и до Оракула и до МСа

bender ★★★★★ ()
Ответ на: комментарий от bender

Он и в оракле и в ms sql давным давно есть. По-мне фигня все эти стандарты SQL, один фиг никто в здравом уме не пишет переносимый SQL. Ни холодно, ни жарко от него.

Legioner ★★★★★ ()
Ответ на: комментарий от demrnd

Эх жаль сгубили.

Хто посмел?

XML всяко лучше json

Не сказал бы. Это разные языки для разных целей. XML это язык разметки, JSON это язык для передачи программных данных. В JSON массив это массив, пусть там будет 0 элементов, 1 элемент или 10 элементов. В XML ты массив вообще никак не выразишь однозначно, чтобы понять, что это массив, нужна внешняя схема. Поэтому когда делают автоматическую сериализацию в XML, получается не очень удобно. В XML куча разных сущностей - атрибуты, теги, которые можно юзать как хочешь. Хочешь - вообще атрибуты не юзай, только теги. Хочешь - атрибуты юзай только для одиночных строковых свойств, теги для всего остального. Нет однообразия. В JSON такого нет, там всё однозначно. Зато если тебе нужен язык разметки, тут XML отлично подходит.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

А когда последовательность ключей в JSON? А когда 1 JSON надо вставить в другой? Я проклинаю JSON. С каждым днем все больше...

demrnd ()
Ответ на: комментарий от demrnd

Не понял про ключи. Последовательность в JSON реализуется последовательностью ([...]). Какие проблемы вставить 1 JSON в другой? Берёшь и вставляешь.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Берешь json от 1С {basket: []} и вставляешь туда goods от opencart {basket:[{articul: 'abc'...}...]} А потом 1С срет поносом потому что у него тоже есть articul

demrnd ()
Ответ на: комментарий от bender

SQL - вслед за Постгресом когда-нибудь доползет и до Оракула и до МСа

JSON уже года 4 как там и там.

А XML уже больше 10 лет ;)

grim ★★★☆ ()
Ответ на: комментарий от demrnd

{a: 1, b: 2, c: 3} Что раньше a или c?

Вы используете словарь вместо списка от этого у вас и умственные страдания.

если нужно упорядочить, напишите
[{a: 1}, {b: 2}, {c: 3}]

или поместите ключи в список если вам важен только порядок ключей.

grim ★★★☆ ()
Последнее исправление: grim (всего исправлений: 1)
Ответ на: комментарий от grim

умственные страдания.

Да и у создателей redis и прочих OrderedDict...

demrnd ()
Ответ на: комментарий от demrnd

поместите ключи в список если вам важен только порядок ключей.

Собственно у XML есть siblings чего нет у JSON

Вот только порядо обработки siblings парсером не гарантирован, так что если вы пишете код рассчёте на фичу конкретного парсера, то вы делаете непереносимый код.

grim ★★★☆ ()
Ответ на: комментарий от grim

Вот только порядо обработки siblings парсером не гарантирован

Ну явно XML сложнее JSON, но под винду есть 1 парсер. А под Linux 2. Код гораздо переносимее убогого JSON который я ненавижу уже пару лет...

demrnd ()
Ответ на: комментарий от demrnd

Кстати, если вам наплевать напереносимость, то большинство парсеров JS выдадут вам Object.keys({a: 1, b: 2, c: 3}) как ['a','b','c']

Так что ваши умственные страдания только от незнания предмета.

grim ★★★☆ ()
Ответ на: комментарий от demrnd

Ничего не раньше, порядок не определён. В нормальных реализациях вероятно порядок будет идентичен указанному, но полагаться на это не стоит. Нужен порядок - пиши [{"a": 1}, {"b": 2}] или что-то в этом роде.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от grim

Так что ваши умственные страдания только от незнания предмета.

Вполне возможно. Только вот я откуда узнал что с иногда раньше a если

то большинство парсеров JS выдадут вам Object.keys({a: 1, b: 2, c: 3}) как ['a','b','c']

Или я упал в этот люк?

demrnd ()
Ответ на: комментарий от demrnd

Ну явно XML сложнее JSON, но под винду есть 1 парсер. А под Linux 2.

Вы, извиняюсь какую-то хрень пишете.

Парсеров просто море не считая браузерных движков.

Код гораздо переносимее убогого JSON

Как я писал выше, ваши страдания от незнания темы.

grim ★★★☆ ()
Ответ на: комментарий от Legioner

Нужен порядок - пиши

Пишу не я. Я разбираю инциденты когда в зависимости от фазы луны нью йорк становится раньше далласа хотя там {dal:123, nyc:456}

demrnd ()
Ответ на: комментарий от demrnd

Берешь json от 1С {basket: []} и вставляешь туда goods от opencart {basket:[{articul: 'abc'...}...]} А потом 1С срет поносом потому что у него тоже есть articul

Это не проблема JSON, это проблема кривого дизайна, в котором никто не задумался о расширяемости. Должно быть что-то вроде {"basket": [{"type": "opencart", "value": {...}}, {type: "1C", value: {...}]}.

Legioner ★★★★★ ()
Ответ на: комментарий от grim

Как я писал выше, ваши страдания от незнания темы.

Вышлете мне фото своего зада чтоб я его целовал. Я говорю о фактах. Под Win 99% MsXMLParser...

Еслиб я не поел этого всего яб не говоил...

demrnd ()
Ответ на: комментарий от Legioner

В json нет NS чтоб указать что пайлоад инороден. И надо его другой json schema использовать. JSON такой шустрый, но глупый...

demrnd ()
Ответ на: комментарий от grim

Если мы говорим о JS (и его JSON.parse), то это даже в стандарте языка написано. В других парсерах и языках это, конечно, не гарантировано.

deadNightTiger ★★★★ ()
Ответ на: комментарий от demrnd

Под Win 99% MsXMLParser

Вы гоните.
Даже виндописатели им не пользуются так есть несколько сот других.

Вы на чём страдаете?
Я слышал только пых-пыхе нет нормальных переносимых решений этого дела.

grim ★★★☆ ()
Ответ на: комментарий от demrnd

Ну вот в JSON это ровно такие же атрибуты. А упорядоченная последовательность делается через []. Так же как ты в XML применяешь упорядоченную последовательность тегов и правильно делаешь. Т.е. ты сравниваешь правильный вариант в XML с неправильным вариантом в JSON, хотя и там и там можно сделать и правильно и неправильно.

Legioner ★★★★★ ()
Ответ на: комментарий от grim

Даже виндописатели им не пользуются так есть несколько сот других.

Просто для развития - назовите. Я с 2005 года винду не видел, но помню что даже в 1С MSXmlParser

demrnd ()
Ответ на: комментарий от Legioner

Ха. Я могу по tag[tag] получить список... если там более 1

demrnd ()
Ответ на: комментарий от demrnd

не нужен NS в JSON, когда можно просто отдельно рядом указать тип.

Legioner ★★★★★ ()
Ответ на: комментарий от deadNightTiger

Если мы говорим о JS (и его JSON.parse), то это даже в стандарте языка написано.

Вы не правы. JSON.parse('{«a»:1, «b»:2, «c»:3}') возвращает Object { a: 1, b: 2, c:3 } у которого порядок ключей не гарантирован.

Если нужен порядок ключей то вам нужен Map а не Object

grim ★★★☆ ()
Ответ на: комментарий от demrnd

Просто для развития - назовите

Эээээ.... вы шутите?
На каком ЯП?
поищите DOM, SAX парсеры они есть для любого ЯП

Я даже не знаю ни одного Вин или Лин специфичного.

grim ★★★☆ ()
Ответ на: комментарий от deadNightTiger

Если мы говорим о JS (и его JSON.parse), то это даже в стандарте языка написано. В других парсерах и языках это, конечно, не гарантировано.

JSON.stringify(JSON.parse('{"2": 2, "1": 1}')) == '{"1":1,"2":2}'
Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Был неправ, да. Со строками, парсящимися в числа не работает (точнее, работает в порядке увеличения).

When the abstract operation OrdinaryOwnPropertyKeys is called with Object O, the following steps are taken:

  1. Let keys be a new empty List.
  2. For each own property key P of O that is an integer index, in ascending numeric index order, do
    1. Add P as the last element of keys.
  3. For each own property key P of O that is a String but is not an integer index, in ascending chronological order of property creation, do
    1. Add P as the last element of keys.
  4. For each own property key P of O that is a Symbol, in ascending chronological order of property creation, do
    1. Add P as the last element of keys.
  5. Return keys.

Для строк, которые не парсятся в числа, работает в порядке вставки.

deadNightTiger ★★★★ ()
Ответ на: комментарий от demrnd

Такое я и сам могу накатать. Но кончился массив - а какой?

[ [1, 2], [3, 4]

Это так сложно?
Вот уж не поверю, что человек который не может разобраться в 3-х скобках, может хоть что-то понять в XML.
Ещё и пытается что-то доказывать.

surefire ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.