ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
25 сообщений из 438, страница 10 из 18
  10  все
Объектная надстройка над релационной СУБД
    #32863658
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Эта информационная система должна будет как минимум реализовать единое информационное пространство для всех
> подразделений и компаний а в идеале обеспечить в организации все требования и управленческого учета и финансового
> и остальных... :)

Хорошая задача. ;) С учетом и управлением - понятно, а вот с единым информационным пространством - есть варианты и темы для обсуждения.

> Надо чтобы внедрение в систему новой функциональности занимало не 3-6 месяцев а 1-2 недели;

Еще одна хорошая задача.

> Выходом здесь [...] может послужить внесение в БД дополнительного "объектного" слоя [...] в которой можно будет
> описать модель предметной области, в нашем случае - организации и её БП, в виде набора логических объектов, их
> связей, атрибутов и методов.

Хм... у меня похожие посылки и аналогичные выводы. ;)

> Обычно подобные вещи называется "метаданными", "словарем БД" но в нашем случае этот объектный слой или надстройка
> имеет более широкий смысл.

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

> Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если
> использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет
> обсуждения по вопросу, который я выше в теме обозначил номером 6.

Какой набор элементарных логических объектов Вы намерены использовать? В задачу входит регистрация состояний объектов? Если входит, то какие состояния Вы намерены регистрировать?

> Логично было-бы в объектном слое описать для необходимых бизнес-объектов и их пользовательский интерфейс - тоже в
> виде логических объектов. Тогда можно было-бы все возможные клиентские модули системы ограничить единым
> универсальным модулем - генератором user-интерфейса (очень тонкий клиент).

Это относительно несложно. Причем, абсолютно логично в описание интерфейса вписываются права и уровень доступа.

> При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к
> описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и,
> возможно, написанию/генерации некоторых специфических ХП.

Imho два варианта: хорошее, полное описание бизнес-правил в обмен на ужесточение детерминированности (второй вариант - соответственно, наоборот). По моему мнению, код писать придется в обоих случаях. У меня не получилось найти удобного решения.

> Т.к. при внесении изменений в модель системы потребуется корекция или перегенерация всех или части таблиц
> традиционной реляционной структуры, то мы получим серьезные трудности с хранением данных живой, изменяемой
> системы в таких таблицах.

Почему? А версионность?

> Поэтому на мой взгляд, имея объектный слой в БД, эффективнее было-бы и для хранения данных системы пользоваться
> только объектным слоем, а постоянные/временные таблицы или представления использовать только в "крайних" случаях -
> автоматически генерировать для сложных отчетов, пересчетов данных, и т.п.

Понятно. Т. е. получилась такая база данных в базе данных.

> В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору
> таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать
> ни одну таблицу объектного слоя.

А для какой цели ограничивать этот набор таблиц? Imho это требование ниоткуда не вытекает, а ограничений накладывает кучу.

> Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу

Не уверен.

> Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма
> нормализации модели данных :)

Хм... зависит от того, как на это посмотреть. Если положить метаописание эквивалентным системным таблицам, - что, в общем, imho вполне оправданно, - тогда упоминаемая Вами жесткая структура таблиц может быть рассмотрена как обычная стуктура данных. Тогда, как обычно, есть варианты и стоит посмотреть на реализацию этой жесткой структуры таблиц.

> Минусами при этом будут [...] и больший объем БД.

Imho здесь накладные расходы будут действительно большими, но меня это не пугает. Стоимость хранения данных падает на глазах. А вот с производительностью сложнее.
...
Рейтинг: 0 / 0
13.01.2005, 16:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863663
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621>
...такую задачу: путь в базе данных есть некоторая сущность, которая может быть связана с любой из других сущностей этой же базы данных отношением n:m.

Hint1: база данных среднего размера, единицы сотен таблиц,
Hint2: таких сущностей в общем случае большей одной,
Hint3: решение нужно в общем виде, безотносительно СУБД,
Hint4: решение должно предоставлять возможность управления отношениями без написания дополнительного кода.



Направление моей мысли (вариант решения в рамках ОО-подхода, возможны некоторые вариации):

Сущность 1 = объект класса 1

Класс 1
{
тип атрибут1;
тип атрибут2;
тип=(ссылка на Класс2) атрибут3;
...
}

Класс3, ... КлассN - наследуют от Класса2

Сущность 2 = объект класса 2
...

Если нужно назначить какие-то параметры самой ссылке, то атрибут3 можно определить как объект класса "Отношение", включив в него все необходимые атрибуты.

