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

Опять соглашусь с коллегой.
skorohod
2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам;

В точку.

MMS
Объектная надстройка может выглядеть в виде ИК, причем это не способ хранения данных, а метод визуализации их местонахождения.

Точно!

2 MMS
Есть огромное желание объединиться, но, если вы не программер нам с Вами не сладить.
...
Рейтинг: 0 / 0
28.01.2005, 18:24
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890140
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Объектная надстройка может выглядеть в виде ИК,

Может. А может и не выглядеть. Вообще дело десятое, какая структура данных использована для описания объектов.

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

Вы заблуждаетесь. Способ хранения не обязан быть связан с методом визуализации.

> Посмотрел несколько тезаурусов. Душераздирающее зрелище

Что вызвало у Вас столь отрицательные эмоции?
...
Рейтинг: 0 / 0
28.01.2005, 18:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890158
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Dogen
С моей дремучей точки зрения не суть важно, разработаете Вы объектную надстройку над РСУБД или же объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД.
..............
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

Вот если мы затронем вопрос сопровождения готовой ИС и её вполне возможного в перспективе "модельного апгрейда" (речь не идет о "кривом" проектировании - просто со временем требования к отлично спроектированной и реализованной системе могут измениться), это даст нам какую-то точку опоры для определения "уровня абстракции"!
Т.е. от вопроса "кому надо" переходим к вопросу "зачем надо". (немного повторю то, что уже писал здесь раньше)
На мой взгляд - логическая объектная модель ИС д.б. реализована в виде отдельного слоя в РСУБД таким образом, что любое изменение этой логической объектной модели ИС (т.е. требований к функциональности ИС) не влечет, при реализации этих новых требований, никаких изменений ни в структуре РБД ИС, ни в сервере приложений (если он есть), ни в клиентском приложении! Все изменения функциональности ИС будут выполняться путем "манипулирования записями в РБД" (отдельный разговор о методах объектов - есть несколько вариантов, не противоречащих вышесказанному) через, раз и навсегда сделанный, универсальный клиентский интерфейс (или стандартный вэб-клиент).
Если же, как Вы писали, "объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД", то Вам придется (в общем случае) каждый раз, при изменении требований к Вашей ИС и реализации этих требований в объектной модели приложения, и заниматься дальнейшей частью цикла разработки-сопровождения - перекомпилляцией, отладкой, тестированием, переинсталляцией приложения у всех пользователей...
Всего этого можно избежать в первом случае, перенеся процесс изменения ИС только на работу с ОРБД.
Можно это назвать ленью, а можно - сокращением издержек на разработку-сопровождение ИС.
Убедил на счет уровня абстракции?
...
Рейтинг: 0 / 0
28.01.2005, 18:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890159
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Dogen
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

На уровне промежуточной софтины.
И, конечно, на уровне приложения.
...
Рейтинг: 0 / 0
28.01.2005, 18:41
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890163
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
adisk Dogen
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

На уровне промежуточной софтины.
И, конечно, на уровне приложения.


Сколько людей, столько и мнений!
Кто стырил консенсус!!!
:)
...
Рейтинг: 0 / 0
28.01.2005, 18:44
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890172
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
2 MMS
Поищите где-то ближе к началу топика пост от ASU (по-моему, сейчас уже поздно мне искать). Там он довольно хорошо объяснил разницу между иерархией, классификацией (и наследованием). Из-за различного понимания этих терминов тут тоже много непонимания между людьми и лишнего копьеломания.
...
Рейтинг: 0 / 0
28.01.2005, 18:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890173
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Гостю
Поисковые семантические надстройки над Сетью просто лучше ищут нужное в мусорной куче информации. ИК может работать с "обратной стороны", складывая информацию так, чтобы она не образовывала мусорных куч-тогда качество и процессы поиска будут другими.
Мне нужен не "разгребальщик", а "укладчик". В начале топика были высказывания типа "Вот сделал такую фигню (по моему разумению-пробу создания инструментов ИК) , не знаю зачем" - мне показалось в этом можно найти полезное взаиморазумение или хотя бы получить наводку. Очень, знаете ли, не хочется велосипедов изобретать. Тем более, что отношусь к группе 1 :-)
У меня быстро и успешно внедрены две системы управления на АЭС, ИК составляет их основу. Поскольку использовались местные программеры, возможно, они не использовали современных средств (опирающихся на ИК) и я пытаюсь выяснить, существуют ли таковые.
Высказывание академика под сомнение не ставлю. Однако оно может означать лишь отсутствие прогресса в официальной науке, программерские же разработки могут находиться вне ее, либо засекречиваться.

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

