> -----Original Message-----
> From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
> > 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.
>
Yup, depends on the problem domain and the number of users actively using
the system (.e.g., even a news system may track user behavior which in a
successful internet site is millions of requests a day). On the internet I
tend to think in terms of futures and growth (plan for success).
> 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.
>
btw, I am not arguing that everyone write database code--Just that CMP is
isn't an end all.
> 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 agree.
> 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.
>
Hmm. I like to think that DBA's help flush out a better object model. ;->
> > 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 :-)
>
We gave up on CMP at least for now and wrote a tool to generate our BMP
entities and schema from Rational Rose models. We also have generated
utilities to circumvent entities and go direct--As we suffer we adapt. ;->
> 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.
>
Sorry if I put words in your mouth. ;-> I do admit we are talking about
mixing CMP and BMP where it makes sense. We are all banking on a healthy
specification and market where ejb vendors will make our life easier.
Scaling is all about good design and I just need tools which are developed
by folks who understand this...it is not merely stateless versus stateful
design.
-phil ([EMAIL PROTECTED])
Phillip A. Lindsay
eBuilt, Inc. - http://www.ebuilt.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".