Это объектная модель дальше берем O/R-инструментарий (например, VOA JDO) и получаем решение, позволяющее хранить все это в любой реляционной СУБД, поддерживаемой данным инструментарием. Причем все изменения объектной модели (добавление/изменение классов и атрибутов) таким инструментарием (с некоторыми оговорками) могут отрабатываться автоматически.

Правда не совсем понятно, что означает требование 4.

С уважением, Алексей Ровдо.
...
Рейтинг: 0 / 0
13.01.2005, 16:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863793
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
skorohod"объектность" такой системы плавно вытекла из логичной необходимости иметь не в Visio или Rose, а в БД модель всей организации и ее БП. Сделать это можно и "традиционным реляционным" подходом, забив все необходимые данные в кучу справочников и обеспечив их "динамичность", но поддерживать и развивать такую систему и на уровне БД и на уровне прикладного софта будет очень проблематично даже для небольшой компании.
Выходом здесь на мой взгляд(и не только на мой) может послужить внесение в БД дополнительного "низкоуровневого", "объектного" слоя (или "объектной надстройки" - наверно не важно как это называть) в которой можно будет описать модель предметной области, в нашем случае - организации и её БП, в виде набора логических объектов, их связей, атрибутов и методов.
Обычно подобные вещи называется "метаданными", "словарем БД" но в нашем случае этот объектный слой или надстройка имеет более широкий смысл.
Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если использовать напр. MS SQL-Server).
...
Минусами при этом будут - нетрадиционный подход к проектированию и структуре БД, возможно меньшая производительность (что спорно и сильно зависит от реализации), и больший объем БД.


А я вот для себя сформулировал "закон сохранения сложности", который гласит : "сложность задачи состоит из сложности алгоритмов и сложности структур данных. Уменьшение одной компоненты ведет к увеличению другой".

Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы уменьшаете, но вот алгоритмы...
Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя". Ему не хочется хвататься грязными руками за хрустальную мечту его программистского детства :-). В конце концов, знатоки Фокса не обязаны знать SQL !
Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте, прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем хранилище.
Или вы тоже на Фоксе пишите ?
...
Рейтинг: 0 / 0
13.01.2005, 17:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863807
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adiskРеализвал вариант БД с одной таблицей. (где все данные зранятся в одной таблице)
эксперимент проводил на FoxPro

Работаю над оптимизацией.
Как снова буду на работе вышлю код программы с запросами.


Ждем-с....
...
Рейтинг: 0 / 0
13.01.2005, 17:33
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863813
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> тип=(ссылка на Класс2) атрибут3;

напомню: отношение n:m

> Это объектная модель дальше берем O/R-инструментарий (например, VOA JDO) и получаем решение, позволяющее
> хранить все это в любой реляционной СУБД, поддерживаемой данным инструментарием.

Правильно. С 500 связанными таблицами. Оно хм... просто не нужно. Еще варианты?

> Причем все изменения объектной модели (добавление/изменение классов и атрибутов) таким инструментарием (с
> некоторыми оговорками) могут отрабатываться автоматически.

Для типовых структур - возможно. Но, если Вы заметили, о них речь не идет. Вообще. Так что в данном случае такие генераторы бесполезны. Т. е. абсолютно.

> Правда не совсем понятно, что означает требование 4.

Прочтите сообщение Member skorohod [1242024] (последнеее на 9 странице). Он описал примерно то, что мы с Вами пробуем обсуждать. Вопросов осталась масса, но в общем и целом идея должна быть понятна.
...
Рейтинг: 0 / 0
13.01.2005, 17:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863921
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 guest_20040621
> Хорошая задача. ;) С учетом и управлением - понятно, а вот с единым информационным пространством - есть варианты и темы для обсуждения.

Согласен, есть. Только наверно надо отдельно обсуждать структуру базы и цели автоматизации - а то сами не разберемся что и где написали :)

>> Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если
>> использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет
>> обсуждения по вопросу, который я выше в теме обозначил номером 6.
> Какой набор элементарных логических объектов Вы намерены использовать?
> В задачу входит регистрация состояний объектов? Если входит, то какие
> состояния Вы намерены регистрировать?

Набор логических объектов будет зависеть от задачи. Согласитесь, что для "библиотеки" или "химического справочника" или "КИС" эти наборы будут ОЧЕНЬ разные! Хотя 100% для всех задач должен быть определенный небольшой (наверно) набор, определяющий структуру, функционал объектов самого ядра системы.
Я нигде не упоминал термина "атрибут", имея ввиду, что любой атрибут логического объекта модели является таким-же логическим обектом той-же модели но уже следующего уровня иерархии. И конечно д.б. атрибуты конечные (или первичные - с какого конца смотреть), которые ни на что уже не подразделяются и имеют только значение определенного типа.
Логично в виде объектов модели ввести доступ пользователей, версионность самих объектов, их состояния, ссылки, отношения, типы данных, различные типы объектов, события, сообщения...
Состояния обязательно. Я бы хотел фиксировать:
а) системные состояния объектов модели (шаблонов / классов)- зависит от реализации ядра системы - ну напр. "в разработке" (не введен в строй), "активный" (понятно), "архив" (выведен из текущей эксплуатации), ...
б) бизнес-состояния объектов собственно системы (ну тут может быть что угодно)

