Отражение объетов на реляционную БД. Подходы? Способы?

← →
mvg_first (2002-11-06 17:18) [0]

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

Суть вопроса: Каким образом можно хранить объекты в БД, а главное каким образом работать с этими объектами используя всю мощь Объектного языка, такого как делфи например.

Понимаю что слишком туманно, поэтому приведу пример, который,IMHO,прольет свет на мою проблему.

Итак если разрабатывать любую систему средней сложности в ней всегда есть объекты представляющие какие нибудь сущности реального мира возьмем к примеру сотрудника организации.

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

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

Но тут появляется второй вопрос, как быть с большими объемами данных? Например - есть перечень сотрудников в 10 000 человек? Таблица вроде бы и не большая? Но если прочитать данные в объекты то это уже 10 000 экземпляров только одной сущности, а их может быть и больше например товары народного потребления? Не будет ли проблем с памятью или со скоростью обработки?

И как отображать это все? Ведь DBGrid просто показывает таблицу,
а не перечень сущностей???

← →
mvg_first (2002-11-06 17:24) [1]

Есть кончено специализированная БД называется помоему "Cache" - но так как она не понастоящему объектная а только на 70% то я исключил ее из рассмотрения и стараюсь рассматривать эту проблему в следующей связке Delphi + MS SQL 2000.

← →
mvg_first (2002-11-07 11:21) [2]

Господа, может непонятен вопрос? Или есть другие причины мне не отвечать? Я затрагиваю чье-то ноу-хау?

← →
Fiend (2002-11-07 11:30) [3]

та нет. просто вы немного бредово подходите к решению вопроса.
Зачем вам отображать объект из БД(в сущности результат выбора данных из нескольких таблиц)в объект ООП языка. Это просто ни к чему.

← →
mvg_first (2002-11-07 11:43) [4]

Предложите альтернативный вариант, хотя бы в намеках...

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

Т.е. если мне необходим объект сотрудник с определенным поведением и свойствами - то это очень легко реализуется. Но я хотел бы получить какой нибудь совет по хранению, а главное способам отображения на экране этих объектов ( в больших количествах).
Мне не проблема создать TList и в нем хранить перечень объектов TCustomer которые на старте программы подгружать из базы. Но Что делать если у меня есть множетсво сущностей (пользователи, документы, товары), а так же множество потомков этих сущностей? Не грузить же все это в память?
Да и оборажать на экране это как? DBGrid - удобная вещь - но он отражает просто данные из таблицы - но это же не объекты??? Или я ошибаюсь??

Как это делают? Мне интересно мнение профессионалов.

← →
asmith (2002-11-07 12:30) [5]

Почитай статью А.Тенцера "База данных — хранилище объектов" в журнале КомпьютерПресс, вот только не помню года и номера. Если не найдешь - могу ее замылить.

← →
mvg_first (2002-11-07 12:42) [6]

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

Как мне например в своей программе отобразить список из 10 000 товаров? А если каждый товар имеет еще и свой собственный класс? Производный от базового?

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

Сложность в процедуре отображения списков объектов на экране.

← →
mvg_first (2002-11-07 13:46) [7]

Я спрашиваю нечто банальное? Или никто не решал такие проблемы?
Может если нет желания отвечать на вопрос? То хотя бы ткните в статейку каку нибудь или материальчик, где бы я свои пробелы мог восполнить.

← →
Fiend (2002-11-07 15:25) [8]

меня осенило: а может вы просто неправильно пытаетесь применить SQL Server, ну или любую другую СУБД???

В вашем клиентском приложении, если вы будете делать клиент-сервер систему, должно быть как можно меньше опора на сам принцип организации данных в базе данных. Т.е. БД должна существовать сама по себе. быть полностью управляемой собственными процедурами и функциями. В клиенте должен быть полный тривиал. Оно не должно ничего считать-вычислять. Конечно от этого не всегда удаётся уйти. Есть такие случаи но их достаточно мало.

Поэтому реализовывайте БД не оглядываясь на ООП язык клиента. Клиент только даёт так сказать комманды, которые надо выполнить. а база сама знает как. Для этого задуманы ХП, ЮДФ.

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

Ну никто же не будет вас тут учить такому глобальному вопросу. Вы ведь и сами это понимаете.

ЗЫ: С наилучшими!

← →
MsGuns (2002-11-07 16:09) [9]

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

← →
mvg_first (2002-11-07 16:48) [10]

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

Повторяю, у меня нет сложностей с организацией храниения объектво в бд. И я то же сторонник мнения что бд не должна знать как функционирую объекты которые в ней храняться. НО!!!

Мое клиентское приложение как раз знает что за объекты оно считывает из бд. Проблема не в этом. Проблема в том что я не знаю как оптималоно отображать (отрисовывать) на экране клиентского приложения большие объемы (списки) экземпляров разработаннх мною объектов.

Т.е. если у меня есть класс TCustormer и есть у него метод Сохранить_в_бд и Загрузить_Из_БД который унаследован из класс (допустим) TDBItem у которого то же есть методы Сохранить_в_бд и Загрузить_Из_БД. То как раз в этом случае мне все понятно. Вызывает вопрос как работать с такими объектами когда их в бд лежит непомерное количество?

