| > | > The issue of ORDER BY raises some interesting issues in this regard: | > | > | > | > Is the semantics of ordering defined by the database semantics (e.g. | > | > SQL semantics) or by Java semantics? While maintaining Java semantics | > | > would seem desirable, it means that we cannot generally push the | > | > ordering down into the database, | > | > Not pushing it to the database will give horrible performance. | | Why? The container might cache the resulting set after sorting it, | and hence give much better performances for subsequent calls. Also, | the results are already mapped to Java objects, hence another gain. For result sets whose data is static over the span of an application "day" (States in the U.S. for example), or for simple lookup by primary key, you will gain something from the cached representation in the middle tier. However, as soon as you begin to build a real application that needs complex WHERE clause evaluation where the criteria are changing by user and have to deal with the inevitable fact that other applications besides your EJB client will be modifying those same tables, then for the EJB container to really add value here, it needs to become a full-fledged database to really unload the work off the back-end database of evaluating arbitrary queries (not just equality matches against key values). I doubt this is where middle-tier app servers are going, since the back-end databases already do an excellent job at this. | There is no absolute answer here, it depends on your application, the typing | system that you want to be used when you sort, the quality of your database | and/of your EJB container, etc... Regardless of the quality of your EJB container, it will be a long time before any middle-tier application server can deliver the performance of today's relational databases for querying enterprise data. I don't mean only Oracle here, I'm talking about any of the "major" relational databases. | > This might be a naive-sounding question, but is there any way | > in EJB 2.0 to allow developers to directly use the SQL language | > that many are already familiar with? | | I am assuming you mean "SQL instead of EJB-QL", because otherwise | the answer to your question would be BMP. Yes, I mean the ability to allow developers to use SQL if they want to use SQL, instead of EJB-QL. People needing good database performance will either trust their EJB container to rewrite EJB/QL into well-performing SQL statements, or they will go with a BMP approach and make *sure* the statements perform by having fine control over exactly what SQL gets executed, which indexes it will use, etc. Time will tell which approach pans out better in terms of application performance. | > EJB 2.0 needs an ability to use the full power of SQL, | > not just EJBQL. | | In a majority of cases, this will simply not make sense. | Eventually, you need to map the SQL results back into an abstract | schema (or in other words, into a world of Java objects). Again, if the majority of the cases are looking up all attributes of an object by primary key, or doing simple equality predicates, then you are right. But most apps I've consulted on, like the 40-50 huge applications suites built by the Oracle Applications teams, need the ability to work with the full power of SQL and the ability to automatically tie that back into their entities. They want the best of both worlds. Full power of SQL, full encapsulation of business logic. | I agree that the existence of both SQL and EJB-QL is regrettable, | but it cannot be addressed differently as of today. But the | situation might look less grim to you if you think of a possible | future where a bunch of new query languages have been invented | besides SQL and OQL, and where the good news is: you don't need to | learn them, just keep programming in EJB-QL and the container will | generate the code for you. This seems like a doomsday scenario for developers. Every time I've worked on a project that tried to treat the database as a black box, putting blind faith into a magic conversion layer to convert from a "query in terms of objects" into a query in terms of tables, the performance has just never been able to match the hand-tuned SQL, understandably. Perhaps vendors will convince developers that EJB/QL is finally that magic layer that gets this right. Many simple queries on primary key attributes probably *can* be straightforwardly translated to SQL. My gut tells me that developers will believe the data sheets, and then find out when they start building andn deploying applications against production data that it just doesn't quite work like they thought, performance-wise. ______________________________________________________________ Steve Muench, Lead XML Evangelist & Consulting Product Manager BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG Author "Building Oracle XML Applications", O'Reilly http://www.oreilly.com/catalog/orxmlapp/ =========================================================================== 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".