> Это относительно несложно. Причем, абсолютно логично в описание
> интерфейса вписываются права и уровень доступа.

На мой взгляд права доступа должны определяться на объектах модели а на юзер-интерфейс они должны отображаться опосредованно.

>> При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к
>> описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и,
>> возможно, написанию/генерации некоторых специфических ХП.
> Imho два варианта: хорошее, полное описание бизнес-правил в обмен на
> ужесточение детерминированности (второй вариант - соответственно,
> наоборот). По моему мнению, код писать придется в обоих случаях. У меня
> не получилось найти удобного решения.

Код конечно будет - (не считая ХП в БД) на языке сервера приложения д.б. модули обработки определенных событий и методов объектов, но храниться они будут тоже в БД.

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

Версионнность в традиционной системе - это по-моему слишком громоздко и накладно будет.

> Понятно. Т. е. получилась такая база данных в базе данных.
:) Ну в SQL-S 2000 тоже в пустой новорожденной базе присутствует куча системных табличек, так что мы не первые!

>> В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору
>> таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать
>> ни одну таблицу объектного слоя.
> А для какой цели ограничивать этот набор таблиц? Imho это требование
> ниоткуда не вытекает, а ограничений накладывает кучу.

Я просто считаю что это вариант проще в реализации и "универсален". Кроме того получаемые при этом преимущества перевесят накладываемые ограничения. А вообще изначально я начал свои измышления на эту тему "из чисто спортивного интереса" с целью придумать именно универсальную структуру, годную для описания любой инфосистемы на уровне данных, без изменения реляционной структуры.

>> Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу
> Не уверен.
Хорошо! "Традиционному" именно сегодня может и противоречит, но согласитесь, что "традиционный" подход 5 или 10 лет назад был несколько другим, чем сегодня! Традиции приходят и уходят...
Разве стандарт SQL ставит ограничения на степень нормализации данных, или на структуру логической модели данных приложения???

>> Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма
>> нормализации модели данных :)
> Хм... зависит от того, как на это посмотреть. Если положить метаописание
> эквивалентным системным таблицам, - что, в общем, imho вполне
> оправданно, - тогда упоминаемая Вами жесткая структура таблиц может
> быть рассмотрена как обычная стуктура данных. Тогда, как обычно, есть
> варианты и стоит посмотреть на реализацию этой жесткой структуры таблиц.

Сегодня варианты не приведу, но их на самом деле можно по пальцам перечесть и потом обсуждать - какой лучше/хуже и почему. В этом топике они вроде были, и в паре смежных топиков - я где-то раньше здесь на них ссылки приводил (в конце декабря).

>> Минусами при этом будут [...] и больший объем БД.
> Imho здесь накладные расходы будут действительно большими, но меня это
> не пугает. Стоимость хранения данных падает на глазах. А вот с
> производительностью сложнее.

На счет производительности тоже можно будет говорить конкретно, только имея что-то, что можно протестировать на серьезном объеме данных. Т.е. сейчас наверно еще рановато. Хотя можно привлечь к обсуждению авторов / владельцев подобных систем. Есть такие в реале.
...
Рейтинг: 0 / 0
13.01.2005, 18:16
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863934
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
guest_20040621> тип=(ссылка на Класс2) атрибут3;

напомню: отношение n:m

> Это объектная модель дальше берем O/R-инструментарий (например, VOA JDO) и получаем решение, позволяющее
> хранить все это в любой реляционной СУБД, поддерживаемой данным инструментарием.

Правильно. С 500 связанными таблицами. Оно хм... просто не нужно. Еще варианты?



Для любого отношения можно построить адекватную струтуру класса (классов).

Но если решение с 500 таблицами вас принципиально не устраивает (в общем-то могу понять) и вы хотите разместить данные в меньшем количестве таблиц, навернув на это некую оболочку, то чем это отличается от попытки создания объектной СУБД, где в качестве хранилища данных выступает некая структура, размещаемая внутри РСУБД? Не проще ли в таком случае просто переориентироваться на использование чистой ООСУБД, в которой можно отследить и достаточно сложные случаи модификации структуры данных и их взаимосвязей? Ведь любое моделирование рассматриваемой ситуации (в т.ч. и в приводимых выше в дискуссии статьях) приводит нас к модели в виде какого-то графа. Но хранение и обрабтка структурированной таким образом информации - прерогатива объектных систем (они для этого в первую очередь и создавались).
...
Рейтинг: 0 / 0
13.01.2005, 18:20
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863956
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
2 vybegallo
Зачем ему такие джойны ?

