Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Arne Vajhøj on 26 Apr 2010 20:21 On 26-04-2010 16:31, Robert Klemme wrote: > Exactly. I believe there is a fundamental dilemma that I haven't seen a > satisfying solution to: with a relational database and an object > oriented (or not) application which implements the business logic you > automatically have a distribution of business rules between several tiers. > > If you manage to place all business consistency rules into the database > (which is often impossible because either of limitations of the DB or > complexity of the model) you leave very little for the application layer > (mostly presentation) so you might wonder why not directly implement all > the business logic in PL/SQL or T-SQL (just to name two well known > brands). Advantage is that you cannot break the model if you need to do > changes in the DB (this can happen for migration, repair or other one > off tasks). > > If you place all the rules in the application consequently you would > have to even get rid of foreign keys. Downside is of course that you now > have zero consistency enforcement for the data model in the DB (e.g. > during all those tasks mentioned above) and you are only using 10% of a > potentially expensive installation (in the case of a commercial RDBMS). > > In reality I have often seen a mix between the two approaches: some > consistency checking (FK, PK, CHECK constraints, triggers) is done in > the database and the "rest" of the business logic lives in the > application tier. This may actually be the worst approach: it's not only > that you don't have a single place where the business model is > consistently defined and enforced - that is merely a violation of some > form of purity rule (which _does_ have its advantages). But this might > also make people feel safe when they change the database while breaking > business rules that live elsewhere... That is a classic dilemma. 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 - I would keep basic integrity check in the database though. Arne
From: Arne Vajhøj on 26 Apr 2010 20:24 On 25-04-2010 22:57, Jack wrote: > On Apr 25, 9:58 am, Arne Vajh�j<a...(a)vajhoej.dk> wrote: >> On 25-04-2010 12:44, Zlatko Duric wrote: >>> On 04/25/2010 06:14 PM, Tom Anderson wrote: >>>> And as Arne said, when you're trying to do something unusual, you may be >>>> outside the limits of what ORM can comfortably do, and you'll be better >>>> off using straight JDBC. Or perhaps a combination of ORM for any CRUDdy >>>> / domain logicky bits, and JDBC for complex queries. >> >>> I inherited something that uses Hibernate, and I'm thinking about >>> speeding up a few things. I was just thinking about how it would be >>> difficult to try to speed all the slow stuff up by replacing all the >>> hibernate stuff with all JDBC queries, and with my experience there's no >>> chance I'll be doing this. But this approach (combination of ORM and >>> JDBC) sounds very interesting to me. >> >>> Now, my data is all objects - that suits me perfectly. But there is some >>> information about all those objects I'd like to store in a single table >>> or maybe two of them, that'd be super-fast to reach, without having to >>> look for all those parent/children/node/parameters/other links and >>> without having other issues to think about. I believe that part of the >>> features would benefit from it a lot in terms of performance. >> >>> Now, how common is this approach (combination)? Is there something >>> really important I should read about this, before starting with the >>> implementation? >> >> If you are accessing the data as objects, then I don't think >> that switching from Hibernate to raw JDBC is the right direction >> to optimize the code. >> >> Instead you should focus on tuning Hibernate and the databases >> itself. >> >> Hibernate can be slow and Hibernate can be fast. It all depends >> on the guy writing the code. > > To use JDBC and SQL, I need to handle trial things, like commit, > rollback etc. How about hibernate/spring? You still need to handle your own transactions. That is a very common feature of persistence frameworks - they don't try to guess how you want your transactions. Arne
From: Arne Vajhøj on 26 Apr 2010 20:31 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). > 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. Arne
From: Graham Cox on 27 Apr 2010 04:47 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, and - potentially - gives support for near matches as well... 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... -- Graham Cox
From: Pitch on 27 Apr 2010 04:45
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? -- stirr your cofee properly |