Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Arne Vajhøj on 27 Apr 2010 21:33 On 27-04-2010 04:45, Pitch wrote: > In article<4bd62dfc$0$286$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk > says... >> My preference is: if database need to be accessed by apps in different >> technology, > > If you use ORM you don't want this, so it's not relevant. Right? In the unlikely case that it is a decision that can be made, then it is still a restriction and therefore relevant. In the more likely case that it is a given, then it is obviously relevant. Arne
From: Arne Vajhøj on 27 Apr 2010 21:37 On 27-04-2010 15:10, Tom Anderson wrote: > On Mon, 26 Apr 2010, Arne Vajh?j wrote: > >> My preference is: if database need to be accessed by apps in different >> technology, then it makes sense to put the business logic in SP's - >> otherwise I would keep the business logic in the Java code, because >> that makes it a lot cheaper to work with a different database - > > It's worth mentioning that the modern alternative approach here is to > put hide the database completely behind the java, and expose the > functionality through web services. Rather than having other apps talk > to the database directly, they make calls to the java layer. That lets > you raise the level of abstraction in the other apps, reuse > functionality in the java, and maintain the invariants enforced by the > business logic in the java. Modern alternative???? I thought it was a classic anti-pattern to expose DAL as services instead of BLL as services. After all - this is entity beans remote interface just with a 10 times more inefficient transport format. Arne
From: Arne Vajhøj on 27 Apr 2010 21:38 On 27-04-2010 04:48, Pitch wrote: > In article<83mbghFjnU1(a)mid.individual.net>, shortcutter(a)googlemail.com > says... >>>> Also, this multi-tier architecture allows for easier load-balancing, >>>> architecture changes, integration with other systems, development.. >> >> Pitch, you can have multi tier with JDBC and ORM - you can even have >> multi tier without persistence altogether. > > Yes, but I sad _this_ multi-tier architecture. If you use only JDBC you > have one tier less. No. You have the same tiers with ORM and JDBC and in 99% of cases the same layers as well. Arne
From: Arne Vajhøj on 27 Apr 2010 21:43 On 27-04-2010 12:06, Robert Klemme wrote: > On 27 Apr., 02:31, Arne Vajh�j<a...(a)vajhoej.dk> wrote: >> On 26-04-2010 16:14, Robert Klemme wrote: >>> Btw, did I mention that I believe database independence is a myth? :-) >> >> It is a myth that is seen working everyday in the Java world, that >> many Java apps using a good ORM (like Hibernate or one >> of the JPA implementation) use the same Java code with different >> databases. It is not always that easy. But for all the simple >> stuff it works well. > > Hm... The question is: how simple is "simple" and where does > "complicated" begin? Just an example, which I would rather place in > the "simple" bucket: assume you want to query for items that have a > field set to null. Considering that Oracle does not index NULL values > and another RDBMS that you want to use does so, you'll likely end up > with a clutch: either you use a different value for NULL which will > allow for uniform ORM code at the cost of a bad design; or you need to > make the ORM tool create different queries (and I do not mean the > difference between "VARCHAR2" and "VARCHAR") for Oracle and the other > RDBMS. You could, of course, also live with the FTS in Oracle but I > doubt you'll have much fun doing this on any reasonably large > database. :-) How does you solve it by using JDBC? > In any case I believe the complicated stuff is where the fun begins - > so for _me_ DB independence is definitively a myth. ;-) Well - out goal is to make everything as simple as possible. Arne
From: Robert Klemme on 28 Apr 2010 03:30
On 28 Apr., 03:43, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > On 27-04-2010 12:06, Robert Klemme wrote: > > > > > On 27 Apr., 02:31, Arne Vajhøj<a...(a)vajhoej.dk> wrote: > >> On 26-04-2010 16:14, Robert Klemme wrote: > >>> Btw, did I mention that I believe database independence is a myth? :-) > > >> It is a myth that is seen working everyday in the Java world, that > >> many Java apps using a good ORM (like Hibernate or one > >> of the JPA implementation) use the same Java code with different > >> databases. It is not always that easy. But for all the simple > >> stuff it works well. > > > Hm... The question is: how simple is "simple" and where does > > "complicated" begin? Just an example, which I would rather place in > > the "simple" bucket: assume you want to query for items that have a > > field set to null. Considering that Oracle does not index NULL values > > and another RDBMS that you want to use does so, you'll likely end up > > with a clutch: either you use a different value for NULL which will > > allow for uniform ORM code at the cost of a bad design; or you need to > > make the ORM tool create different queries (and I do not mean the > > difference between "VARCHAR2" and "VARCHAR") for Oracle and the other > > RDBMS. You could, of course, also live with the FTS in Oracle but I > > doubt you'll have much fun doing this on any reasonably large > > database. :-) > > How does you solve it by using JDBC? Well, you would either wrap the query in a stored procedure or use custom SQL per database engine type. For example, with Oracle you could create a FBI and query with its functional expression. > > In any case I believe the complicated stuff is where the fun begins - > > so for _me_ DB independence is definitively a myth. ;-) > > Well - out goal is to make everything as simple as possible. .... but not simpler. :-) Cheers robert |