Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Pitch on 27 Apr 2010 04:48 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. -- stirr your cofee properly
From: Pitch on 27 Apr 2010 04:54 In article <hr3r1v$bvp$2(a)news.albasani.net>, noone(a)lewscanon.com says... > > junw2000(a)gmail.com says... > >> When I work on database development projects, I use JDBC and SQL. Many > >> people use hibernate/spring. Can somebody explain the pros and cons of > >> using JDBC and SQL vs using hibernate/spring on database > >> developments? > > Pitch wrote: > > I always believed that ORM systems are forcing you to write your own > > business-rules layer apart from the persistence layer. That way database > > access is kept simple and easy mantainable. > > ORM doesn't force business rules into a separate layer and raw JDBC calls > don't force them into the same layer as persistence. I disagree. -- stirr your cofee properly
From: Lew on 27 Apr 2010 06:41 Pitch wrote: > In article <hr3r1v$bvp$2(a)news.albasani.net>, noone(a)lewscanon.com says... >> junw2000(a)gmail.com says... >>>> When I work on database development projects, I use JDBC and SQL. Many >>>> people use hibernate/spring. Can somebody explain the pros and cons of >>>> using JDBC and SQL vs using hibernate/spring on database >>>> developments? >> Pitch wrote: >>> I always believed that ORM systems are forcing you to write your own >>> business-rules layer apart from the persistence layer. That way database >>> access is kept simple and easy mantainable. >> ORM doesn't force business rules into a separate layer and raw JDBC calls >> don't force them into the same layer as persistence. > > I disagree. The evidence speaks for itself. -- Lew
From: Robert Klemme on 27 Apr 2010 12:06 On 27 Apr., 02:31, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > On 26-04-2010 16:14, Robert Klemme wrote: > > > > > On 04/26/2010 02:14 AM, Arne Vajhøj wrote: > > >> I don't think the big benefits of ORM (Hibernate or JPA or one of the > >> alternatives) are in the writing of the code. It still requires > >> somebody that knows both the ORM framework and the database well > >> to write really efficient code. > > >> The big benefits are for reading the code. Everyone can read the > >> the code using ORM and immediately understand what it does without > >> looking at tons of code that uses JDBC and SQL. It is maintenance > >> friendly. > > > So you are saying that I need skilled people to write the initial code > > and can give maintenance to less skilled people because the ORM using > > code is easy to read? I am not sure that is a good strategy. Over time > > software tends to decay because more and more bug fixes are applied and > > features added. If only the people knew internals of ORM that wrote the > > initial code I see a good chance that maintainers wreck havoc on the > > performance and potentially the whole application if they change / > > extend the easy readable code without knowing the tool they are using. > > Even a change as seemingly simple as that of a field type from "int" to > > "String" might have dramatic consequences. And just think of the woes of > > schema migration: if you have an installed base you urgently need > > someone who understands the DB underneath and the ORM tool to come up > > with a feasible migration strategy that. > > Not quite. I am saying that you may want people that have a clue > about persistence to write and modify the persistence code, but > that developers that does not know about the used ORM framework > or the database will be able to easily read and understand the code > (while working on something else - like the business logic). Thank you for the clarification! > > 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. :-) In any case I believe the complicated stuff is where the fun begins - so for _me_ DB independence is definitively a myth. ;-) Kind regards robert
From: Tom Anderson on 27 Apr 2010 14:48
On Tue, 27 Apr 2010, Graham Cox wrote: > Lew <lew(a)lewscanon.com> writes: > >> What you wrote looks correct, but I am fairly certain it requires >> 'keywords' to be expressed as a collection (probably a 'Set'), which >> is best done if the keywords are in their own table, which they should >> be anyway. I don't think it works with the space-separated list of >> keywords as in your first of three examples. > > Arguably the keywords should actually be in a full text index in the > RDBMS, and let the proper full text indexing support handle it > instead. That will be more efficient than scanning a table of keywords > joined back to the table of documents Maybe, maybe not: http://www.pui.ch/phred/archives/2005/06/tagsystems-performance-tests.html Depends on the data. > On the other hand, I've no idea if JPA supports full text indexes and if > it does how you'd go about using them... JPA itself doesn't, AFAIK. However, you can take a JPA-mapped database, add a fulltext index on the side, and then access it using native queries. It's a leak in the abstraction, and a point of nonportability, but it's easily confined to the data access layer, and probably not too big a deal in practice. There are also fulltext search options for JPA that don't use the database's own indexing - notably Compass, which indexes a JPA repository with Lucene: http://www.compass-project.org/overview.html Hibernate also has Hibernate Search, which does much the same thing. I understand that its existence is pushing towards the next major version of JPA including fulltext search. Whether there will be implementations on top of database fulltext search as well as Lucene and similar, i don't know. tom -- Get my pies out of the oven! |