Ваша задача не на выборку данных, а на отображение их на клиенте.
Ваши юзеры наверно не на прямую в SQL работают, а через интерфейс.

IMHO, Mon$te®
...
Рейтинг: 0 / 0
13.01.2005, 18:30
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863958
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
skorohod2 guest_20040621
> Хорошая задача. ;) С учетом и управлением - понятно, а вот с единым информационным пространством - есть варианты и темы для обсуждения.

Согласен, есть. Только наверно надо отдельно обсуждать структуру базы и цели автоматизации - а то сами не разберемся что и где написали :)

>> Практически это будет небольшой, сторго ограниченный (или автоматически дополняемый) набор таблиц и ХП (если
>> использовать напр. MS SQL-Server). В конкретной реализации такого набора таблиц возможны варианты - это предмет
>> обсуждения по вопросу, который я выше в теме обозначил номером 6.
> Какой набор элементарных логических объектов Вы намерены использовать?
> В задачу входит регистрация состояний объектов? Если входит, то какие
> состояния Вы намерены регистрировать?

Набор логических объектов будет зависеть от задачи. Согласитесь, что для "библиотеки" или "химического справочника" или "КИС" эти наборы будут ОЧЕНЬ разные! Хотя 100% для всех задач должен быть определенный небольшой (наверно) набор, определяющий структуру, функционал объектов самого ядра системы.
Я нигде не упоминал термина "атрибут", имея ввиду, что любой атрибут логического объекта модели является таким-же логическим обектом той-же модели но уже следующего уровня иерархии. И конечно д.б. атрибуты конечные (или первичные - с какого конца смотреть), которые ни на что уже не подразделяются и имеют только значение определенного типа.
Логично в виде объектов модели ввести доступ пользователей, версионность самих объектов, их состояния, ссылки, отношения, типы данных, различные типы объектов, события, сообщения...
Состояния обязательно. Я бы хотел фиксировать:
а) системные состояния объектов модели (шаблонов / классов)- зависит от реализации ядра системы - ну напр. "в разработке" (не введен в строй), "активный" (понятно), "архив" (выведен из текущей эксплуатации), ...
б) бизнес-состояния объектов собственно системы (ну тут может быть что угодно)

> Это относительно несложно. Причем, абсолютно логично в описание
> интерфейса вписываются права и уровень доступа.

На мой взгляд права доступа должны определяться на объектах модели а на юзер-интерфейс они должны отображаться опосредованно.

>> При наличии в системе такого объектного слоя разработка и коррекция её функционала сведется к
>> описанию/редактированию в БД модели - заполнению/редактированию "модельных" таблиц объектного слоя данными и,
>> возможно, написанию/генерации некоторых специфических ХП.
> Imho два варианта: хорошее, полное описание бизнес-правил в обмен на
> ужесточение детерминированности (второй вариант - соответственно,
> наоборот). По моему мнению, код писать придется в обоих случаях. У меня
> не получилось найти удобного решения.

Код конечно будет - (не считая ХП в БД) на языке сервера приложения д.б. модули обработки определенных событий и методов объектов, но храниться они будут тоже в БД.

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

Версионнность в традиционной системе - это по-моему слишком громоздко и накладно будет.

> Понятно. Т. е. получилась такая база данных в базе данных.
:) Ну в SQL-S 2000 тоже в пустой новорожденной базе присутствует куча системных табличек, так что мы не первые!

>> В этом случае данные будут хранится в объектном слое так-же в строго органиченном наборе таблиц, аналогичном набору
>> таблиц для модели системы. Тогда, при внесении изменений в модель системы, не придется изменять/перегенерировать
>> ни одну таблицу объектного слоя.
> А для какой цели ограничивать этот набор таблиц? Imho это требование
> ниоткуда не вытекает, а ограничений накладывает кучу.

Я просто считаю что это вариант проще в реализации и "универсален". Кроме того получаемые при этом преимущества перевесят накладываемые ограничения. А вообще изначально я начал свои измышления на эту тему "из чисто спортивного интереса" с целью придумать именно универсальную структуру, годную для описания любой инфосистемы на уровне данных, без изменения реляционной структуры.

