For a new project without existing RDBMS (or at least parts of the data
stores are new), it will be better if the project design starts with the
object model reflecting the bussiness system closely. It seems to me that
laying out the structure of RDBMS first and then generate BMP Beans is not a
good way for new projects.
Richard correctly pointed out that currently available reporting systems
need to be configured against the RDBMS so these reporting systems will work
better with a normalized RDBMS. That is one of the problems we attempt to
solve by making a reporting system that will work against the object model
inside application servers directly, without requiring developers or users
ever thinking about the schema of the RDBMS (or other types of data stores).
<vendor>
Anyone interested in enterprise reporting or OLAP systems working directly
against EJB servers are welcome to take a look at our web site
http://www.sightsoftware.com/
The product is still in development stage. Any comments, suggestions, or
feature requests will be greatly appreciated.
</vendor>
Chia-ming Hsu
Sight Software, Inc.
[EMAIL PROTECTED]
www.sightsoftware.com
-----Original Message-----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, September 30, 1999 5:48 AM
Subject: Re: Standard CMP: Dear App Server Vendors and EJB Spec authors
>Evan Ireland wrote:
>
>> Among our customers, I see two distinct requirements for CMP.
>>
>> (1) CMP where the customer wants persistent objects, and couldn't care at
all
>> where or how their data is stored. (The spec allows Java
Serialization to
>> be used in this case).
>>
>> (2) CMP where the bean's persistence must map to database schemas that
already
>> exist or are created by the customer (in the RDBMS case, they may
sometimes
>> want to be able to use SQL to access their data).
>>
>> Where the customer wants the latter, I believe that tools that generate
BMP
>> code are an essential part of the equation, since no matter how 'clever'
a CMP
>> code generator is, it might not be adequate to meet the customer's
requirements,
>> so generating BMP code that the user can then modify is very useful.
>
>This is very true. BMP provides much more flexibility if the persistent
store
>already has an existing structure and data. This seems to be the case in
many
>projects. Actually I would say that even green field projects benefit more
from BMP
>with RDBMS are used then CMP because the RDB can be normalized and therefor
better
>able to accommodate other systems and tools (like reporting systems and
data ware
>housing tools). This is why I like products like CocoBase, which generates
BMP
>entities for RDBMS but keeps the code portable. If you can alter the beans
after
>they are generated its even better because you can introduce more complex
behavior
>that the OR tool may not have been able to generate.
>
>--
>Richard Monson-Haefel
>Author of Enterprise JavaBeans
>Published by O'Reilly & Associates
>( http://www.monson-haefel.com )
>
>===========================================================================
>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".