1. Существует ли ПО, которое не будучи неотъемлемой принадлежностью СУБД могло бы выстраивать ИК так, чтобы связать (пусть вручную) концы ветвей деревьев ИК с объектами, описанными в произвольной СУБД?
2. Вызывает ли ИК-надстройка над СУБД резкий рост требований к ресурсам?
3. Если стандартных решений нет, но есть собственные наработки-давайте свяжемся по мылу, поскольку на таковые имеется заказчик, хотя и не стопроцентный
...
Рейтинг: 0 / 0
28.01.2005, 18:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890197
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
skorohod Dogen
С моей дремучей точки зрения не суть важно, разработаете Вы объектную надстройку над РСУБД или же объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД.
..............
Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.

Вот если мы затронем вопрос сопровождения готовой ИС и её вполне возможного в перспективе "модельного апгрейда" (речь не идет о "кривом" проектировании - просто со временем требования к отлично спроектированной и реализованной системе могут измениться), это даст нам какую-то точку опоры для определения "уровня абстракции"!
Т.е. от вопроса "кому надо" переходим к вопросу "зачем надо". (немного повторю то, что уже писал здесь раньше)
На мой взгляд - логическая объектная модель ИС д.б. реализована в виде отдельного слоя в РСУБД таким образом, что любое изменение этой логической объектной модели ИС (т.е. требований к функциональности ИС) не влечет, при реализации этих новых требований, никаких изменений ни в структуре РБД ИС, ни в сервере приложений (если он есть), ни в клиентском приложении! Все изменения функциональности ИС будут выполняться путем "манипулирования записями в РБД" (отдельный разговор о методах объектов - есть несколько вариантов, не противоречащих вышесказанному) через, раз и навсегда сделанный, универсальный клиентский интерфейс (или стандартный вэб-клиент).
Если же, как Вы писали, "объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД", то Вам придется (в общем случае) каждый раз, при изменении требований к Вашей ИС и реализации этих требований в объектной модели приложения, и заниматься дальнейшей частью цикла разработки-сопровождения - перекомпилляцией, отладкой, тестированием, переинсталляцией приложения у всех пользователей...
Всего этого можно избежать в первом случае, перенеся процесс изменения ИС только на работу с ОРБД.
Можно это назвать ленью, а можно - сокращением издержек на разработку-сопровождение ИС.
Убедил на счет уровня абстракции?
Не-а, не убедил.
По-моему, Вы сразу потеряете так ВСЕ возможности, предоставляемые РСУБД, кроме возможности тупо хранить данные объекта и искать его по первичному ключу.
...
Рейтинг: 0 / 0
28.01.2005, 19:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890218
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Гостю
\\\Вы заблуждаетесь. Способ хранения не обязан быть связан с методом визуализации

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

adisk
C программерами намного легче ладить, чем с манагерами :-)
Формализованные мозги в коммуникациях дают совсем иное качество понимания, даже без знаний в предметной области. Бросайте опасения :-)

