А нужно ли это встраивать в зав-типы? семантика классов ООП существует давно в "параллельной" реальности. Можно отобразить классы на тайп-классы, например.

кстати, еще в древние Смоллтоко-ЛИСПовские времена, когда ООП относилось к экспериментальной теме, которую обкатывали академические сотрудники, были придуманы метаклассы с метаобъектами, как высшее проявление ООП-шности. но там всё рантаймовое, как в нынешней Джулии. а встречал ли кто-нибудь настоящий денотационный вариант семантики метаклассов? http://ldbeth.sdf.org/The_Art_of_the_Metaobject_Protocol.pdf

Понятно, что не полный вариант семантики, но идея эта?

Понятно, что не полный вариант семантики, но идея эта?

Не оно? http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0707r0.pdf

Книжка BORO в своей первой части как раз посвящена подробному и нудному разбору этих ситуаций. Так что за примерами — сразу туда.

Да те же самые ножницы. Сначала про in-the-small. Например, сломалась ручка ножниц. Берём отпиливаем (одну) ручку от других ножниц, и привариваем к этим. Даже если в БД заведены таблицы как для самих ножниц, так и для их половинок и винтиков, и даже для функциональных блоков "ручки" и "ножи", то такие нестандартные ситуации непонятно как учитывать. А когда in-the-large, то всё ещё хуже, когда ножницы есть в БД проектного института, БД завода-изготовителя, БД транспортной компании, БД склада, БД швейной фабрики, БД ремонтной матерской, БД бухгалтера на подряде, и т.д. И первичные ключи вроде одних и тех же ножниц не соотносятся между собой один-к-одному. Интеграционные сценарии спасают положение, но не универсально, а только для ножниц именно в этом "бизнес-процессе".

Konstantin , in-the-small проблема заключается в необходимости пересматривать всю схему БД при каких-либо изменениях предметной области, ибо столбец в таблицу добавить гораздо сложнее, чем строку (в богатых системах типов ожидается, что изменения будут локальны). In-the-large проблема в федерировании независимых БД.

Konstantin , in-the-small проблема заключается в необходимости пересматривать всю схему БД при каких-либо изменениях предметной области, ибо столбец в таблицу добавить гораздо сложнее, чем строку (в богатых системах типов ожидается, что изменения будут локальны). In-the-large проблема в федерировании независимых БД.

Реляционные БД хорошо подходят для хранения и обработки данных с одной точки зрения на предмет, но плохо подходят для одновременного учёта множества точек зрения независимых деятелей на один и тот же предмет (см. выше формулировку @pavetok).

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

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

Базу можно спроектировать с любым количеством точек зрения на предмет, если они известны заранее. Вот чего делать не нужно, это проектировать базу в попытке учесть заранее неизвестные "точки зрения" ака requirements. В результате всегда получается overengineered crap.

Вопрос к тому, как такое выражать на языке программирования. В том числе в ситуации, когда ручки и ножевой блок используются в программе управления требованиями в конструкторском бюро, а две половинки ножниц и винтик даны в САПР в том же бюро, и нужно как-то состыковать их: чтобы требования относились к тому, что проектируется в САПР.