> With the right people you can get time to market with scalability, but it
> is naive to think that scalability comes without some rubber meeting the
> road. For example, I don't think a platform where a database is
> constrained by 32bit addressing is scalable. In other words, leveraging
> 8GB, 16GB, etc. memory spaces requires some work in coupling to a specific
> database platform (i.e., leverage platform features).
It really depends on the requirements. Some systems have very heavy
loads but very small databases. Look at online news, they don't have
that much information on a daily basis (the most accessible) to even
justify 1GB memory space. Their archives are huge, but they don't have
to scale.
I've worked on two applications that were just complex schemas and
highly tuned queries (update was rather rare). The complex stuff was
OLAP, fine tuned queries, fetch blocks, cursors, any trick to get them
working better. The simple stuff, which happened to be 80% of the forms
was brain-dead mapping that any CMP tool can do just as efficiently.
Your milage may vary, but as long as you understand when and when not to
use it, it's just another tool in the box.
> I see CMP today valuable in rapid prototyping. I don't think you want your
> normalized schema coming from data modeling (data view), but rather I think
> an initial normalized schema falls out of a good object model (behavioral
> view).
My schema is actually coming from the Java object model. But in the
design phase there is a back-and-forth interaction between the more
flexible process side (Java object model) and the very strict relational
side (SQL). At the end of the day your Java object model borrows a lot
from the relational model, or you get too much friction.
> Leverage things like SPROCs to hide RDBMS details from entities. If a DBA
> decides to toss a view in or update two tables for a single entity
> creation...so be it, try and reduce the impact of these changes in the
> entity beans.
No problem. You narrow down a SELECT/INSERT/UPDATE operation to
something so simple even CMP can deal with that :-)
> I would argue that a tool can't magically solve the scaling issues of
> dealing with database technology. So pure automated mapping is a concern in
> larger systems (unless there is a well defined and easy way for DBA types to
> circumvent the tool without impacting the software).
Never said a tool can magically solve any scaling issues. In fact I
don't see Entity beans as a scaling solution to begin with. I said
upfront, you want it to scale go the stateless way. You want to invest
less in development, go the entity way. The question is, what is the
proper mix of BMP and CMP.
> I guess, I don't see CMP being "smart" enough. Having lived the large scale
> production world with oracle, Sybase, etc....I know it requires in depth
> "human" experts to constantly troubleshoot, tune and optimize a large scale
> DBMS.
CMP is smart enough when the problem is simple enough. In many cases
(not all) the SQL operations they perform are equivalent to the SQL
operations BMP would perform. In some cases, BMP has that room for fine
tuning which CMP lacks. In the applications I've seen that was pretty
much the 80/20 rule. 80% of the stuff could be CMP, 20% of the stuff
should be BMP. But we got better result by doing 100% of the stuff
stateless.
arkin
>
> -phil ([EMAIL PROTECTED])
> Phillip A. Lindsay
> eBuilt, Inc. - http://www.ebuilt.com
> [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".
