Entity Bean - physical table

Sabina · Post by **Sabina** » 09 Mar 2004 21:12

Опять передо мной выдвинули задачу...

Is there to be one Entity Bean class per database table? If so, then must we perform joins on the application server instead of in the database? That is awful. If we were to perform joins in the database, then the result set would be some hybrid table and, therefore, would not correspond to any one table.
Should we have an Entity Bean class for temporary tables resulting from joins? If there will not be one Entity Bean class per database table, then what do the
Entity Bean classes correspond to? How do we map objects to database tables in a way that allows one to harness the powere of the database? This is a tough
problem. The literature calls it "impedence mismatch", a term that the community borrowed from Electrical Engineering.

Я считаю, что необязательно one entity per table, хотя в большинстве случаев именно так. Что касается joins, они наверняка сидят где-нибудь в stored procedures, стало быть в базе, а аппликация только делает из них select.
И при чем тут "Should we have an Entity Bean class for temporary tables resulting from joins". Ведь entity bean представляет объект, то есть если объект проектируется на несколько физических таблиц, зачем писать entity bean на каждую физическую таблицу? Entity она и есть entity, а не физическая таблица.

Прошу аксакалов покритиковать, если я где неправа.

Спасибо,
Сабина

JustMax · Post by **JustMax** » 09 Mar 2004 21:37

Вы делаете успехи. Абсолютно серьезно.

На самом деле для меня, как для "старого" базовика :oops:

, дизайн базы данных всегда первичен, а потом уже идут всякие beans, ado.net и всякие другие приблуды - и именно они IMHO должны подстраиваться под базу а не наоборот. Когда делается наоборот в 80% случаев проект через некоторое время имеет бледный вид.

Dmitry67 · Post by **Dmitry67** » 09 Mar 2004 21:46

JustMax wrote:Вы делаете успехи. Абсолютно серьезно.
На самом деле для меня, как для "старого" базовика , дизайн базы данных всегда первичен, а потом уже идут всякие beans, ado.net и всякие другие приблуды - и именно они IMHO должны подстраиваться под базу а не наоборот. Когда делается наоборот в 80% случаев проект через некоторое время имеет бледный вид.

JustMax, жму Вашу руку !
особенно меня насторожила фраза

That is awful. If we were to perform joins in the database, then the result set would be some hybrid table and, therefore, would not correspond to any one table.

Явно писанная привеженцем идеологии 'База это чтото странное и непонятное. Лучше мы все на клиенте сделаем'

Strannik223 · Post by **Strannik223** » 09 Mar 2004 21:55

JustMax wrote:Вы делаете успехи. Абсолютно серьезно. :)
На самом деле для меня, как для "старого" базовика :oops:, дизайн базы данных всегда первичен, а потом уже идут всякие beans, ado.net и всякие другие приблуды - и именно они IMHO должны подстраиваться под базу а не наоборот. Когда делается наоборот в 80% случаев проект через некоторое время имеет бледный вид.

И причина этому на мой взгляд такова что именно база обычно является узким местом в смысле производительности.
Поэтому дизайн делается не так как удобнее програмить а так как быстрее будет работать

Sabina · Post by **Sabina** » 09 Mar 2004 22:37

Strannik223 wrote:И причина этому на мой взгляд такова что именно база обычно является узким местом в смысле производительности.
Поэтому дизайн делается не так как удобнее програмить а так как быстрее будет работать

Сразу после ваших слов вспомнился фундаментальный проект. В 1995-96 году организация POSC (Petrotechnical Open Software Corporation) попробовала создать универсальную модель базы данных для нефтяной компании. Они собрали экспертов по всем направленям и сильных программистов. Написали объектно-ориентированную модель Epicenter, с использованием языка EXPRESS. Причем проект был в очень зрелой стадии - были написаны всякие специфические leader-ы, проведена огромная работа по соотвествию стандартам по каждому направлению.
Многие фирмы уже начали писать программные продукты на основе этой модели, а POSC отвоевывал право быть стандартом по всей нефтяной промышленности.

Я тогда работала на французскую фирму, которая начала писать банк данных для нефтяной компании. Поскольку проект грандиозный, они написали каркас и потом сразу стали искать заинтересованных клиентов, чтобы это дело далее финансировать. Добрались и до российского Лукойла. Мне тогда повезло, я под это дело съездила в Англию и Францию на учебу по поводу Epicenter и того самого каркаса, что наши французские кодописатели написали.

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

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