>> Фактически такая объектная надстройка/слой БД не противоречит традиционному реляционному подходу
> Не уверен.
Хорошо! "Традиционному" именно сегодня может и противоречит, но согласитесь, что "традиционный" подход 5 или 10 лет назад был несколько другим, чем сегодня! Традиции приходят и уходят...
Разве стандарт SQL ставит ограничения на степень нормализации данных, или на структуру логической модели данных приложения???

>> Просто в этом случае в ходе проектирования системы мы уходим несколько дальше, чем традиционная 3 форма
>> нормализации модели данных :)
> Хм... зависит от того, как на это посмотреть. Если положить метаописание
> эквивалентным системным таблицам, - что, в общем, imho вполне
> оправданно, - тогда упоминаемая Вами жесткая структура таблиц может
> быть рассмотрена как обычная стуктура данных. Тогда, как обычно, есть
> варианты и стоит посмотреть на реализацию этой жесткой структуры таблиц.

Сегодня варианты не приведу, но их на самом деле можно по пальцам перечесть и потом обсуждать - какой лучше/хуже и почему. В этом топике они вроде были, и в паре смежных топиков - я где-то раньше здесь на них ссылки приводил (в конце декабря).

>> Минусами при этом будут [...] и больший объем БД.
> Imho здесь накладные расходы будут действительно большими, но меня это
> не пугает. Стоимость хранения данных падает на глазах. А вот с
> производительностью сложнее.

На счет производительности тоже можно будет говорить конкретно, только имея что-то, что можно протестировать на серьезном объеме данных. Т.е. сейчас наверно еще рановато. Хотя можно привлечь к обсуждению авторов / владельцев подобных систем. Есть такие в реале.
Есть они. А сложность-это всего лишь миф! Мало таблиц-проще алгоритм,так по крайней мере получилось у меня. Мало ли что может показаться вначале....
...
Рейтинг: 0 / 0
13.01.2005, 18:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32863959
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!
...
Рейтинг: 0 / 0
13.01.2005, 18:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864032
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
4d_monster2 vybegallo
Зачем ему такие джойны ?

Ваша задача не на выборку данных, а на отображение их на клиенте.


IMHO, Mon$te®

Ну так для того, чтобы отобразить, сначала нужно выбрать ?
...
Рейтинг: 0 / 0
13.01.2005, 19:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864034
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
skorohod2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!

Есть такой старый анекдот
Сидит чукча на дереве и пилит под собой ветку. Прохожий ему
- что ты делаешь, ты же упадешь !
чукча продолжает пилить, падает, встает - "Колдун, однако !"

Я понятно намекаю ?
...
Рейтинг: 0 / 0
13.01.2005, 19:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864082
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
2 skorohod

> Только наверно надо отдельно обсуждать структуру базы и цели автоматизации - а то сами не разберемся что и где
> написали :)

Вы правы.

> Набор логических объектов будет зависеть от задачи.

Хм... нет, не соглашусь. _Элементарные_ логические объекты будут одинаковы для любой задачи.

> Логично в виде объектов модели ввести доступ пользователей, версионность самих объектов, их состояния, ссылки,
> отношения, типы данных, различные типы объектов, события, сообщения...

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

> а) системные состояния объектов модели [...] б) бизнес-состояния объектов собственно системы

Возражений нет.

> а на юзер-интерфейс они должны отображаться опосредованно.

Это всего лишь один из уровней проверки (всего их - классический паттерн - три). Возражений нет.

> Код конечно будет - (не считая ХП в БД) на языке сервера приложения д.б. модули обработки определенных событий и
> методов объектов, но храниться они будут тоже в БД.

Понятно. Хозяин - барин, конечно, но мне такая реализация не нравится. Я предпочитаю хранить в базе данных только правила обработки.

> Версионнность в традиционной системе - это по-моему слишком громоздко и накладно будет.

Нет необходимости поддерживать ее в объеме cvs. ;)

> Я просто считаю что это вариант проще в реализации и "универсален".

Это кажущаяся простота. В данном случае схема данных получается настолько навороченной, что бороться нужно не за компактность хранения данных, а за скорость манипуляции данными.

> А вообще изначально я начал свои измышления на эту тему "из чисто спортивного интереса" с целью придумать именно
> универсальную структуру, годную для описания любой инфосистемы на уровне данных, без изменения реляционной
> структуры.

Ну, по этому поводу здесь уже были замечания, повторяться не буду.

> Традиции приходят и уходят...

Не думаю. Динамика традиций проектирования реляционных баз данных imho заключается в увеличении роли адаптивной составляющей по сравнению с детерминированной. И только. Я бы не стал называть это новыми традициями.