Скороходу
Пост АСУ заметил, в этой проблематике давно. Не люблю рассуждать про инкапсуляции и прочие суперпозиции. Если не стремиться к идеальному качеству классификации (которое невозможно), то вполне реально создавать ИК с качеством "достаточным для инженерных расчетов"; их может быть несколько (на любителя) - каждый со своими проколами. Дальше-вопрос привычки.
С наследованием никогда проблем не было, ограничивался набором конкретных признаков объекта и не залазил в дебри.
...
Рейтинг: 0 / 0
28.01.2005, 19:28
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32890261
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
MMSГостю
Поисковые семантические надстройки над Сетью просто лучше ищут нужное в мусорной куче информации. ИК может работать с "обратной стороны", складывая информацию так, чтобы она не образовывала мусорных куч-тогда качество и процессы поиска будут другими.
Мне нужен не "разгребальщик", а "укладчик". В начале топика были высказывания типа "Вот сделал такую фигню (по моему разумению-пробу создания инструментов ИК) , не знаю зачем" - мне показалось в этом можно найти полезное взаиморазумение или хотя бы получить наводку. Очень, знаете ли, не хочется велосипедов изобретать. Тем более, что отношусь к группе 1 :-)
У меня быстро и успешно внедрены две системы управления на АЭС, ИК составляет их основу. Поскольку использовались местные программеры, возможно, они не использовали современных средств (опирающихся на ИК) и я пытаюсь выяснить, существуют ли таковые.
Высказывание академика под сомнение не ставлю. Однако оно может означать лишь отсутствие прогресса в официальной науке, программерские же разработки могут находиться вне ее, либо засекречиваться.

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

1. Существует ли ПО, которое не будучи неотъемлемой принадлежностью СУБД могло бы выстраивать ИК так, чтобы связать (пусть вручную) концы ветвей деревьев ИК с объектами, описанными в произвольной СУБД?
2. Вызывает ли ИК-надстройка над СУБД резкий рост требований к ресурсам?
3. Если стандартных решений нет, но есть собственные наработки-давайте свяжемся по мылу, поскольку на таковые имеется заказчик, хотя и не стопроцентный

Пункт '3' меня заинтересовал, если это взаимно, то пишите на мыло, здесь тусоваться считаю для себя малопродуктивным.
По пункту '1' - ответ положительный,
по пункту '2'-отрицательный. Разумеется эти данные экспериментальные, а не голая теория.
...
Рейтинг: 0 / 0
28.01.2005, 20:11
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891235
Рус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рус
Участник
EJB или JDO - вот вам и объектная надстройка над СУБД. Не изобретайте велосипед, господа!
...
Рейтинг: 0 / 0
30.01.2005, 17:46
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891916
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Rovdo
Гость
РусEJB или JDO - вот вам и объектная надстройка над СУБД. Не изобретайте велосипед, господа!

Все не так просто в этом топике. Господа хотят больше, чем дает типовой O/R-мэппинг. И при этом хотят во что бы то ни стало работать только с тем инструментарием, который доступен в составе существующих РСУБД (т.е. использовать JDO в качестве отправной точки в своих разработках они не считают возможным).
И если первое я могу понять, то причины второго я так и не осознал (впрочем, возможно я и не очень старался, а с другой стороны - каждый имеет право распоряжаться своим временем как пожелает).
...
Рейтинг: 0 / 0
31.01.2005, 11:42
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891959
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
IMHO, ООСУБД - не подходят, потому-что для всей системы будет только один класс, у которого из атрибутов - коллекция значений аттрибутов...

IMHO, Mon$te®
...
Рейтинг: 0 / 0
31.01.2005, 11:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32891996
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4d_monster IMHO, ООСУБД - не подходят, потому-что для всей системы будет только один класс, у которого из атрибутов - коллекция значений аттрибутов...

IMHO, Mon$te®
Ну тогда весь этот странный топик - про серверы бизнес-логики. Кому нужен универсальный сервер, в котором можно прописывать возможные алгоритмы обработки атрибутов объектов и коллекций объектов, да еще так чтобы это все осмысленно хранилось и эффективно обрабатывалось в РСУБД?
Маниловщина это всё.
...
Рейтинг: 0 / 0
31.01.2005, 12:08
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892026
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
Мне на пример :-)

а вот "осмысленно хранилось" мне не требуется :), достаточно чего-то типа варианта adisk`a

IMHO, Mon$te®
...
Рейтинг: 0 / 0
31.01.2005, 12:19
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892062
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4d_monsterМне на пример :-)

а вот "осмысленно хранилось" мне не требуется :), достаточно чего-то типа варианта adisk`a

IMHO, Mon$te®