Т.е. как организовывать структуру именно клиентского приложения?
Вот в чем мой вопрос. На ум приходит понятие TCustomerList(TList) - у которого есть методы LoadObectsFromDB который насоздает кучу объектов? вызовет у каждого метод Загрузить_Из_БД и при этом засрет мне кучу памяти :).

Поэтому я и спрашиваю о подходах в реализации отражения списков объектов на клиенстком приложении.

Как они будут лежать в БД меня это пока не волнует.

уфф... надеюсь объяснил.

← →
Fiend (2002-11-07 17:50) [11]

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

Просто опишите конкретный пример, именно конкретный!!!!, где вы считаете нужно создать классы.

← →
A.White (2002-11-07 17:56) [12]

Я думаю надо так: TCustomerList(TList) не дожен создавать кучу обьектов, ему надо уметь getCustomerByID() для создания конкретного объекта, и иметь метод заполняющий DBGrid.
Но как бы для этого есть TDataSource, но он работает напрямую с базой (в смыcле минуя твои обьекты :(). Может на базе TDataSource создать TCustomerDataSource создающий и управляющий твоими обьектами ? ...
Или написать свою прослойку представления твоих обьектов и прослойку работы с базой на основе примитивов (StringGrid и т.д.)

PS. Посмотри мапинг и представления на Java ресурсах, там примерно такие подходы используются, может натолкнет на мысли.
Presentation Layers, Database maping и т.п.

Если я правильно понял ... :)

WBR, A.White

← →
mvg_first (2002-11-07 20:52) [13]

TO Fiend
Вообщем то щас, никаких объектов, в пример привести не могу, я анализирую концептуальные возможности :). Т.е. каким образом работать, как строить архитектуру, какие базовые (абстрактные) классы создавать. Но почему вы думаете, что Пользователь, Товар, Клиент, Счет... и другие сущности физического мира не могут быть выражены в виде объектов? Ведь как Вы сами говорили, клиент не должен зависеть от способа хранения данных в БД так же как и БД не должна зависеть от способа обработки данных клиента. ( вообщем то вы так не говорили, это моя интерпретация, но я не думаю что она далека от истины).
Тем более что использовать объекты гораздо приятнее при программировании чем не использовать. Взять хотя бы аспект описания поведения объекта в одном месте, а не в пятнадцати местах, где это может понадобится в процессе эксплуатации системы

← →
mvg_first (2002-11-07 20:59) [14]

TO A.White

> Я думаю надо так: TCustomerList(TList) не дожен создавать
> кучу обьектов, ему надо уметь getCustomerByID() для создания
> конкретного объекта, и иметь метод заполняющий DBGrid

Вообщем то так я себе где то и представлял. Т.е. для каждой сущности в моей системе - будет обязательно присутствовать "менеджер сущности", который и будет отвечать за предоставление, списка сущностей или предоставления конкретной сущности (а так же предоставлять различного рода севрисные возможности, по работе со списками сущностей, групповые обработки, фильтрующие выборки и т.д.)
Где то подкожно проскакивает ощущение что, то о чем я тут "мечтаю" - уже выраженно ввиде паттернов проектирования. Господа знающие (читавшие эту книгу) подскажите так ли это???

← →
mvg_first (2002-11-07 21:01) [15]

To All
Обсуждение остается открытым, жду Ваших советов, рекомендаций, наставлений.

← →
MsGuns (2002-11-07 21:20) [16]

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

а) зачем и кому это надо
б) во что это выльется
в) а стоит ли а) тратить на б)

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

PS Вы когда-нибудь сталкивались с SAP R/3 Там кое-какие идеи из того, что Вы здесь излагали, реализованы. В рез-те на западе, где все или почти все упрощено и унифицировано, эта штука работает, в Союзе же не не знаю ни одного объекта, который бы смог реально внедрить и полноценно эксплуатировать этого монстра

← →
MsGuns (2002-11-07 21:20) [17]

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

а) зачем и кому это надо
б) во что это выльется
в) а стоит ли а) тратить на б)

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

PS Вы когда-нибудь сталкивались с SAP R/3 Там кое-какие идеи из того, что Вы здесь излагали, реализованы. В рез-те на западе, где все или почти все упрощено и унифицировано, эта штука работает, в Союзе же не не знаю ни одного объекта, который бы смог реально внедрить и полноценно эксплуатировать этого монстра. Система сверхжестка именно из-за ее "объектности"

← →
A.White (2002-11-08 00:15) [18]

Паттернов на архитектуру неизвестной системы ?:) Посмотрите все-таки на JAVA ресурсах - там много интересных решений. Там, кстати, и паттернов навалом. Все будет зависить от задачи, а если говорить о концептуальных возможностях, то D6, в плане реализации многоуровневого подхода, может сгодиться (хотя, наверное, судя по ответам, никто не пробовал), надо только разобраться в его (D6 компонентах) подходе. Или написать свои компоненты :)

