Да, ваши последние записи я в LJ видел.  Кстати,  о птичках,  т.е близкой мне системе SAP.

Действительно,  гонять данные между БД и структурами данных в языке програмиирования - это боль,  но эта боль в других системах по опыту еще больше.

Дело в том,  что в SAP нельзя просто так напрямую создать табличку с полями.  Нужно пойти в словарь данных, для полей таблички сослаться на элементы данных,  в элементах данных описать из назначение и сослаться на домены,  в доменах опять описать назначение и сослаться на один из базовых типов.  Если сослался на элемент данных с количественным типом в домене - будь добр укажи поле с единицей измерения,  аналогично для стоимостных полей нужно указать валюту.  И все это трассируется по where used,  т.е можно посмотреть в каких табличках фигурирует вот этот элемент данных "номер заказа на продажу".  

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

Вот и интересно,  появилось ли за прошедшие десятилетия что-то получше именно прикладном плане,  а не в виде перспективных исследований?

Да, ваши последние записи я в LJ видел.  Кстати,  о птичках,  т.е близкой мне системе SAP.

Действительно,  гонять данные между БД и структурами данных в языке програмиирования - это боль,  но эта боль в других системах по опыту еще больше.

Дело в том,  что в SAP нельзя просто так напрямую создать табличку с полями.  Нужно пойти в словарь данных, для полей таблички сослаться на элементы данных,  в элементах данных описать из назначение и сослаться на домены,  в доменах опять описать назначение и сослаться на один из базовых типов.  Если сослался на элемент данных с количественным типом в домене - будь добр укажи поле с единицей измерения,  аналогично для стоимостных полей нужно указать валюту.  И все это трассируется по where used,  т.е можно посмотреть в каких табличках фигурирует вот этот элемент данных "номер заказа на продажу".  

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

Вот и интересно,  появилось ли за прошедшие десятилетия что-то получше именно прикладном плане,  а не в виде перспективных исследований?

С одной стороны понятно, что дикая процедура с походом в словари и принудительной трассировкой ("сослаться" это как раз оно) долгая, с другой стороны она и есть нынешний онтологический state of the art, ибо позволяет создавать сложнейшие системы, которые не слишком быстро разваливаются.

Примерно так сегодня устроены большинство PLM и ERP и EAM систем — те системы, которые первично имеют дело с описаниями материального мира, а не только с "данными", неважно что описывающими (это программисты любят работать с "данными", а для всех остальных это описания чего-то вовне программы, и это крайне важно — онтология вот тут появляется).

С одной стороны понятно, что дикая процедура с походом в словари и принудительной трассировкой ("сослаться" это как раз оно) долгая, с другой стороны она и есть нынешний онтологический state of the art, ибо позволяет создавать сложнейшие системы, которые не слишком быстро разваливаются.

Примерно так сегодня устроены большинство PLM и ERP и EAM систем — те системы, которые первично имеют дело с описаниями материального мира, а не только с "данными", неважно что описывающими (это программисты любят работать с "данными", а для всех остальных это описания чего-то вовне программы, и это крайне важно — онтология вот тут появляется).

Производственная практика показывает, что программист приземляет на систему типов своего языка программирования не концептуальную модель БД, а физическую.  Вчера был вопрос "насколько часто типы вообще используются для описания домена" - вот оно здесь. Какие физические таблицы и поля завели в БД, такие типы в программе обычно и заводятся (ORM для незнающих SQL). То есть, тип данных pump в программе обычно появляется только если в БД есть таблица с насосами, и программисту неважно какие насосы - складские, установленные на станции, разбираемые, или другие, так как он делает типы "для вычислений".

Вот да, я в эту точку и бью: что там у программистов с приземлением не физической модели данных, а сразу концептуальной модели! А мне хором отвечают, что их физическая модель интересует, и всё богатство современной системы типов для неё!

А меня не конверсия из одной foundational ontology в другую такую же интересует, а выход на upper ontology. Увы, программисты этого даже не понимают (((

Как всегда - есть, но не всегда то, что хочется.
Видели обзор https://medium.com/@mikhailparfentev/%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7-%D0%BB%D1%83%D1%87%D1%88%D0%B8%D1%85-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%D0%BD%D0%B0%D1%80%D0%BE%D0%B4%D0%BD%D1%8B%D1%85-%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%BA-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D1%8F-%D0%B8-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BC%D0%B0%D1%81%D1%82%D0%B5%D1%80-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%BC%D0%B8-8b57fd39696f

Да, а на более низком уровне, например, https://docs.microsoft.com/en-us/sql/master-data-services/master-data-services-overview-mds?view=sql-server-2017

@ailevenchuk Хуже, богатство современной системы типов не для физической модели данных даже, а для вычислений.

Добавлю ещё одну ссылку от 2013 года https://ailev.livejournal.com/1067013.html

Вот это место и болит. Нужно, чтобы его не было. Есть же красивые системы типов, а люди с табличками возятся. Грубо говоря, волшебной палочкой делают деревянные палочки, а потом работают деревянными палочками. А можно сразу волшебной палочкой — чтобы деревянные по пути не создавать?! Программируют-то не на SQL, хоть он тьюринг-полный! Программируют на нормальных языках. А систему типов и хранение данных этих типов делают в табличках, а не в нормальных структурах данных.

Нужно понять, в чём проблема (она ж не в legacy, хотя и в этом тоже — СУБД многие создавались, когда круче Паскаля/Дельфи ничего не было) и исправить ситуацию!

@ailevenchuk Я имею в виду не математические вычисления, а исполнение программ. Каким боком типы, предназначенные для того, чтобы не давать совершать недопустимые действия в алгоритмах, прикрутить для того, чтобы описывать недопустимые дейстия над данными?

Надо объявить таблицы в БД "ассемблером, на котором никто не программирует", и выполнять из богатого на типы языка программирования в автоматическом режиме не только DML-операции, но и DDL тоже. А концептуальную и логическую схемы БД списать в утиль.

@ailevenchuk Я имею в виду не математические вычисления, а исполнение программ. Каким боком типы, предназначенные для того, чтобы не давать совершать недопустимые действия в алгоритмах, прикрутить для того, чтобы описывать недопустимые дейстия над данными?