> Разве стандарт SQL ставит ограничения на степень нормализации данных, или на структуру логической модели данных
> приложения???

Не помню, не могу сказать.

> Хотя можно привлечь к обсуждению авторов / владельцев подобных систем. Есть такие в реале.

Вы знаете о практических реализациях этой задачи? Поделитесь ссылками, pls, очень интересно.



2 Alexey Rovdo

> Для любого отношения можно построить адекватную струтуру класса (классов).

Кто бы с этим спорил. ;)

> то чем это отличается от попытки создания объектной СУБД, где в качестве хранилища данных выступает некая структура,
> размещаемая внутри РСУБД?

Хороший вопрос. Дело в том, что мне не нужна объектная реализация как таковая: с удовольствием предоставлю возможность решать эту задачу промежуточному уровню (благо вариантов масса) ПО. Но при этом хотел бы иметь дополнительную функциональность, отличную как от объектных СУБД, так и от реляционных. Один из примеров я Вам привел. Их (примеров) еще есть. ;)

> Не проще ли в таком случае просто переориентироваться на использование чистой ООСУБД,

Не проще.

> в которой можно отследить и достаточно сложные случаи модификации структуры данных и их взаимосвязей?

Хм... это не есть главная задача.

> Ведь любое моделирование [...] приводит нас к модели в виде какого-то графа.

В данном случае Вы ошибаетесь.
...
Рейтинг: 0 / 0
13.01.2005, 20:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864098
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Дополнение: если обсуждаемое решение дополнить семантической составляющей (в предположении, что хронология, права доступа, мультиязычность и пр. реализованы), получившася база данных будет imho иметь основания таковой называться.

Остался без обсуждения вопрос о единственности информационного пространства. Какие будут соображения на этот счет?
...
Рейтинг: 0 / 0
13.01.2005, 20:45
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864255
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Поскольку запросов на выборку данных будет гораздо больше, чем модификаций структуры базы,
рациональнее хранить данные в отдельнах таблицах. (то есть в РБД)
Но при этом обращаться к данным только через объектную надстройку.
Другими словами, генерировать SQL-запрос к реляционной базе на основе метаданных.
Такой подход даст производительность сравнимую с РБД и одновременно придаст БД гибкость.

Исключить прямые обращения к таблицам и полям из клиентского приложения.
Т.е. работать с данными только через ОО-надстройку.
...
Рейтинг: 0 / 0
14.01.2005, 07:31
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864261
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
2 vybegallo:
Считаю, некорректным выяснение отношений в рамках данного топика.
Также считаю пустой тратой времени общение с человеком препятствующим развитию идеи в то время как подавляющее большинство занимается ее развитием и верят в ее состоятельность.
Ваши дальнейшие посты будуть игнорироваться.
...
Рейтинг: 0 / 0
14.01.2005, 07:34
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864270
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vybegallo
Гость
adisk2 vybegallo:
Считаю, некорректным выяснение отношений в рамках данного топика.
Также считаю пустой тратой времени общение с человеком препятствующим развитию идеи в то время как подавляющее большинство занимается ее развитием и верят в ее состоятельность.
Ваши дальнейшие посты будуть игнорироваться.

Одно из двух : или JOIN не удалось написать, или время выполнения зашкалило за все пределы разумного.

Да развивайте на здоровье вашу идею, уважаемые ! У меня подобная система в продакшн сидит - своими руками бы автора задушил, жаль, он уволился лет пять назад... А в теории да, система замечательная, позволяет все что угодно описать пятью таблицами. Между прочим, говорят, любую мысль в русском языке можно передать словоформами пяти матерных корней :-)
...
Рейтинг: 0 / 0
14.01.2005, 07:52
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864271
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
БД можно представить в виде направленного графа.
Направленные дуги - это связи м/у объектами.

Хочу дать пользователю возможность отметить необходимые атрибуты
(причем атрибуты разных объектов),
программа найдет связи м/у объектами (опираясь на описание связей в метаданных),
и в итоге пользователь получит запрашиваемый список.
Причем любой список пользователь сможет формировать самостоятельно.


Такая программа уже реализована в качестве эксперимента, и уже тестировалась на рабочей РБД. (Не ОО)
Хоть и с глюками, но работает!
...
Рейтинг: 0 / 0
14.01.2005, 07:59
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864365
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 vybegallo

> Есть такой старый анекдот
> Сидит чукча на дереве и пилит под собой ветку. Прохожий ему
> - что ты делаешь, ты же упадешь !
> чукча продолжает пилить, падает, встает - "Колдун, однако !"
> Я понятно намекаю ?