Спросите меня что с этим проектом сейчас? Почил в бозе. Якобы потому, что конкретный переход компаний на эту модель был очень costly, соответственно то что на ее основе написали, не продавалось и все потихоньку сошло на нет. То есть POSC есть и даже модель по-прежнему поддерживает, но они тише воды, ниже травы. Какие уж тут стандарты для всей отрасли. Особенно мне интересно про Алжир, где ихняя государственная нефтяная компания закупила наш продукт и устроила грандиозный проект по перегонке всех алжирских данных за многие годы в Epicenter.

Мораль такова - не доросли мы еще до уровня абстракции, когда все вокруг можно будет представить как entitites. В смысле умом дорасли, а вот материально не тянем :mrgreen:

Сабина

Dmitry67 · Post by **Dmitry67** » 09 Mar 2004 22:59

Sabina
Вот почему Вы во Франции поработали
Кстати с очередной аватарой Вас

Dmitry67 · Post by **Dmitry67** » 09 Mar 2004 23:35

PS
А с нефтяной компаией я думаю дело было вовсе не в структуре таблиц
Просто об откатах не договорились

JustMax · Post by **JustMax** » 09 Mar 2004 23:39

Strannik223 wrote:
JustMax wrote:Вы делаете успехи. Абсолютно серьезно.
На самом деле для меня, как для "старого" базовика , дизайн базы данных всегда первичен, а потом уже идут всякие beans, ado.net и всякие другие приблуды - и именно они IMHO должны подстраиваться под базу а не наоборот. Когда делается наоборот в 80% случаев проект через некоторое время имеет бледный вид.

И причина этому на мой взгляд такова что именно база обычно является узким местом в смысле производительности.
Поэтому дизайн делается не так как удобнее програмить а так как быстрее будет работать

Не только - просто на уровне базы данных намного проще/удобнее контролировать различные business rules и целостность/непротиворечивость данных. Быстрота как раз вторична. Особенно если вы работали в банке где баланс сводится в on-line в любой момент времени из 12 филиалов и 250 удаленных точек обслуживания - а в течение ночи накладываются десятки тысяч транзакций из терминально-банкоматной сети и Eurocard/Visa. И не дай Бог где-то какой-то rule неправильно отработает. :nono#:

Dmitry67 · Post by **Dmitry67** » 09 Mar 2004 23:58

Я кстати интересный фефект наблюдаю
Коллеги, умные люди, пшут в основном на шарпе
Иногда имнадо написаь upgrade script для базы в связи с изменением модели

Ну например, надо заменить какието значения на другие
В духе

update TAB set COL=someexpr WHERE filter

90% это путтак
Организуют цикл по TAB с declare cursor, fetch, проверкой fetch_status
В цикле делают update. Иногда даже filter загоняют в if проверку внутри цикла

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

Sabina · Post by **Sabina** » 10 Mar 2004 00:43

Dmitry67 wrote:Я заменяю на одну строку, все говорят как круто, и... в следующий раз все равно пишут цикл

А update script вы своей волшебной программой генерируете?

Сабина

OBender · Post by **OBender** » 10 Mar 2004 02:52

Добавлю свои 2 цента.

Если речь идет о нескольких таблицах то я бы не стал применять Entity Beans вообще. По скольку как правило выбор здесь идет в пользу BMP и даже если вы сделаете view в базе данных и будете использовать EJB QL для CMP я не думаю что это сильно поможeт. Особенно если выборки данных/количество создаваимых бинов большое.
Лучше использовать JDO или TopLink. Возможно это во мне просто говорит противник Entity Beans

OBender · Post by **OBender** » 10 Mar 2004 02:55

JustMax wrote:Не только - просто на уровне базы данных намного проще/удобнее контролировать различные business rules ...

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

OBender · Post by **OBender** » 10 Mar 2004 02:59

Sabina wrote:Скажем есть у меня JSP, которая при вызове User Profile формы идет в базу и если там уже есть информация, то она заполняет форму.

Допустим какие-то значения не заданы (nulls).
...
А как в real life appplication это чаще всего делается?

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

JustMax · Post by **JustMax** » 10 Mar 2004 09:57

OBender wrote:Вообще то бизнес логике не место в базе данных в случае если эта база используется только J2EE приложением.

Vot, vot kliuchevaja fraza - esli TOL'KO. Vremia ot vremeni 100% baza budet redaktirovatsia vruchnuju. Eto dazhe ne obsuzhdaetsia - eto aksioma, pritom horosho esli eto budet kvalificirovannyj admin, a esli net

.... Ja predpochitaju perebdet' chem nedobdet'. Dazhe esli mnogie iz biznes rules dublirujutsia na urovne bazy dannyh. Dvojnoj kontrol' esio nikomu ne meshal, i v pervuju ochered' samim zhe razrabotchikam.

