 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2006Need Relational Database Capabilties in Java
We are looking at converting some legacy apps o Java. The apps were originally in a relational database software program. we want to keep the data structures if possible. Is there a way to do this? We don't mind converting the structures int a new data container or file system. However we would like to keep the same fields, records, tables, etc. Is there anyway to do this? And what would be the Java tools, software, etc, that we would need? Thanks Best regards, JAF http://www.bscinc.net http://www.affordablefloridainsurance.com http://www.discountdrivingschool.com > We are looking at converting some legacy apps o Java. The apps were > originally in a relational database software program. we want to keep > the data structures if possible. Do you mean data *and* logic were in the DB (i.e. stored procedures)? Or do you mean to say only data is in the DB? > Is there a way to do this? > [quoted text clipped - 4 lines] > Is there anyway to do this? And what would be the Java tools, > software, etc, that we would need? You can access a relational DB from Java via JDBC (and other tools that do more abstraction, like object relational mapping tools such as Hibernate). And with some DB products you can also implement logic inside the DB in Java (Oracle for example). Kind regards robert snip >Do you mean data *and* logic were in the DB (i.e. stored procedures)? >Or do you mean to say only data is in the DB? Our legacy system only stored data in the DB. All procedures and processes were in he code. They were very "modularized" though, and we could use them in input routines and reports without any trouble. The two biggest pluses I see to the relational model for DB, and please comment on my ideas here for Java since I am new to Java, are the data is easy to maintain and it is easy to train end users to understand relational data and to do heir own reports. By maintain I don't mean the day to day input but rather the data schema over time. We have had several times when we needed to add serious new functionality to the system, and by adding a few fields and a few new reports, we were able to do it without any serious reprogramming of the scheme or the code. Can we do this in Java? Best regards, JAF http://www.bscinc.net http://www.affordablefloridainsurance.com http://www.discountdrivingschool.com > snip >> Do you mean data *and* logic were in the DB (i.e. stored procedures)? [quoted text clipped - 17 lines] > > Can we do this in Java? You can execute any DML and DDL commands via JDBC. robert > The two biggest pluses I see to the relational model for DB, and > please comment on my ideas here for Java since I am new to Java, are > the data is easy to maintain and it is easy to train end users to > understand relational data and to do heir own reports. If you want to interact with the DBMS at the level of SQL queries, tables, rows, and so on, then that is provided by JDBC. There's a tendency in the Java world to /assume/ that anyone interacting with a DBMS will want to use a Object-Relational mapping tool (such as Hibernate) to handle the translation from the world of relational data into the world of objects, but that assumption is not necessarily valid. The data can perfectly well be represented (in Java) as objects from the relational domain (rows, etc) rather than being automatically transcribed into objects from the target domain (customers, etc). And if you are already happy working with those concepts, then I don't (myself) see much benefit in changing. -- chris > There's a tendency in the Java world to /assume/ that anyone interacting with a > DBMS will want to use a Object-Relational mapping tool (such as Hibernate) to [quoted text clipped - 6 lines] > > -- chris Actually, its a tendency of Object Oriented Programmers world to assume that anyone interacting with data at all, regardless of its source. Object Oriented Design allows you to have a rich domain model. The domain model will know how to manipulate and present itself (to a point), in such a way that it reduces complexity of code. If you are moving to Java JUST to move to Java, then I suggest you reconsider. If you are moving to Java so that you can become a (true) OO shop, then I suggest you think of ways to utilize your data in a more OO fashion. > Actually, its a tendency of Object Oriented Programmers world to assume > that anyone interacting with data at all, regardless of its source. Parse error: no apparent main verb. Syntactic analysis terminated.  Signaturesimon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/ ;; I put the 'sexy' in 'dyslexia' >> The two biggest pluses I see to the relational model for DB, and >> please comment on my ideas here for Java since I am new to Java, are [quoted text clipped - 14 lines] > (customers, etc). And if you are already happy working with those > concepts, then I don't (myself) see much benefit in changing. Further to that, the various object-relational mapping frameworks are all fairly heavyweight and add greatly to the complexity and computational expense of your software. They are great sledgehammers, but if what you've got is a nut they are cumbersome and dangerous. Signaturesimon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/ IMHO, there aren't enough committed Christians, but that's care in the community for you. -- Ben Evans > We are looking at converting some legacy apps o Java. The apps were > originally in a relational database software program. we want to keep [quoted text clipped - 16 lines] > http://www.affordablefloridainsurance.com > http://www.discountdrivingschool.com Have you looked at using something like Apache Derby to integrate into your Java application? There's a review of it here: http://www.techbookreport.com/tbr0275.html More details at the Apache Derby page: http://db.apache.org/derby/ HTH SignatureTechBookReport Java http://www.techbookreport.com/JavaIndex.html > Have you looked at using something like Apache Derby to integrate into > your Java application? There's a review of it here: > http://www.techbookreport.com/tbr0275.html > > More details at the Apache Derby page: http://db.apache.org/derby/ At the risk of inducing topic drift what are the pros and cons (in the context of your choice ;-) with hsqldb? http://www.hsqldb.org/ We use hsqldb, because in its ram resident incarnation we can create a schema, populate it with a small amount of test data, run a test, and demolish everything in milliseconds, which is just F**kin' superb for unit testing. In this way unit tests are genuinely independent, whereas when testing against "real" DB's one failed test can cause enough corruption/damage to make other tests fail - the tests aren't independent. BugBear >> Have you looked at using something like Apache Derby to integrate into >> your Java application? There's a review of it here: [quoted text clipped - 19 lines] > > BugBear Not tried HSQLDB, but on paper at least the functionality is fairly similar to Derby. I did see some benchmarks recently that did put HSQLDB ahead in terms of speed, so perhaps next time the need comes up I'll give it a go. SignatureTechBookReport Java http://www.techbookreport.com/JavaIndex.html > Not tried HSQLDB, but on paper at least the functionality is fairly > similar to Derby. I did see some benchmarks recently that did put HSQLDB > ahead in terms of speed, so perhaps next time the need comes up I'll > give it a go. There were some benchmarks that made HSQL appear very fast. They just used the defaults. HSQL defaults to in memory storage, so it is in no way comparing like with like. Sometime ago I had a brief look at the HSQL implementation. All commands ran under "synchronized (database)". That is just mickey mouse. I believe Derby has an option for 'transient' databases that don't sync to non-volatile storage. That could make things much faster. It looks as if an in-memory database feature is going to be added soon. Tom Hawtin >> Not tried HSQLDB, but on paper at least the functionality is fairly >> similar to Derby. I did see some benchmarks recently that did put [quoted text clipped - 6 lines] > HSQL implementation. All commands ran under "synchronized (database)". > That is just mickey mouse. For a lot of our unit testing HSQLDB is a good enough database (we normally have TINY amount of test data), and it's very high boot/create schema performance is a godsend. For component level testing we work differently. Horses for courses, no silver bullet etc. BugBear > We are looking at converting some legacy apps o Java. The apps were > originally in a relational database software program. we want to keep [quoted text clipped - 5 lines] > file system. However we would like to keep the same fields, records, > tables, etc. If you want a relational database within the Java process, there is Derby. It's under the Apache license, so no worries about your own intellectual property. Originally it was a commercial product called Cloudscape written in the late nineties, then bought by Informix, who were themselves bought by IBM. So it's not just some cobbled-together half-implemented junk. Then you may well want some form of Object Relational Mapping (ORM) tool. Hibernate has been the traditional choice. The persistence part of EJB3 is the knew kid on the block (not to be confused with bad old EJB). You may also here of JDO, which just wont die. Tom Hawtin Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.