Амвросий Амбруазович!
Я тут посмотрел по форуму...
Вы оказывается не только в нашем топике проверяете, чтобы народ на нужных ветках сидел и в руки ничего лишнего не брал.
Как, не тяжело за всеми сразу следить??? На пенсию не пора еще?
Я понятно намекаю ?
...
Рейтинг: 0 / 0
14.01.2005, 09:32
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864385
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Я собственными глазами видел систему и даже чуть чуть работал с ней, в которой есть именно "Поскольку запросов на выборку данных будет гораздо больше, чем модификаций структуры базы,
рациональнее хранить данные в отдельнах таблицах. (то есть в РБД)
Но при этом обращаться к данным только через объектную надстройку.
Другими словами, генерировать SQL-запрос к реляционной базе на основе метаданных.
Такой подход даст производительность сравнимую с РБД и одновременно придаст БД гибкость. "
Исключить прямые обращения к таблицам и полям из клиентского приложения.
Т.е. работать с данными только через ОО-надстройку."

Подозреваю, что для Вас объем базы 580 Гб великоват, но я бы сказал, что система очень тормозит. Кстати, для такой системы очень важно, чтобы она была привязана к конкретной субд, так как она будет вся построена на динамическом sql, а при больших объемах всплывают тонкости, на которые обычно забиваешь в малых БД (для меня это 14-20Gb). Это я к тому, что независимость от СУБД вряд ли удастся, потому как у многих это самоцель...

Кстати, г-н Adisk, Вы умнеете на глазах. Теперь уже не хотите, по крайней мере, все (изменяющиеся данные и бизнес-логику) хранить в "единой универсальной структуре".
...
Рейтинг: 0 / 0
14.01.2005, 09:40
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864498
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
guest_20040621Дополнение: если обсуждаемое решение дополнить семантической составляющей (в предположении, что хронология, права доступа, мультиязычность и пр. реализованы), получившася база данных будет imho иметь основания таковой называться.

Остался без обсуждения вопрос о единственности информационного пространства. Какие будут соображения на этот счет?

Вопрос конечно интересный!
Что называть единым инфо-пространством?!
Применительно к коммерческим структурам (что наверное большинству здешних посетителей ближе) это значит, что должны быть максимально автоматизированы бизнес-процессы всех подразделений организации, которые имеет смысл автоматизировать, с целью повышения эффективности деятельности и снижения затрат на обеспечение работы организации вцелом.
При этом, конечно, есть процессы, которые необходимо автоматизировать с помощью СУБД, но есть и такие, для которых достаточно будет M$ Office. (всех мух из котлет надо сразу повыковыривать!)
Возможные варианты на мой взгляд:
1) Все пользователи работают с различными интерфейсами функциональных частей (модулей/задач/... - как это реализовано практически - сейчас не важно) инфосистемы, базирующейся на единственной, общей многофункциональной БД;
2) Разные пользователи работают с различными интерфейсами функциональных частей нескольких многофункциональных подсистем (каждая на своей БД), реализованных с поддержкой общей (единой) БД метаданных.
3) Разные пользователи работают с интерфейсами нескольких узкоспециализированных подсистем (каждая на своей БД), реализованных с поддержкой общей (единой) БД метаданных.
п.3 есть разновидность п.2. Оба они гораздо сложнее в разработке и поддержке, чем 1, но должны дать большую производительность. Хотя у каждого варианта есть свои плюсы и минусы. Например от 1 к 3 возрастает сложность аналитики данных, что иногда может перевесить плюс производительности.
Если говорить о функциональности, то в идеале наверно для всех (крупных организаций) обязательно д.б. реализован полный замкнутый документооборот, возможно реализация интранет на основе СУБД... Остальные функциональные части будут зависеть от специфики организации.

