Зачем придумывают всё новые языки-велосипеды?

Какая из них более распространена, чем SQLite?

Berkley, Redis, HSQLDB способны догнать SQLite. Но да, пока что SQLite незаслужено доминирует.

Блин, даже в браузер и файлы журналов 1С уже SQLite запихнули (хотя он там как собаке пятая нога).

Вот именно - SQLite там не нужен. Его там используют, потому что проще найти хорошего кодера, знакомого с SQL. Подобными причинами обусловленные многие неоптимальные выборы инструментов.

COBOL тоже активно используется. Сколько проектов, начатых после 2010 на MS Access?

Мало, но только потому, что у MS Access появилось огромное кол-во конкурентов - это куча софтин и сервисов, которые позволяют за ящик водки сделать склад/бухгалтерию.

Berkley, Redis, HSQLDB способны догнать SQLite.

HSQLDB - тоже SQL. Berkeley DB была в той нише, где сейчас SQLite и её доля уменьшается.

Его там используют, потому что проще найти хорошего кодера, знакомого с SQL.

Нет. Потому что «а вдруг пользователю захочется запрос с другими условиями, группировками, итогами». Для BDB или DBF нужно писать свой движок запросов или сильно ограничивать пользователя, для SQL произвольная структура запроса просто транслируется в SQL.

Но даже в пике популярности SQL было не единственным средством, и тот же Borland в это же время довольно неплохо себя чувствовал со своими NoSQL инструментами.

Это какими? Paradox и Interbase были SQL. dBase не совсем Borland'овский. И dBase был фактическим стандартом, но со временем вытеснен SQL, как только позволила производительность компьютеров.

HSQLDB - тоже SQL. Berkeley DB была в той нише, где сейчас SQLite и её доля уменьшается.

Да. Много кодеров из сервер-клиентов идут на локалхост, потому что на сервере они больше не нужны. Это примерно как кодеры на JS, которых слишком много, чтобы уместить во фронтенде, потому они просачиваются на бэкэнд.

Потому что «а вдруг пользователю захочется запрос с другими условиями, группировками, итогами». Для BDB или DBF нужно писать свой движок запросов или сильно ограничивать пользователя

Владение SQL запросами - это не такой уж распространенный навык, чтобы говорить о том, что кто попало может просто написать запрос с другими параметрами для своих нужд. Так-то разбор примитивных правил я и сам писал. Собсна, вся 1С - это сплошной костыль разбора и трансляции пользовательских выражений.

Но да, наличие общеизвестного языка является довольно важным фактором. Правда, я сомневаюсь, что много пользователей Firefox умеют делать запросы ко встроенной базе данных.

Но даже в пике популярности SQL было не единственным средством, и тот же Borland в это же время довольно неплохо себя чувствовал со своими NoSQL инструментами.

Это какими? Paradox и Interbase были SQL. dBase не совсем Borland'овский. И dBase был фактическим стандартом, но со временем вытеснен SQL, как только позволила производительность компьютеров.

https://ru.wikipedia.org/wiki/BDE

Это примерно как кодеры на JS, которых слишком много, чтобы уместить во фронтенде, потому они просачиваются на бэкэнд.

Вот, кстати, такой же пример про удобство. Вместо Python теперь на бэкенде всё чаще JS. Также как раньше вместо PERL'а стал Python. И даже Electron вместо кроссплатформенного интерфейса.

Владение SQL запросами - это не такой уж распространенный навык, чтобы говорить о том, что кто попало может просто написать запрос с другими параметрами для своих нужд. Так-то разбор примитивных правил я и сам писал.

Я имею в виду, что можно дать форму настройки с группировками/итогами фильтрами и их произвольная комбинация очень легко транслируется в SQL. На BDB или DBF всё не так просто.

Собсна, вся 1С - это сплошной костыль разбора и трансляции пользовательских выражений.

Как-то очень однобоко. Система компоновки данных — очень малая часть 1С 8. А в 1С 7.7 вообще пользовательских выражений не было: хочешь менять структуру запроса, идёшь в конфигуратор.

https://ru.wikipedia.org/wiki/BDE

Так там SQL был в качестве языка запросов. Даже по твоей ссылке

В BDE используется «Local SQL», подмножество стандарта ANSI-92 языка SQL, расширенное для поддержки используемых в Paradox и DBF (называемых в BDE «стандартными» таблицами) соглашений о наименовании таблиц и полей.

Так там SQL был в качестве языка запросов. Даже по твоей ссылке

Ага, давай, порассказывай мне истории о том, что же там на самом деле было. Естественно, BDE - это сборная солянка, которая должна была объединять dBase, paradox, foxpro, при этом с опциональным подключением к серверам. Такой себе перечинный ножик, который в этой роли не взлетел, потому что работа с серверными БД таки заметно отличается от локальных. Там была поддержка SQL, но именно из-за фундаментальной ориентации на локальные базы, когда программа может спокойно делать разные дополнительные дешевые запросы, подключение к серверам было неэффективно.

В пределе это будет SQL СУБД в виде библиотеки.

но ведь sql в пределе - сам просто find по массивам, слегка поперчёный алгебраическими типами данных (результат этих ваших джоинов) и всё

но как тогда писать «t1 LEFT JOIN t2

a->first->id == b->second->id && b->second->id;

как указать переименование полей, если в t1 и t2 с одинаковыми именами поля?

a[0].id... a[1].id обычный tuple из структур на выходе, короче

