Сахават Юсифов
По хорошему в метаописании СКЛ сервера не хватает не так много - разделение на ссылочную целостность и релейшн, сложные констрейнты между таблицами (assert) и мелочи типа как показать (вся эта хрень была у интербейзе).
расшифруй

Сахават ЮсифовPetro123Сахават Юсифов
По хорошему в метаописании СКЛ сервера не хватает не так много - разделение на ссылочную целостность и релейшн, сложные констрейнты между таблицами (assert) и мелочи типа как показать (вся эта хрень была у интербейзе).
расшифруй
чего?
чего не хватает в метаданных СУБД (в служебных схемах в оракле или системной БД сиквела)

_модPetro123чего не хватает в метаданных СУБД (в служебных схемах в оракле или системной БД сиквела)
метаданные СУБД описывают стр-ру РБД, метаданные прикладной системы - объекты системы. разные вещи просто
у кого как.
У меня метаданные СУБД описывают логическую структуру объектов Системы .
Например: мастер - детайль, FK, ограничения поля данных, и т.д.

В случае EAV там для этого нет места, поэтому и нужно городить метаструктуру, то бишь классификатор.
ЗЫ. Конечно это холивар и бесконечный спор.
Удачи!

_модPetro123У меня метаданные СУБД описывают логическую структуру объектов Системы .
Ошибка - РБД - это модель данных (табличная !) реальных объектов произвольной и более сложной стр-ры.

=== да! Плоская УПРОЩЁННАЯ модель реального мира (как любая другая модель)

МД строится для того чтобы можно было манипулировать св-ми объектов стандартным образом, т.е. посредством рел. алгебры.

== я не против. На то она и УПРОЩАЕТ свойства и взаимосвязи

Прямое описание объектов посредством метаописания - это отказ от РМД и соотв. алгебры. - применяется в определенных целях.

====== вот это я не понял.



модель БД для работы рел.алгебры я не трогаю.
Дело в том, что помимо метамодели так сказать, для поддержки работы РБД, там же (в табличном виде) описывается бизнес-логика и модель предметной области.
Например, отношение многие ко многим в сущностях Товары - Заказчики описаны в табличном виде в системных таблицах (поле owner, поле ссылочное, вид связи, ....).
IMHO

Petro123
Например, отношение многие ко многим в сущностях Товары - Заказчики описаны в табличном виде в системных таблицах (поле owner, поле ссылочное, вид связи, ....).

поправлюсь. Если вы проектировали БД на декларативной ссылочной целостности (напр. через директиву cascade)

_модPetro123Например, отношение многие ко многим в сущностях Товары - Заказчики описаны в табличном виде в системных таблицах (поле owner, поле ссылочное, вид связи, ....).
IMHO
тогда д.б. описана привязка сущностей к таблицам БД:
Заказчики = tabl1+tabl2 и т.д
тогда операции с сущностями можно транслировать в sql

зачем это надо? Чтобы соединить ООП клиента с РСУБД?
Это никому не надо.
Привязка сущностей к таблицам происходит на другом уровне.

Вар.1 - БЛ в виде пакетов и процедур в них на сервере.

Тогда пакет оракал = класс = сущность. И все методы с клиента и с класа клиента оперируют с метамоделью в виде пакетов-классов.

Вар.2 - БЛ в виде библиотек на клиенте.
Уже давно реализовано в клиентских библитеках и программист на клиенте оперирует не сущностями, а физической структурой БД через SQL строя объекты этим ЯП (Join)

_модPetro123Тогда пакет оракал = класс = сущность.
Ну это-то понятно :) Новый класс - пиши новый пакет (и еще кучу кода). Но мы как раз обсуждаем способы этого избежать.
а это возможно?
Пакет это не только имя, но и методы CRUD.
---
Проблема в том, что класс=данные+методы_для_работы_с_ними.
Допустим вы создали супер-пупер модель по добавлению сущностей.
А методы? Что с ними делать?
Перебросить метод "ЗакрытьОперДень" на серверПриложения?

_модНо мы как раз обсуждаем способы этого избежать.
избежать очень просто - сериализовывать классы в БЛОБ, и потом рожать их обратно на клиента.
Правда сервер тут ни при чём (как при EAV)