guest_20040621
Процентов десять реальных объектов такой структурой можно описать. И?
Описать-то можно процентов 100.

А потому что это неправильное решение некорректной задачи. Не имеет оно ничего общего с реальным положением вещей. Чего для его тиражировать?
Это решение эффективно по некоторым критериям. Не более. Собсно, в этом и был мессадж для adisk.

guest_20040621Поправочка: адекватно описать. Независимых сущностей - для которых эта схема будет приемлема - и будет десять процентов. Очень оптимистично. А для остальных девяноста процентов - ну совсем не покатит такая схема. Т. е. абсолютно.
Эта схема адекватно описывает 100% сущностей, их атрибуты, классификацию и связи между ними. Проблема в приемлемой реализации использования этих описаний. Возможно, для 10% она существует, хотя, согласен, это оптимистичная оценка.

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

guest_20040621Пальцем ткните, чего темнить: как именно с помощью четырех (я правильно посчитал?) перечисленных таблиц описаны связи и классифицированы сущности. Очень интересно, чесслово. Особенно в контексте предметных областей.
Так вы обсуждаете мое давнее тезисное сообщение с целью непосредственного использования ? Разочарую вас - оно имело собой другую цель.
Возьмите картинку со схемой на предыдущей странице, в которой эта же схема уже детализована для использования.
Тыкаю в эту картинку: берете ваши сущности и заносите в таблицы "Классы", "Атрибуты" и "Типы связей".


А "Название_в_предметной_области" тогда зачем? Чтобы врагов запутать?
Чтобы моделировать предметную область или несколько смежных в контексте.

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

guest_20040621Понятно. Это уже было. В треде про сервер объектного представления. Из реляционной СУБД сделали... полное непотребство. Для какой цели, позвольте поинтересоваться? Что, это сильно удобно? Или сильно производительно? Или, может, переносимость идеальная?
Ссылка приведена, читайте обсуждение. Вкратце: это она их схем маппинга объектов. Расширяемая без изменения структуры БД. Унификация связей. Метаданные.

А что, у Вас _сущности_ от контекста зависят? Сильно.
Похоже у вас "название сущности в предметной области" и "сущность" каким-то образом тождественны. Вот это, действительно, сильно :)

Правильно, не нужны. Но сами-то атрибуты не начали зависеть от предметной области, правда?
См. выше про "множество атрибутов".

guest_20040621Повторяю вопрос: Вы-то свою схему реализовали для какой цели? Это сильно удобно? Или сильно производительно? Или, может, переносимость идеальная? В чем фишка-то, поделитесь?
Мы делали подобное в 1996 как расширение для бизнес-админа.
В системе обычный маппинг на таблицы, реализуемый прикладным программстом. Для добавления новых классов/атрибутов использовалась вертикальная схема. Админ, без программирования, за 5 минут добавлял классу новый атрибут, который тут же появлялся во всех динамических формах, металанных и построителях запросов/отчетов. Да, это для него "сильно удобно". Это "сильно удобно" для прототипирования. В этом и "фишка".

Хм... как имя может быть тождественно сущности? Для Вашего примера "название сущности в предметной области" - бессмысленное буквосочетание.
О тождественности говорили вы, лихо перейдя с "названия в предметной области" на "зависимость сущности от предметной области". Вам и разбираться в своих логических построениях.


> См. выше про "множество атрибутов".
Спасибо, я это уже читал. Вопрос в силе.
Ответ тоже в силе. См.выше. Или см. в словаре про "тезаурус" и "синонимичные ключевые слова".

guest_20040621В обмен на imho весьма сомнительную гибкость Вы намертво привязали приложение к СУБД, получили абсолютно неудобную архитектуру и максимально геморройный для сопровождения код. Великолепный результат.
Позвольте сначала поинтересоваться, где вам удалось увидеть в такой схеме привязку к СУБД ?

guest_20040621Нигде. Я сопоставил Ваше описание, тред "реализация сервера объектного представления", время выхода статьи и время обсуждения.
Раз нет привязки, то нет и вопросов.
Если хотите обсудить статью или архитектуру NEXUS - ссылки были даны.

guest_20040621Хех, ну это Вам кажется, что вопросов нет. ОК, забыли о реализации. Остановились на схеме.
Это хорошо что вы забыли о реализации.

Так какой, говорите, тезаурус используется в схеме? Как описаны предметные области? Как реализована локализация? Как локализация связана с тезаурусом? Как реализовано разделение доступа?
Напоминаю, мы о ней забыли.
Для вышеназванного в ядро добавится десяток таблиц.

adiskДля наглядности прилагаю схемку. (по описанию templar)
Очень хочу разобраться.
Не нужно тезисно приведенную схемку использовать как рабочую даже в первом приближении. Если хотите использовать, то нужно проектировать ее под ваши системные требования.
Смысл дискуссии по ссылке состоит совсем в другом: универсальность схемы оборачивается проблемами с выборкой данных даже по простым условиям как по скорости, так и по сложности запросов.
Получается неряляционная (вертикальная) модель хранения, реализованная реляционными средствами.

MasterZivА, Сергей, ты здесь ? Брось ты этот топик, что тебе-то здесь ловить ?
Пусть молодые вон упражняются в словоблудии.
Я как увидал эту бодягу на 10*N страниц - сразу все понял.
Да я вспомнил нашу давнюю дискуссию в фидо , кстати, и с твоим участием :) и запостил ссылку, в надежде, что людям полегчает :)

guest_20040621Про реализацию. А про схему никто не забывал. Перечисленные задачи по крайней мере частично в схему вписываются очень даже.
и

У Вас же уже есть четыре таблицы, зачем еще? Н-да... и здесь не получилось дискуссии.
Если забыть про реализацию, то можно впихнуть и в 4.
Ну, потратить еще десяток страниц на тему "что первично", решая, как же внести класс "класс" если класса "класс" еще не существует (не описан). Потом на оптимальность. У всех будут свои критерии оптимальности. Что вам стоит. Думаю, и без меня управитесь.

guest_20040621Кроме того, абсолютно неясны критерии (я уже задавал Вам этот вопрос) выбора собственно элементов метаописания. Почему они выбраны такими и в таком количестве? Какие объекты Вы получили в результате? С какими свойствами? Какие операции и для какой цели вы реализовали для Вашей схемы?
Опять про реализацию ?
Придется повторить еще раз и последний: схема была написана мной "на коленке" и приведена в сообщении в фидо несколько лет назад для дискуссии на тему "как хреново с такой схемой жить, если нужно делать сложные выборки" и "почему за 30 лет никто из производителей СУБД не удосужился реализовать такой подход".
Если хотите обсуждать реализацию и проектирование такой схемы - вопросы к Тенцеру.
Мы не делали полной реализации, мы добавили похожую усеченную схему для создания расширений непрограммистом. Это совершенно конкретная и ограниченная задача. Все.
Почему выбрано такие метаописания, а не другие - потому что у нас были такие требования к системе, а не другие. Не нужна нам была ни многоязычность, ни "многоименность" сущностей в разных предметных областях. Система безопасности тут вообще боком стояла. Кому нужно, думаю, сами догадаются, как все это поддержать в рамках схемы.