Обсуждение

«а программисты вообще не замечали бы проблемы — "все ж с данными так делают!".» — программисты, которые что-то делают с данными — это уже вещь специфическая.

ну объектные БД можно. Например IBM Domino. Есть база, в ней объекты, в объектах поля и всё, больше ничего. К этому довольно пристойный API. Ваяй шо хочешь.

https://en.wikipedia.org/wiki/Document-oriented_database — это документарки. Обьект и документ — это все таки разные вещи. Хоть мне и ближе концепция документов в отношении к бд.

У меня сложилось мнение, что подход "от инструмента" чаще ведёт к тупикам. Да, теория категорий штука красивая, но это DSL, созданный для определённых абстрактных построений. Можно использовать её в описании факта "сегодня будет дождь", но ровно в той же степени, что написать текстовый редактор на машине Тьюринга. Да, микроскоп тоже хорошая вещь, и если искать ему новые применения, то обнаружится возможность забивать им гвозди, и это физически осуществимо, но нерационально. А онтологи всё пытаются найти хоть какое-то применение своим бесполезным верованиям про эндурантизм и пердурантизм, но получается вообще никак. Является ли этот наблюдаемый во многих областях человеческой деятельности перекос в сторону подхода "от инструмента" когнитивным искажением? Всё может быть. Есть солверы на FOL и системы управления базами данных на SQL (изначально - огрызке FOL), которые частично решают проблемы хранения и обработки знаний о мире. Если погрузиться в те кейсы, которые не решены, то можно создать и более удобные и универсальные инструменты. Но сомневаюсь, чтобы эти инструменты оказались гибридами молотка, микроскопа и теории категорий.

Ну вот "инструмент" это ж предмет, который может выполнять какую-то роль -- и дальше можно понимать, хорошо ли он выполняет эту роль, или нет. Цивилизация прирастает инструментами. Я в ad hoc для всего-всего не верию, не работает это. Фишка в том, что нет ни одного инструмента -- есть кулибинство. Все гвозди забиваем даже не твёрдым микроскопом, а всем чем под руку попадает: руками, чужими головами, мягкими камнями, подушками и т.д.

Добавлю два цента в поддержку)) (в чатах не хочу) 1) в F# например есть абстракция "функции как типы данных", что сразу сделало её систему типов потенциально (математически) мощнее чем в Java/C#/... А если добавить к F# что-то типа MLTT, то получится его залифтить до Agda. Это каждый раз качественно новый уровень абстракций (дающий потенциальный выигрыш в компактности/выразительности наверное даже на порядки), но как оптимально использовать хотя бы систему типов Java (Тьюринг-полную саму по себе), да, никто не знает, действуют в основном интуиционистски :) Есть type driven development, но там всё с ориентацией в основном на программистские цели (всё те же выразительность/минималистичность в отношении кода), не на постановочные (моделирование с помощью мощных типов). 2) однозначно "бестиповые языки не выживают", системы типов в современных языках быстро усложняются (в хорошем смысле), поэтому любые попытки использования в программах на таких языках безтиповых, безсхемных форматов данных наподобие JSON, не допускающих статический тайпчекинг, следует считать крайне вредными :) Даже XML куда лучше чем JSON.

/// Почему мир не моделируют в этих типах, а моделируют только обработки внутри БД?! /// ИМХО если бы все креативили в Wolfram'е, то типизировали бы всё подряд, поскольку там оно достигается в известной мере бесплатно. Кстати, помимо типа/класса, есть и другие аффиксы модельных объектов— scope, reliability, affinity, integrity, могу ещё добавлять.

ну документ это пассивный объект. В Лотусе по крайней мере разницы нет.

Довольно интересно. Правда, много непонятного.

Реляционное в базе и разложенное по объектам в памяти — естественное и вынужденное следствие возможности произвольного доступа к оперативке и более естественного изрядно последовательного доступа к дорожке диска. И, ИМХО, практически ничего сверх этой разницы.

Вы какие DB ODS/StorEngines знаете более или менее досконально?

А Вы?.. Я правильно понимаю, что Вы о storage engine для БД типа MySql и всяких построенных поверх баз ORM (Object-Relational Mapping)? А то Ваши названия у меня не гуглятся даже... Знаком с пачкой СУБД, начиная с Oracle и PostgreSQL, до SQLite, естественно с оглядкой на прочие, и с несколькими менее популярными, и с пачкой промышленных самописных ORM, видел Hibernate в Java, BOLD в Delphi и ещё что-то Вы задаёте такой вопрос чтоб решить верить ли мне, или таки имеете возражения?

/// А то Ваши названия у меня не гуглятся даже... /// ODS? Это On-Disc Structures.

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

А in-memory DB, типа той же HANA? Конфиги по 40+ терабайт на практике.

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

А что бы предложить?