cityzen · Post by **cityzen** » 10 Mar 2004 12:32

OBender wrote:
Sabina wrote:Скажем есть у меня JSP, которая при вызове User Profile формы идет в базу и если там уже есть информация, то она заполняет форму.

Допустим какие-то значения не заданы (nulls).
...
А как в real life appplication это чаще всего делается?

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

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

Dmitry67 · Post by **Dmitry67** » 10 Mar 2004 13:43

Sabina, не всегда, зависит от скрипта

Что касается проверки бизнес правил на клиенте то в 90% случаев )то просто дырка, которая правда срабатывает довольно редко
Потому что правильно проверить бизнес правило на клиенте необъодимо очень четко разбираться в isolation leveles и на нужные документы класть блокировки. Причем для Oracle и MS SQL код будет совершенно разный
Иначе изза racing conditions проверка правила не сработает или сработает не правильно. Сбой такой проверки лишь вопрос вероятности неудачного стечения событий

Когда же код эти проверки делает через всякие абстрактные слои то вообще мрак...

OBender · Post by **OBender** » 10 Mar 2004 14:44

Может я чего то не понимаю но похоже у меня представление о бизнес логике несколько отличается от здесь присутствующих.
В моем понимании это вещи типа balance > XXX and account_no == YYY
ну и т.д.

И мое глубокое убеждение что это не должно отдаваться в БД. Потом, чем дальше вы отпускаете валидацию данных тем дольше клиент будет ждать что бы просто получить сообщенее что нужно ввести все сначала.

Кстати это не просто мое мненее, это весьма стандартный и много раз описаный подход в мире J2EE :mrgreen:

Dmitry67 · Post by **Dmitry67** » 10 Mar 2004 14:59

OBender wrote:Может я чего то не понимаю но похоже у меня представление о бизнес логике несколько отличается от здесь присутствующих.
В моем понимании это вещи типа balance > XXX and account_no == YYY
ну и т.д.

Как правило balance>XXX где XXX - установленное значение (зранящееся в какой то таблице) или результат маленькой квери

Например, СуммаПлатежкиКоторуюВыМожетеВыписать < ОстатокНеизрасходованныхСредствВашегоОтдела

Правая часть этого неравенства может изменится за время редактирования
Проверять на клиенте это НЕПРАВИЛЬНО
(хотя и возможно, другое дело что ФИНАЛЬНАЯ проверка все равно должна быть не сервере)

OBender · Post by **OBender** » 10 Mar 2004 15:11

Ну не стоит цепляться к словам

на клиенте есть масса информации которую можно проверить, например пустые или недопустимые значения.

Но по прежнему все проверки, я считаю, должны делаться чем раньше (возможнее) тем лучше и в J2EE приложении самое позднее это Session Bean перед обращением к DataAccess layer.

Dmitry67 · Post by **Dmitry67** » 10 Mar 2004 15:46

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

OBender · Post by **OBender** » 10 Mar 2004 16:10

Ну да на сервере конечно, на апликейшен сервере :mrgreen:

Dmitry67 · Post by **Dmitry67** » 10 Mar 2004 16:21

Если на app server, то вы там все чяетко расставляете блокировки чтобы не попасться на racing conditions ? Как правильно расставлять все hints на блокировки через средства абстракции ?

Post by **Flying Hen** » 10 Mar 2004 17:27

А по-моему вы упускаете из виду понятие транзакции. Если транзакция спланирована правильно, то какая разница, исполняется она на сервере или клиенте? А если нет, то неприятности гарантированы опять же, независимо от того, где происходит исполнение.

testuser · Post by **testuser** » 10 Mar 2004 17:41

Dmitry67 wrote:update TAB set COL=someexpr WHERE filter

90% это путтак
Организуют цикл по TAB с declare cursor, fetch, проверкой fetch_status
В цикле делают update. Иногда даже filter загоняют в if проверку внутри цикла

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

Цикл универсальней - можно делать сложную обработку. Т.к. это одноразовая штука, производительность особого значения не имеет.
Мне, помнится даже рекомендовали такой метод, особенно при удалениях (так еще можно лог вести для себя, чего нельзя сделать при апдейте). Если лог есть, потом можно все назад вернуть, без откатов базы.

В общем, администрирование и программирование это разные вещи :umnik1:

testuser · Post by **testuser** » 10 Mar 2004 17:56

Dmitry67 wrote:Если на app server, то вы там все чяетко расставляете блокировки чтобы не попасться на racing conditions ? Как правильно расставлять все hints на блокировки через средства абстракции ?

Блокировки расставляет app server. Правила можно задать в bean descriptor (это для CMT).