TO: MsGuns
а) зачем и кому это надо<i/>
Вопрошавшему
б) во что это выльется<i/>
К универсальному походу для создания определенной бизнес-логики, независимой от представления и способов сохранения, которую можно будет использовать в дальнейшем.
в) а стоит ли а) тратить на б)<i/>
"Для себя, для любимого" Чтоб по несколько раз одно и тоже не создавать. "WORA"

Удачи!

WBR, A.White

← →
sniknik (2002-11-08 00:41) [19]

может будет интересно
http://www.osp.ru/os/2002/09/057.htm

← →
Fiend (2002-11-08 10:29) [20]

Я всё же еще раз поддержу MsGuns: по моему вы пытаетесь сделать из мухи слона. Поясню почему.
Вот первый довод: у вас еще нет конкретной проблемы, где вы считаете нужно применить объектность. Я так считаю подобные проблемы надо решать по мере их поступления. А вы сами говорите что привести конкретных объектов привести не можете.

Довод второй: концептуальный анализ возможностей СУБД (для хранения объектов сотрудников, товаров или еще чего то там) во время того как уже стоит конкретная задача (я так понял надо сделать кадры, материалы) и вам чётко говорят(MsGuns) что подобные задачи не настолько сложны, чтобы применять объекты в БД, и что они замечательно решаются "линейно" - это помоему ДЕМАГОГИЯ, вместо действий.

Ну и третий довод(чисто пример): лично вот я применил "объекты" в БД для такой задачи CAD. Т.е. есть у меня такой комплекс, который предназначен для составления подробнейших карт города с нанесением ЛЭП, колодцев, ТП, не говоря уже о домах и разводке коммуникаций в них. Я счёл эту задачу достаточно сложной для того чтобы было необходимо применить объекты в БД. И сделал там наследование и т.п.

Удачи!

← →
A.White (2002-11-08 12:32) [21]

Вот чего надыбал :)
"Bold - комплекс интегрированных с Delphi инструментальных средств и компонент для построения масштабируемых прикладных систем на базе концепции бизнес-объектов по схеме MDA (Model Driven Architecture)." (c)iBase, www.ibase.ru

http://shop.ibase.ru/news/n1.htm#starbase

Может это поможет? Входит в поставку D7

Удачи

WBR, A.White

← →
mvg_first (2002-11-08 12:50) [22]

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

MsGuns
Теперь по пунктам
а) (зачем) я создаю ядро системы(трехзвенки) в которую хочу вложить работу с объектами; (кому) нужно, мне как программисту, а также моей организации, что бы в дальнейшем опираться на ядро разрабатывая любые объекты бизнес-логики
б) Во что это выльется я пытаюсь выянить сейчас, спрашивая совета у мастеров, и пытаясь определить оптимальное соотношение для включения и использования ООП при разработке.
б.1) Выльется это в большие затраты на разработку ядра и стандартизацию методов работы сним внутри организации, а так же выльется
в) Однозначно стоит, так как, нормальные системы без ядра работать не смогут, а "Кадрики" и "Складики" написанные быстро и наскорую руку очень тяжелы в последующей модернизации особенно если ее (модернизацию) будет выполнять не автор.

sniknik
Интересно, было, тем более что оно вплотную пересекается с одной моей разработкой, то же делал универсальный каталог, и он даже работал :).

← →
mvg_first (2002-11-08 12:58) [23]

A.White
Bold for Delphi входит в состав Delphi 7 >Studio Architect<
Вот именно такого D7 у меня нету :(
А вообще я пробовал скачивать его для D6 но видимо то ли мозги у меня еще не созрели, то-ли еще по какой причине, но как им пользоваться я так и не вогнал :((
Может кто поможет освоиться с этим продуктом. У кого есть опыт реального использования Bold for Delphi

← →
MsGuns (2002-11-08 13:46) [24]

>mvg_first © (08.11.02 12:50)

Кажется, догнал !
Тема, безусловно, интересная, но, ИМХО, требует значительных инвестиций (чего я себе, к примеру, позволить не могу). Я, как Вы правильно изволили выразиться, клэпаю "складики" и "кадрики", т.к. ни на что более красивое у меня просто нет времени (денег). В бытность свою инженером-программистом на радиозаводе я сталкивался с несколькими подобными проектами (тогда они назывались САП и САКП), одна из которых (не помню как называлась, но помню что разрабатывалась в ГДР, дорабатывалась в Калининграде, а потом в Харькове) очень меня заинтересовала своим оригинальным подходом. К сожалению, реализация его оставляла желать лучшего, что было типично для Союза. Были даже у меня какие-то конспекты и магн.лента (это все было в ОС ЕС), но на заводе не работаю уже почти 10 лет и все на фиг забылось.

PS.Очень интересно было бы с Вами посотрудничать. С наилучшими. Мой E-mail: MsGuns@ukr.net. Если что получится, прошу, мо и я смогу помочь советом (и не только).

Отражение объетов на реляционную БД. Подходы? Способы? Найти похожие ветки