Спасибо за ссылку. Да, реализация отстает, особенно в публично доступных сервисах. Мне-то больше интересна концепция, но, видимо, не смог её коротко и вместе с тем ясно изложить. Вынес ответ на первый комментарий в текст самой статьи.
А про «тучи», если интересно… Вот попался на днях гартнеровский прогноз:
By 2023, 75% of all databases will be on a cloud platform, reducing the DBMS vendor landscape and increasing complexity for data governance and integration.
By 2022, 50% of cloud buying decisions will be based on data assets provided by the cloud service provider rather than on product capabilities.
Прошу прощения за задержку с ответом. Нет, REPL CLI умеет только работать с данными в абстрактной модели PartiQL (которая тем самым становится не такой уж и абстрактной). Отображать в нее данные из внешних источников он не умеет.
Если очень хочется попробовать, в Redshift Spectrum поддержка PartiQL более полная, чем в S3 Collect. Нужно создавать внешние таблицы как описано здесь.
Еще, говорят, PartiQL поддерживается в Amazon QLDB, но тот в статусе превью.
У вас скриншот из таблички 2017 года, но в табличке 2018 один наш соотечественник его уже обогнал (и в табличке за 2017 год у ряда соотечественников поле со страной не было заполнено).
Бегло посмотрел на Google Scholar и пр. соотечественников — лидеров рейтинга. Особо криминального ничего не увидел. Появились даже некоторые сомнения в полноте данных, собранных авторами статьи, и в методике расчета этого %self.
Я вижу небольшую проблему в том, что статьи нынче пишутся авторскими коллективами. Если совсем не учитывать статьи, имеющие хотя бы минимальное пересечение по авторам, то окажется не учтено, как мне кажется, достаточно много добросовестных цитирований.
Во-вторых, если сети цитирований хранятся в БД (а они хранятся), то расчет показателей «на лету» с учетом добавляемого ограничения становится немного более проблематичным.
В других комментариях уже написали про круговые цитирования. Тут, с одной стороны, все не безнадежно: вон, Stack Overflow довольно успешно борется с vote rings. С другой, феномен невидимого колледжа лежит в основании нынешней науки, можно с водой выплеснуть и ребенка.
Кстати, попиарю, можно сказать, коллегу по одному совсем-совсем невидимому колледжу: там, конечно, не про наукометрию, но тоже графы, сети...
Доминирующей формой цитирования в этой ситуации становится самоцитирование.
Получается, все-таки туземная…
Краткое содержание всей статьи
Грубо говоря, если провинциальная наука — это карго-аэропорт, подающий сигналы настоящим самолетам, которые этих сигналов не слышат и никогда на него не садятся, то туземная — это аэропорт, который подает сигналы самолетам воображаемым, и эти самолеты регулярно на такой аэродром садятся.
Если разработчики подписываются под то, что реализовали функционал из SQL/JSON (частичный или полностью), тогда получается, что работа с JSON интегрирована в язык.
В первой части соответствующего change proposal создатели стандарты писали, что давайте делать все «using built-in functions». То есть существуют, значит, какие-то иные способы, и есть между этими способами некоторая разница.
На самом деле, конечно, сделали по образу и подобию поддержки XML, особо головой не подумав. Тогда подумать было некогда (или не захотели связываться), а сейчас лень.
Но больше тут вопрос языкового пуризма, конечно. Я вот пурист.
Ну и в (спеке PartiQL) нет вообще информации по JSONPath
У них это называется path navigation, которая бывает всего видов: tuple navigation и array navigation. И примечание: «notice that consecutive tuple/array navigations… navigate deeply into complex value».
Кстати какого функционала не хватает в реализации JSONPath по SQL/JSON?
Пройдусь по двум пунктам из своего поста («вот что делает иерархически организованные данные практически сущностями первого класса в PartiQL»), от второго к первому:
я так и не понял, как в SQL/JSON получить список ключей, и лучше в привязке к значениям, а не просто значения.
эти селекторы не «созависимы». Например, насколько понимаю, при SELECT JSON_VALUE(T.J, '$.persons[*].name'), JSON_VALUE(T.J, '$.persons[*].surname'), мы получим декартово произведение множеств имен и фамилий. То есть утрачивается реляционность. Может, можно сделать что-то с помощью JSON_TABLE, но уж больно все громоздко, я не разбирался.
поэтому вы будете думать почему привычное вам перестало работать
Обещают, что при представлении в абстрактной модели PartiQL чисто реляционных данных все запросы из SQL-92 останутся работоспособными. В конце концов, для разбирательств есть формальная семантика PartiQL. В других «очередных языках» с этим хуже.
Реального мира нет, он съеден софтом, а софт подъедается облаками. Но ОК, пусть приватные и гибридные облака тоже имеют кусок.
Для тех, кого не съели, в оригинальной записи в блоге предлагается архитектурная картинка. Я бы сказал, что тут примерно как с GraphQL. Стандартный путь — сделать resolver, который работает с имеющимся хранилищем. Но некоторые хранилища начинают и сами понимать GraphQL (тот же Stardog, упомянутый в статье).
Вот в Couchbase, например, уже поддержали SQL++, сейчас вроде раздумывают, реализовать ли PartiQL.
Но что дальше?
Цель этой статьи была в том, чтобы на примере AWS (в предположении, что там все делают правильно), ответить на следующие вопросы:
Какие парадигмы интеграции данных нынче актуальны? С организационной точки зрения, так сказать. Ответ — NoETL, data fabric и пр.
Как это реализуется технически? Ответ — виртуализация источников, универсализация языков.
Что будет после этого (хоть и к этому еще не все пришли)? Ответ — похоже, мультимодельность.
Ну а системы, делающие все «правильно», есть и в «реальном мире».
Нет. Там упор на функции по работе с JSON, а здесь работа с JSON интегрирована в язык. Вероятно, авторы подумали: язык-то декларативный когда-то был, может, хватит его функциями раздувать? За счёт этого иерархические данные стали сущностями.
И поэтому здесь, например, оказалось возможным поддержать лишь совсем базовый JSONPath, а там поддерживаемые возможности JSONPath раздуты чуть ли не до имеющихся в XPath.
Автору бы постесняться, языков программирования не в пример больше, чем языков запросов, и ничего.
Согласен, что «мусорных языков запросов» действительно много. Но ограничиться одним SQL не выйдет, коль скоро есть модели данных, отличные от реляционной. Прелесть PartiQL как раз в том, что это более-менее естественное расширение SQL. Одному из авторов SQL даже понравилось.
Половина статьи по ссылке про ORM, не про языки запросов. Я бы уклонился от обсуждения по существу, а развернул бы эту часть его рассуждений против другой, про языки запросов. Можно сказать, что разные language integrated queries как раз для тех, кому лень выучить даже язык запросов.
Смысл в том, что при проходе древовидной структуры мы как бы генерируем таблицу. Первый столбец — где были на первом шаге, второй — где на втором. Чем правее столбец, тем больше в нем уникальных значений. «Маршрут» — это такой rowset provider, как OPENXML в MS SQL Server. Потом эти таблички можно подджойнивать к чему-нибудь или друг к другу.
Менее утрированное объяснение — разделы 3.3 и 5.3 спецификации.
Мне не кажется, что это основная мысль текста. Но так действительно бывает. Положим, массовое ИТ — дело нехитрое и большого ума не требующее, но бизнес ведь требует еще меньше. Автор тут говорит об автоматизации именно бизнеса. Бизнес может требовать чего-то ещё помимо ума, но при составлении ТЗ используется в основном ум. И ум я имею в виду тот, который используется при составлении ТЗ :).
С OpenLink Software создателей NitrosBase связывают достаточно давние напряженные отношения :-). Подробнее на этот и следующий ваши комментарии отвечу попозже.
Спасибо за ссылку. Да, реализация отстает, особенно в публично доступных сервисах. Мне-то больше интересна концепция, но, видимо, не смог её коротко и вместе с тем ясно изложить. Вынес ответ на первый комментарий в текст самой статьи.
А про «тучи», если интересно… Вот попался на днях гартнеровский прогноз:
Не сомневаюсь, что в стихах это было прекрасно, просто прекрасно.
Нигерийские письма больше не работают, и автор, судя по профилю на Medium, создал криптовалютную биржу. Кто бы сомневался…
Прошу прощения за задержку с ответом. Нет, REPL CLI умеет только работать с данными в абстрактной модели PartiQL (которая тем самым становится не такой уж и абстрактной). Отображать в нее данные из внешних источников он не умеет.
Если очень хочется попробовать, в Redshift Spectrum поддержка PartiQL более полная, чем в S3 Collect. Нужно создавать внешние таблицы как описано здесь.
Еще, говорят, PartiQL поддерживается в Amazon QLDB, но тот в статусе превью.
У вас скриншот из таблички 2017 года, но в табличке 2018 один наш соотечественник его уже обогнал (и в табличке за 2017 год у ряда соотечественников поле со страной не было заполнено).
Бегло посмотрел на Google Scholar и пр. соотечественников — лидеров рейтинга. Особо криминального ничего не увидел. Появились даже некоторые сомнения в полноте данных, собранных авторами статьи, и в методике расчета этого %self.
Вот прямо-таки теории графов? Не графовой модели данных, графовых СУБД, графовых алгоритмов?
Мне кажется, вы собираетесь описывать то, что называется 360-Degree View. С удовольствием почитаю, всегда хотел узнать об этом больше.
Я вижу небольшую проблему в том, что статьи нынче пишутся авторскими коллективами. Если совсем не учитывать статьи, имеющие хотя бы минимальное пересечение по авторам, то окажется не учтено, как мне кажется, достаточно много добросовестных цитирований.
Во-вторых, если сети цитирований хранятся в БД (а они хранятся), то расчет показателей «на лету» с учетом добавляемого ограничения становится немного более проблематичным.
В других комментариях уже написали про круговые цитирования. Тут, с одной стороны, все не безнадежно: вон, Stack Overflow довольно успешно борется с vote rings. С другой, феномен невидимого колледжа лежит в основании нынешней науки, можно с водой выплеснуть и ребенка.
Кстати, попиарю, можно сказать, коллегу по одному совсем-совсем невидимому колледжу: там, конечно, не про наукометрию, но тоже графы, сети...
Да было уже, было: https://habr.com/ru/company/yandex/blog/464315/
Из нашумевшей лет пять назад статьи Соколов М. М., Титаев К. Д. Провинциальная и туземная наука:
Получается, все-таки туземная…
Грубо говоря, если провинциальная наука — это карго-аэропорт, подающий сигналы настоящим самолетам, которые этих сигналов не слышат и никогда на него не садятся, то туземная — это аэропорт, который подает сигналы самолетам воображаемым, и эти самолеты регулярно на такой аэродром садятся.
Интересно, а такое к теме относится? —
В первой части соответствующего change proposal создатели стандарты писали, что давайте делать все «using built-in functions». То есть существуют, значит, какие-то иные способы, и есть между этими способами некоторая разница.
На самом деле, конечно, сделали по образу и подобию поддержки XML, особо головой не подумав. Тогда подумать было некогда (или не захотели связываться), а сейчас лень.
Но больше тут вопрос языкового пуризма, конечно. Я вот пурист.
У них это называется path navigation, которая бывает всего видов: tuple navigation и array navigation. И примечание: «notice that consecutive tuple/array navigations… navigate deeply into complex value».
Пройдусь по двум пунктам из своего поста («вот что делает иерархически организованные данные практически сущностями первого класса в PartiQL»), от второго к первому:
SELECT JSON_VALUE(T.J, '$.persons[*].name'), JSON_VALUE(T.J, '$.persons[*].surname'), мы получим декартово произведение множеств имен и фамилий. То есть утрачивается реляционность. Может, можно сделать что-то с помощьюJSON_TABLE, но уж больно все громоздко, я не разбирался.Обещают, что при представлении в абстрактной модели PartiQL чисто реляционных данных все запросы из SQL-92 останутся работоспособными. В конце концов, для разбирательств есть формальная семантика PartiQL. В других «очередных языках» с этим хуже.
Реального мира нет, он съеден софтом, а софт подъедается облаками. Но ОК, пусть приватные и гибридные облака тоже имеют кусок.
Для тех, кого не съели, в оригинальной записи в блоге предлагается архитектурная картинка. Я бы сказал, что тут примерно как с GraphQL. Стандартный путь — сделать resolver, который работает с имеющимся хранилищем. Но некоторые хранилища начинают и сами понимать GraphQL (тот же Stardog, упомянутый в статье).
Вот в Couchbase, например, уже поддержали SQL++, сейчас вроде раздумывают, реализовать ли PartiQL.
Цель этой статьи была в том, чтобы на примере AWS (в предположении, что там все делают правильно), ответить на следующие вопросы:
Ну а системы, делающие все «правильно», есть и в «реальном мире».
Имелось в виду «сущностями первого класса».
Нет. Там упор на функции по работе с JSON, а здесь работа с JSON интегрирована в язык. Вероятно, авторы подумали: язык-то декларативный когда-то был, может, хватит его функциями раздувать? За счёт этого иерархические данные стали сущностями.
И поэтому здесь, например, оказалось возможным поддержать лишь совсем базовый JSONPath, а там поддерживаемые возможности JSONPath раздуты чуть ли не до имеющихся в XPath.
Автору бы постесняться, языков программирования не в пример больше, чем языков запросов, и ничего.
Согласен, что «мусорных языков запросов» действительно много. Но ограничиться одним SQL не выйдет, коль скоро есть модели данных, отличные от реляционной. Прелесть PartiQL как раз в том, что это более-менее естественное расширение SQL. Одному из авторов SQL даже понравилось.
Половина статьи по ссылке про ORM, не про языки запросов. Я бы уклонился от обсуждения по существу, а развернул бы эту часть его рассуждений против другой, про языки запросов. Можно сказать, что разные language integrated queries как раз для тех, кому лень выучить даже язык запросов.
Следуя такой логике, не быть каннибалом тоже невозможно :-).
P..S. Не хотел бы встревать в спор вегетарианцев и их противников, я просто о логике рассуждений.
Смысл в том, что при проходе древовидной структуры мы как бы генерируем таблицу. Первый столбец — где были на первом шаге, второй — где на втором. Чем правее столбец, тем больше в нем уникальных значений. «Маршрут» — это такой rowset provider, как
OPENXMLв MS SQL Server. Потом эти таблички можно подджойнивать к чему-нибудь или друг к другу.Менее утрированное объяснение — разделы 3.3 и 5.3 спецификации.
Мне не кажется, что это основная мысль текста. Но так действительно бывает. Положим, массовое ИТ — дело нехитрое и большого ума не требующее, но бизнес ведь требует еще меньше. Автор тут говорит об автоматизации именно бизнеса. Бизнес может требовать чего-то ещё помимо ума, но при составлении ТЗ используется в основном ум. И ум я имею в виду тот, который используется при составлении ТЗ :).
Не могу удержаться от того, чтобы процитировать фрагмент переписки с одной прекрасной дамой:
Удачи вам и успехов!
С OpenLink Software создателей NitrosBase связывают достаточно давние напряженные отношения :-). Подробнее на этот и следующий ваши комментарии отвечу попозже.