for read only views of a data base, you should consider using session beans with
explicit SQL (same security checking but less cache overhead).
Entity beans should be used mostly for updating persistent data.
-----Original Message-----
From: Alain Rogister [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 29, 1999 8:25 AM
To: [EMAIL PROTECTED]
Subject: Entity beans and RDBMS views
Hi,
Has anyone experimented with the idea of mapping entity beans with RDBMS
views ?
Imagine that you want to produce summary reports about the contents of
several large database tables. You'd like to do this through entity
beans for a number of good reasons like making security checks at the
entity level and adding some business logic. But if you end up coding
complex in-memory navigations between entity instances, it's easy to
imagine horror scenarios involving massively inefficient use of the
RDBMS.
What about defining a number of (materialized ?) views that would let
the RDBMS take care of the query processing ? Instead of coding complex
navigations, you'd create "aggregate" entity beans mapped against
summary views. Did anyone try this ? I'm thinking mostly of read-only
views, but updatable views would also be interesting in some scenarios.
Alain.
--
Alain Rogister
Ubiquity s.a.
http://www.ubiquity.be
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