А тогда при чем тут РСУБД - хоть вы в файлах объекты храните и нумеруйте их файл0001.ххх, хоть в РСУБД, так и так "не осмысленно".
...
Рейтинг: 0 / 0
31.01.2005, 12:29
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892137
Фотография 4d_monster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4d_monster
Участник
не то, нодопоняли, хранить естественнов РСУБД,
но "осмысленное хранение" подразуменвает хранение в таблицах с осмысленными названиями, с осмысленно названными полями. а это мне не нужно

IMHO, Mon$te®
...
Рейтинг: 0 / 0
31.01.2005, 12:50
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32892159
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dogen
Участник
4d_monsterне то, нодопоняли, хранить естественнов РСУБД,
но "осмысленное хранение" подразуменвает хранение в таблицах с осмысленными названиями, с осмысленно названными полями. а это мне не нужно

IMHO, Mon$te®
Я имел в виду хранение в осмысленной структуре данных, учитывающей алгоритмы обработки - с построением полезных индексов, с нормализацией в разумных пределах.
Иначе для чего Вам РСУБД? Ни для чего. А как именовать поля - дело десятое, если Вы до такого уровня опускаться не собираетесь.
...
Рейтинг: 0 / 0
31.01.2005, 12:57
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32899756
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Кто-то спрашивал про базу данных ген.
Загляните.
http://gmod.sourceforge.net/
Возможно поможет.
...
Рейтинг: 0 / 0
03.02.2005, 16:39
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32899916
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
В недрах sf.net обнаружена интересная СУБД.
MonetDB http://monetdb.sourceforge.net/

Представьте себе базу в которой проведена полная декомпозиция.
Все поля таблиц разделены.
Другими словами: модель Тенцера (attribs+objects) разделенная на много таблиц.
Для каждого атрибута своя таблица.
...
Рейтинг: 0 / 0
03.02.2005, 17:36
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32900104
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
adisk
Участник
Описания ядра системы
http://monetdb.cwi.nl/TechDocs/Core/monet/index.html
и плагаю схемку с сайта.
...
Рейтинг: 0 / 0
03.02.2005, 18:35
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32901320
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Для каждого атрибута своя таблица.

Наверное для каждого типа атрибута своя таблица?
Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
04.02.2005, 13:49
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32901429
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skorohod
Гость
Своя таблица для каждого атрибута, а не типа!!!
Полная противоположность вариантам организации О. ядра системы на РСУБД, которые ранее упоминались в этом топике. ("горизонтальный" и "вертикальный" O-R маппинг)
imho на первый взгляд скорость доступа к атрибутам в отдельных таблицах съедается увеличением сложности методов O-R ядра. Или я не прав?
...
Рейтинг: 0 / 0
04.02.2005, 14:15
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917315
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
ASUВ раннем творчестве А. Макаревича была песня "Битва с дураками", она заканчивается словами:
Код: plaintext
1.
2.
3.
Когда последний дурак упал,
Труба победу проиграла.
И лишь тогда я осознал,
Насколько нас осталось мало.
Экзюпери говорил, что стоит только начать бороться с горбунами, как станет заметно, что действительно прямоходящих людей очень мало...
Александр Сергеевич, уж не ожидал вас встретить на этом форуме, но тем приятнее :)
Бог с ним, с маппингом, я почитал - слишком много нестыковок уже на понятйном уровне. А нет ли у вас желания продолжить статью о СУПе ?
http://www.arbinada.com/modules.php?name=Content&pa=showpage&pid=22
...
Рейтинг: 0 / 0
15.02.2005, 21:05
| Ответить | Цитировать | Написать  
Объектная надстройка над релационной СУБД
    #32917317
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
skorohodСвоя таблица для каждого атрибута, а не типа!!!
Полная противоположность вариантам организации О. ядра системы на РСУБД, которые ранее упоминались в этом топике. ("горизонтальный" и "вертикальный" O-R маппинг)
imho на первый взгляд скорость доступа к атрибутам в отдельных таблицах съедается увеличением сложности методов O-R ядра. Или я не прав?
"Вертикального" OR-маппинга не бывает.
...
Рейтинг: 0 / 0
15.02.2005, 21:06
| Ответить | Цитировать | Написать  
25 сообщений из 438, страница 15 из 18
  15  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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