откуда взялась переменная b?

очепятка. там должно было бы быть a->second->id

Даже без оптимизатора

нет, без оптимизатора будет треш - если не верите - попробуйте накатать наивную реализацию РСУБД самостоятельно и посмотреть на результат

join тоже вернёт. в этом и прикол

Нет. Даже без оптимизатора «SELECT count(*) FROM t1 JOIN t2 ON t1.id=t2.id» не «SELECT count(*) FROM t1 JOIN t2 WHERE t1.id=t2.id».

нет, без оптимизатора будет треш - если не верите - попробуйте накатать наивную реализацию РСУБД самостоятельно и посмотреть на результат

Рефери врывается в чят. У современных SQL (да и не только современных) движков джоин выполняется как подзапрос. То есть, примерно

SELECT count(t1.*), (SELECT fieldname FROM t2 WHERE t2.id = t1.id) as fieldname
FROM t1

И да, подзапрос можно сделать с условием a->first->id == b->second->id && b->second->id - именно так работает NoSQL джоин в BDE.

но ведь sql в пределе - сам просто find по массивам, слегка поперчёный алгебраическими типами данных (результат этих ваших джоинов) и всё

Только find с индексами. И с оптимизацией по отбору.

a->first->id == b->second->id && b->second->id;

Это будет t1.id=t2.id and t2.id <> 0

Если в t1 две строки, а в t2 ни одной, то в t1 LEFT JOIN t2 должно быть две строки.

Вот поэтому SQL и лучше, что каждому программисту не приходится велосипедить запросы.

попробуйте накатать наивную реализацию РСУБД самостоятельно и посмотреть на результат

В наивной реализации SELECT ... FROM a JOIN b ON cond разворачивается в

for i1 in a 
  for i2 in b
    if cond then collect ...

for i1 in a 
  for i2 in b
    t += (i1,i2) 
for i in t
  if cond then collect ...

иначе объединение из десятка таблиц по сотне строк в SQL было бы невозможно

Хорошо. Тогда зачем вы здесь применили другой алгоритм? Зачем придумывают всё новые языки-велосипеды? (комментарий)

Только find с индексами. И с оптимизацией по отбору.

Нет и нет. Эффективность индексов и оптимизации гарантирует РСУБД, а не SQL. При наивной реализации SQL, никаких оптимизаций, в общем-то, не будет.

Это будет t1.id=t2.id and t2.id <> 0

ну. я так и написал

Тогда зачем вы здесь применили другой алгоритм?

Там не другой, там этот же. Нигде не собираются все комбинации всех строк двух таблиц. Внешний цикл через SCAN FOR по одной таблице и LOCATE (если известно, что id во второй уникален) по второй таблице. Можно было вместо LOCATE сделать тоже SCAN FOR.

ну. я так и написал

Вот именно. «t1 JOIN t2 ON t1.id=t2.id and t2.id <> 0» и «t1 LEFT JOIN t2 ON t1.id=t2.id» абсолютно разные условия. Например, если таблица t2 пустая, то твоё условие даст пустую таблицу, а LEFT JOIN даст таблицу, где строк столько же, сколько в t1.

ну можно t1.id <> 0 тогда написать - между LEFT и RIGHT JOIN принципиальной теоретической разниц нет

понятно

ну можно t1.id <> 0 тогда написать

До тебя так и не доходит. LEFT JOIN в принципе через декартово произведение с условием не представляется. Если t2 пусто, то (t1|t2) уже будет пусто. А t1 LEFT JOIN t2 непусто.

LEFT JOIN в принципе через декартово произведение с условием не представляется.

и что? это вы зачем-то про декартово произведение вспомнили, теперь носитесь с ним как с писаной торбой

это вы зачем-то про декартово произведение вспомнили

Если (t1|t2) у тебя не декартово произведение, то что это? Это же твоя конструкция:

(t1|t2).find([](decltype((t1|t2)::row)& a){return a->first->id == b->first->id;})

И на вопрос «как в такой конструкции сделать LEFT JOIN» ответ:

a->first->id == b->second->id && b->second->id;

Если (t1|t2) у тебя не декартово произведение, то что это?

плюсы тоже умеют в алгебраические типы (на шаблонах), и да результирующему объекту как и в скл не обязательно копировать в себя данные - результату (t1 | t2) достаточно содержать ссылку на обе таблицы - а там уже как хотите реализовать - желаете - будет построчная склейка как в sql, хотите - декартово произведение

вплоть до того, что на шаблонах и макросах можно сделать SELECT * FROM a JOIN b ON cond валидной конструкцией, и делать выборку, допустим, из массивов структур

только никому такой синтаксис не интересен. интересно, почему?

результату (t1 | t2) достаточно содержать ссылку на обе таблицы - а там уже как хотите реализовать - желаете - будет построчная склейка как в sql, хотите - декартово произведение

Вот я и спросил, как предлагаешь в C++ записать LEFT JOIN.

вплоть до того, что на шаблонах и макросах можно сделать SELECT * FROM a JOIN b ON cond валидной конструкцией, и делать выборку, допустим, из массивов структур

Да ну? Рабочий пример шаблона/макроса «SELECT * FROM a JOIN b ON cond» приведёшь?

только никому такой синтаксис не интересен. интересно, почему?

В C# сделали LINQ. В С++ нормально сделать невозможно, а запрос обильно пересыпанный «[](decltype((t1|t2)::row)& a)» читать неудобно.