 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Dmitry V. Liseev 2:5020/400 02 Feb 2002 00:19:26 To : Andrei N.Sobchuck Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- a> <3C566831.3070805@cssc.tat.ru> <rhu53a.2i.ln@server1.mart.cherkassy.ua> a> <3C5A4C84.2050401@cssc.tat.ru> <slmd3a.gt6.ln@server1.mart.cherkassy.ua> a> <3C5A7303.6040900@cssc.tat.ru> <u96e3a.k4m.ln@server1.mart.cherkassy.ua> From: "Dmitry V. Liseev" <dimik@infopro.spb.su> Andrei N.Sobchuck <andrei@mart.cherkassy.ua> wrote in message news:u96e3a.k4m.ln@server1.mart.cherkassy.ua... Hi! > Кстати о маппинге. Ко всем. > В результате запроса получили объект на клиенте. > Другой пользователь удалил из базы записи из которых > объект был "собран". > Что с этим уже не существующим объектом должно > происходить на клиенте? > Ответ попрошу разжевать. В Cache поскольку первый клиент держит интерфейс на объект, то из памяти сервера (в данном процессе) он не удалится в соответствии с правилами подсчета ссылок, но другой пользователь может удалить объект с диска. у меня есть 3 варианта: 1. Поскольку объект был удален с диска, но жив в памяти, то рассматривать его как новый (только-что созданный), и при попытке его сохранить - создавать на диске новую запись. 2. При попытке сохранить объект возвращать клиенту исключение. 3. Еще при чтении объекта указать флаг исключающей блокировки, и попытки удаления или модификации объекта другими пользователями будут ставиться на ожидание или отлетать сразу. В реальных задачах использую разные методы в зависимости от ситуации. PS: ИМХО объектная модель, как ее обычно понимают, мало применима к БД и хранению данных. Если у Буча объект понимается, как "нечто целостное", то при хранении объекта он неизбежно "рассыпается", т.к. нам редко нужно просто читать и записывать объекты, их нужно еще и искать. То есть появляются индексы. Если искать нужно по многим критериям, то нужно много индексов, в разном порядке следования, и часто хранение самого "нечто целого" просто не имеет смысла - проще и эффективнее при считывании объекта собирать его из индексов, а при записи обратно расталкивать по индексам. Возникают напряги и с производительностью: Если объект понимать, как "нечто целое", то при извлечении объекта из базы он должен извлекаться целиком, даже если клиенту нужно только одно его свойство. А объект может иметь достаточно сложную структуру и значительный размер. При сохранении опять нужно писать на диск целиком в соответствии с принципом целостности. В то-же время в РСУБД можно делать и селект и апдейт отдельно взятых полей. Ведь инкапсуляция, наследование и полиморфизм существуют не как самоцель, а как средство для достижения обычных целей: необходимо разбивать сложную задачу на достаточно слабо взаимодействующие части, чтобы ее было легче осмыслить, чтобы можно было распараллелить разработку, чтобы легче было сопровождать и развивать, чтобы можно было повторно использовать отлаженный код. Вполне возможно, что в БД этих целей можно достичь несколько иными методами, не придерживаясь строгой идеологии классических ОО-языков разработки. То есть, если ОО-метода рулит при разработке приложений, то это не значит, что она в неизменном виде порулит и в хранении данных, поддержании ссылочной целостности, быстром поиске и многопользовательском доступе. И не лучше-ли вместо втискивания таких задач в рамки существующей ОО-идеологии доработать ее под данную предметную область и создать нечто вроде ОО for DBMS? Или создать что-то принципиально иное? ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 --- ifmail v.2.15dev5 * Origin: Peterlink News System (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/207531338f73c.html, оценка из 5, голосов 10
|
|
|