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

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

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

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

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

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

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

там правда XML было

Эх жаль сгубили. XML всяко лучше json

Больше скобочек!

Да но XML имел гораздо больше возможностей.

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

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

Хто посмел?

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

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

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

Типичный пример hiera. Какой ключ будет раньше?

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

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

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

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

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

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

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

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

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

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

если нужно упорядочить, напишите

И потеряйте словарь... Собственно у XML есть siblings чего нет у JSON

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

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

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

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

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

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

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

На самом деле я наверное ненавижу людей которые ВСЕ пишут в JSON. Тот же YAML считается равным JSON хотя НЕТ! https://www.youtube.com/watch?v=NNCK2xUYOJQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что раньше в XML <data a="1" b="2" c="3"/>? Вопрос абсолютно такой же. И ответ абсолютно такой же.

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

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

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

Это атрибуты верно. Но <data><a/><b/></data>

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

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

Под Win 99% MsXMLParser

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JSON.stringify(JSON.parse('{"2": 2, "1": 1}')) == '{"1":1,"2":2}'

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

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.

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

Под Linux это почти все обертки libxml под винду MSXMLParser

Кстати еще - дайте мне SAX для JSON. Сейчас я ради 1 значения парсю JSON файлы размером в сотни мегабайт...

Кстати еще - дайте мне SAX для JSON

Бери, кто тебе мешает?

А нету...

Да ну.

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

Стек

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

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

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