Кстати, guest_20040621, интересно узнать ваш взгляд на необходимость и форму реализации мультиязычности!
...
Рейтинг: 0 / 0
14.01.2005, 10:25
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864535
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Посмотрите систему интеграции TMU Decarte, мне кажется она довольно интересна и соответствует обсуждаемым в этом топике идеям.А то, не сомневаюсь, велосипедов наизобретаете много да и клавиатуры постираете -:(
...
Рейтинг: 0 / 0
14.01.2005, 10:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864576
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
ShtockЯ собственными глазами видел систему и даже чуть чуть работал с ней

Расскажите как она устроена. Как хранятся данные?
Как создаются формы ввода?
Как реализована версионность (исторя)?

Shtock
Подозреваю, что для Вас объем базы 580 Гб великоват, но я бы сказал, что система очень тормозит. Кстати, для такой системы очень важно, чтобы она была привязана к конкретной субд, так как она будет вся построена на динамическом sql, а при больших объемах всплывают тонкости, на которые обычно забиваешь в малых БД (для меня это 14-20Gb).

Верно, такими объемами "живых" данных манипулировать не приходилось.
Сечас пробую сделать так:
1. заполняю описание базы (то есть Объектную надстройку)
2. из описания генерирую таблицы (create) или изменяю их структуру (alter table)
3. далее для обращения к данным динамически формирую SQL-запросы,
но предполагаю кеширование SQL-запросов (кеширование не данных, а SQL-выражений)
4. динамически формирую формы ввода (т.е. есть шаблон формы, на котором в левой части в столбик располагаются поля , в правой части связанный с текущим полем справочник)
такой вид:
Код: plaintext
1.
2.
3.
4.
5.
 --==== |+-----+
 --==== ||     |
 --==== ||     |
 --==== ||     |
 --==== |+-----+

Проблемы:
1. сложно генерировать запросы с GROUP BY и UNION - пока не могу придумать единый механизм;
2. для формы содержащих вычислемые значения, надо писать процедуры - то есть не все генерится; (халява не проходит ;))
3. как ни крути надо как-то поддерживать версионность кода. Для обработки старых данных, прошлых перидов и т.д. использовать старый код, для текущих - новый.

А в целом, имея метаописание базы, предоставляя пользователю, понятные русские названия объектов, даем ему возможность самостоятельно манипулировать данными! (может даже так просто как в Excel!)

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

Shtock
Теперь уже не хотите, по крайней мере, все (изменяющиеся данные и бизнес-логику) хранить в "единой универсальной структуре".
Твердо убежден, что комбинация "универсального хранилища" и РБД - лучшее решение.
Именно их комбинация - данные с неизменяемой (статичной) структурой в РБД, с дополняемой (изменяемой) структурой в некотором общем хранилище.
Лучше чем описано в ссылке, приведенной выше, описать не смогу.
...
Рейтинг: 0 / 0
14.01.2005, 11:02
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864670
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Поздравляю с прозрением. На самом деле, это стандартная архитектура большинства современных коробочных ИС.
Вся история ведется в РБД. Схема движка-коммерческая тайна, но суть Вы и сами объяснили (метаданные по реляционным (не добавляемым автоматом, я не считаю это правильным) таблицам. Синхроницация метаданных идет автоматом по словарю БД., описание методов (с учетом того, что есть полиморфизм) как имя хранимой процедуры + список параметров).
Я работал с серверной частью,но знаю, что формы генерятся полностью автоматом, далее из них убирается то, что не нужно системой контроля доступа.Истории бизнес-логики там не было.
Например, в системе BusinessObjects это называется "метаслой", правда это business intelegence система и в ней нет методов.
Кстати, по поводу велосипедов, метаданные максимально просто хранить в XML, что автоматом решает проблему разработки пользовательского интерфейса настроек ИС, ведь редакторов xml до черта.
...
Рейтинг: 0 / 0
14.01.2005, 11:37
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32864768
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
2 Shtock

> Кстати, для такой системы очень важно, чтобы она была привязана к конкретной субд, так как она будет вся построена на
> динамическом sql,

По поводу динамического SQL - совсем не обязательно.

> а при больших объемах всплывают тонкости, на которые обычно забиваешь в малых БД (для меня это
> 14-20Gb). Это я к тому, что независимость от СУБД вряд ли удастся, потому как у многих это самоцель...

Хм... смотря по тому, на каком уровне говорить о независимости.



2 skorohod

> Что называть единым инфо-пространством?!

Хороший вопрос. ;)

> 1) Все пользователи работают с различными интерфейсами функциональных частей (модулей/задач/... - как это
> реализовано практически - сейчас не важно) инфосистемы, базирующейся на единственной, общей многофункциональной
> БД;
> 2) Разные пользователи работают с различными интерфейсами функциональных частей нескольких многофункциональных
> подсистем (каждая на своей БД), реализованных с поддержкой общей (единой) БД метаданных.
> 3) Разные пользователи работают с интерфейсами нескольких узкоспециализированных подсистем (каждая на своей БД),
> реализованных с поддержкой общей (единой) БД метаданных.

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

> Кстати, guest_20040621, интересно узнать ваш взгляд на необходимость и форму реализации мультиязычности!

В общем случае imho обязательно. Немного задач, которые реально позволяют без нее обойтись. Форма - традиционная (любой из трех возможных способов на выбор). Наличие/отсутствие локализованных значений регистрируется в метаописании как один из признаков.
...
Рейтинг: 0 / 0
14.01.2005, 12:12
| Ответить | Цитировать | Написать  
25 сообщений из 438, страница 10 из 18
  10  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]