Что такое impl файлы и mnet-platform внутри jar архивов?

С вероятностью много - это дамп базы Versant FastObjects

Ребята (включая Оракл) еще в незапамятные времена собрались и придумали стандарт для хранения объектных данных, переносимый между языками программирования - например, чтобы сохранить в файл джавовые объекты и без потерь загрузить их в объекты C++

PDF-ку с мануалом можно скачать внизу вот этой страницы

https://communities.actian.com/s/article/Versant-FastObjects-12-0-ODMG-Java-Programmmers-Guide

Краткое описание ODMG есть здесь:

https://en.wikipedia.org/wiki/Object_Data_Management_Group

Да похоже, ты прав fastobjects_t7_odmg-10.09.200.jar

Придется протокол USB дампить :(

Желал полюбопытствовать, а у меня не скачивается… Это так и задумано или я делаю что-то не так?

Должно качаться, я проверил сейчас.

Спасибо. Где-то у меня ( «что-то не так».

Вот она https://metrohm-tiamo.software.informer.com/2.4/

какая прелесть. Это из тех древних нелепых и милых времен, когда казалось, что табличные БД слишком скучные и надо научиться хранить объекты, потому что всё вокруг ООП?

Я думаю что эта идея недооценена и ещё взлетит.

тяжело загадывать в будущее, но на сегодня можно констатировать простой факт: идея ООП в том виде и с тем энтузиазмом, с каким её обсасывали в 90-е и ранние 2000-е умерла полностью и её хладный трупик даже уже не попинывают.

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

При этом это совершенно не отменяет того факта, что через какое-то время её иная реинкарнация нас может посетить. Ведь нейросетки вышли из забытия, когда для них появилось подходящее железо, а их тоже раза два хоронили.

Бог с ним, с ООП. Хранить реализацию методов в базе может быть и не нужно.

Суть в том, что сейчас в программах используется JSON-оподобные структуры данных. Простите за неимением лучшего термина, думаю, понятно, что я имею в виду. А в РСУБД - реляции. Которые, конечно, как-то можно натянуть, но вот именно - «как-то».

Мне от СУБД хотелось бы:

1. Каждая сущность это ключ-значение для значений из примитивных типов (строка, число и тд). Ну тут примерно как сейчас, разницы нет.

2. Также иметь возможность хранить отношения в виде массива или списка. Сейчас этого в РСУБД нет, есть имитация в виде foreign key, но она неудобная.

3. Также иметь возможность хранить отношения в виде хеша ключ-значение, где ключ это строка, а значение это уже либо сущность либо массив/список, либо другой хеш.

Ну т.е. по сути СУБД это такой большой JSON, концептуально. Только типизированный, схема это правильно.

И поверх этого язык запросов, но не SQL, а что-то вроде jq. И, конечно, все преимущества СУБД в виде индексов, транзакций. Ещё в современном мире, конечно, очень важна возможность работать в распределённом режиме.

Может и есть такое, да я не знаю…

да, ты совершенно понятные вещи говоришь и все, конечно, укладывают более сложные объекты чем эксельки.

Посмотри: в постгресе одна из последних популярных штук — это jsonb хранилище. Всё для schemaless

Но по сути оно было отброшено на десятилетия назад примерно около 15 лет назад, когда массово стало очень много серверов. Т.е. пока речь шла максимум о репликации слабенького трафика на соседний сервер, были одни архитектуры. Когда повсеместно стали дешевыми и доступными кросс-датацентровые инсталяции, то всё откатилось к более простым решениям.

и надо научиться хранить объекты, потому что всё вокруг ООП?

для людей с терминальным поражением ООП головного мозга, весь мир - до сих пор ООП ))) Это не меняется!

кроме джавы есть еще и другие языки, к счастью

Самое страшное, что они хотели хранить не только данные, но и поведение. Но я не знаком со стандартом настолько, чтобы сказать, насколько это у них получилось.

Object Query Language (OQL). The ODMG OQL was a declarative (nonprocedural) language for query and updating. It used SQL as a basis, where possible, though OQL supports more powerful object-oriented capabilities.

Куча РСУБД поддерживают хранимые процедуры. Что тут такого ужасного.

Так это же не РСУБД. Когда у тебя РСУБД стоит во главе угла при дизайне новой информационной системы, то ты отдельно разрабатываешь структуру БД, и потом отдельно думаешь - как ты будешь из приложения запрашивать данные.

Есть возможность использовать ORM, но обычно получается так себе. Есть чуть ли не лучший, самый навороченный в мире ORM под названием Hibernate из Java (и его порт на .NET). Даже когда пользуешься им, тебе нужно вертеться как уж на сковородке, чтобы закрыть object-relational mismatch. По факту, никто в enterprise java не пишет так, чтобы можно было попросить полученную из БД коллекцию объектов напрямую из веб-интерфейса - там между ними десять прослоек, каждую из которых нужно писать по особому феншую, чтобы случайно чего не сломать

Здесь же у тебя прямо противоположный подход к дизайну: во главе угла стоят ООП языки. Конкретно, C++, Java и Smalltalk. И нужно придумать такую структуру данных и «хранимки», которые бы идеально отражали объектную модель минимум 3 языков, и всё это должно быть описано на уровне стандарта, написанного человеческими словами (не кодом), и работать без сервера, дампясь в файлы клиентскими библиотеками.

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

Я уже написал, чего мне не хватает в РСУБД для счастья. Просто JSON. Причём не хранения JSON, а именно тех структур данных для построения отношения между сущностями. Упорядоченный список чего-нибудь, неупорядоченная хеш-карта строка->что-нибудь ну и сущность как неупорядоченная хеш-карта по сути тоже. И всё это типизировано, с возможностью навешивать индексы (а в идеале чтобы оно само их навешивало куда надо, ну 2022 год же). И язык запросов, наподобие jq.

По сути это можно тупо поверх постгреса сделать. Но хочется, конечно, возможностей побольше, чем у постгреса. Хотя может оно и не надо, мне и такого хватит.

С таким интерфейсом уже особого mismatch не будет. Да, всё ещё нужно будет описывать отдельные entity классы, но с ними работать будет удобно. И сложность ORM будет не нужна.

Так расписал, что самому захотелось сделать.

для людей с терминальным поражением ООП головного мозга

и отметь, насколько это перекликается с тем, что я писал сегодня во вконтактике про первичность гуманитарной идеи над техническими конструкциями.

Какая-то зараза притащила программистам идею ООП и её теперь как герпес: не вывести.