GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes What is the best approach for an application managing multiple persons and data related to them? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "What is the best approach for an application managing multiple persons and data related to them?" Watch "What is the best approach for an application managing multiple persons and data related to them?" New topic
Author

What is the best approach for an application managing multiple persons and data related to them?

Veerle Boer
Greenhorn

Joined: Oct 20, 2011
Posts: 13
I have begun working on a project meant to manage multiple persons and data about them (birthdays, relationships, contact data, some payments they make) and my first approach was to store the objects in array lists, and then create the GUI step by step in NetBeans.

It is supposed to make calculations, display certain information about certain categories of persons, add, delete and edit these persons.

Looking for information while building the GUI I stumbled upon a tutorial about building a desktop application that controls a database and then it hit me: I was trying to build from scratch something that maybe can be done better that way!

I have put a considerable amount of time in the part I've already written (I had to define many objects, all the relationships between them, all the classes have complete javadoc comments, each method was tested) and I cannot help but wonder: is it a bad practice to use the initial approach to develop my application?


More specifically, is using array lists instead of a database a bad practice? Could I maybe continue to work on what I've done until now and still manage to create a good application?

I don't have so many doubts about building the GUI from scratch since the "Java Desktop Application" option became unavailable in NetBeans 7, but am not sure, though. This application has a menu bar and a menu with multiple submenus and menu items, and it is supposed to have multiple screens (more than 20).

I'm sorry if the questions sounds too stupid, but I could really appreciate the opinion of an experienced person when taking the decision of giving up the work I've made until now or not.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39070
    
  23
No, it is a good question.
There are several reasons for using databases, for example
  • Databases will keep your data safe for ages.
  • They are very good at searching your data.
  • Ulf Dittmer
    Marshal

    Joined: Mar 22, 2005
    Posts: 42038
        
      64
    Databases are a standard way of storing data, and come in many shapes and forms. But you haven't mentioned persisting data at all, just how you keep them in memory (in array lists). Have you given any thought yet how to persist data between application runs? Since it does sound like the data should be persisted, the first question you should think about is: Will the data only ever be accessed by one person from one computer, or should access be possible from several machines across a network (or possibly even across the internet)? If the former, then some kind of embedded DB would be sufficient (like HSQLDB or Derby, or a NoSQL DB like neo4j). If It's the latter, then some kind of DB server that is always running would be appropriate (like MySQL or PostgreSQL), regardless of whether the client app is running as well. A server-based approach would also allow you to create multiple different clients - maybe at some point you want to create a mobile app that has at least read-only access to the data?


    Ping & DNS - my free Android networking tools app
    Veerle Boer
    Greenhorn

    Joined: Oct 20, 2011
    Posts: 13
    Thank you for your answers, Campbell Ritchie and Ulf Dittmer.

    I use object streams and store data in a file between application runs.

    There is no network involved, and a single person on a single computer needs to access the data at one time. It is a very specific application and don't think it will evolve to something needed by a large amount of people, I try to help someone with the paperwork and learn to create such applications the right way with this occasion.

    From your answers I get that the array lists are not the best choice, right?

    In this case I'll start this again, from scratch, using databases.

    Ulf Dittmer
    Marshal

    Joined: Mar 22, 2005
    Posts: 42038
        
      64
    You need to differentiate between in-memory storage and persistent storage. For in-memory storage array lists may well be appropriate; we don't know enough about your application to say one way or the other.

    I would generally advise against using binary serialization (which, I assume, is what you mean by "object streams") as a form of persistent storage - that is not generally compatible between JVM versions. In other words, an upgrade of your JVM can render such files unreadable.

    Check out embeddable DBs such as HSQLDB (if you're interested in learning about SQL DBs) or neo4j for longer term storage.

    Alternatively, if you want to keep storage simple, switch to java.beans.XMLEncoder and XMLDecoder that are at least guaranteed to be compatible across JVM versions, and produce XML that's readable by other apps and tools.
    Veerle Boer
    Greenhorn

    Joined: Oct 20, 2011
    Posts: 13
    I think I don't have the right words to express what I mean clearly enough, so I will try again. I use object streams http://docs.oracle.com/javase/tutorial/essential/io/objectstreams.html to write the data to a file. In-memory storage is the content of the array-lists, and the persistent storage is the content of that file, am I right?

    The information about files becoming unreadable after a JVM upgrade is one of the most valuable you've offered me and the reason for which I must go with databases, I can't afford let my application lose data and many hours of work from the user's side just like that.

    What would you use binary serialization for (if you'd use it) if not for persistent storage?

    I will check out the embeddable DBs you suggested, but have one more question regarding this subject. Is there a reason why I should rather go with HSQLDB instead of, for example, Apache Derby?

    And regarding neo4j, this is something I'd never would have come up with by my own for this application, never heard about graph databases before. What makes an application more appropriate for a graph database instead of a SQL database?

    I am interested in learning about SQL DBs, the problem is I am interested in learning everything and I have a hard time establishing the priorities. But sure, learning about SQL DBs is close to the top of my priorities. <rhetorical question>Or should I learn first about graph databases?</rhetorical question>

    Thanks again, Ulf, for your valuable help.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7892
        
      21

    Veerle Boer wrote:What would you use binary serialization for (if you'd use it) if not for persistent storage?

    One possibility is for sending objects over a network.

    Winston

    @Ulf: Thanks from me too. I'd never heard of neo4j before; 'sounds interesting.

    Isn't it funny how there's always time and money enough to do it WRONG?
    Articles by Winston can be found here
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 39070
        
      23
    Veerle Boer wrote:Thank you for your answers, Campbell Ritchie and Ulf Dittmer. . . .
    You’re welcome
    Ulf Dittmer
    Marshal

    Joined: Mar 22, 2005
    Posts: 42038
        
      64
    Veerle Boer wrote:In-memory storage is the content of the array-lists, and the persistent storage is the content of that file, am I right?

    Yes. Persistent storage is anything that survives termination of the JVM - could be files or DBs.

    The information about files becoming unreadable after a JVM upgrade is one of the most valuable you've offered me and the reason for which I must go with databases

    No, it does not follow that you need to use a DB. The XMLEncoder/XMLDecoder classes I mentioned are capable of persisting objects in a way that is stable across JVM versions.

    What would you use binary serialization for (if you'd use it) if not for persistent storage?

    For short-lived storage within a JVM's lifetime, or for network communication between JVMs. For example, RMI uses binary serialization. Binary serialization has several drawbacks that have caused to fall out of favor, like the lack of guaranteed compatibility across JVM versions, and -of course- it's a Java-only technology, so you can't use it to exchange data with non-Java apps.

    I will check out the embeddable DBs you suggested, but have one more question regarding this subject. Is there a reason why I should rather go with HSQLDB instead of, for example, Apache Derby?

    I find HSQLDB easier to get started with, and it has a smaller memory footprint than Derby (which is a more full-featured product), but either would be a good choice.

    And regarding neo4j, this is something I'd never would have come up with by my own for this application, never heard about graph databases before. What makes an application more appropriate for a graph database instead of a SQL database?

    If the underlying data fits the graph model :-) Head over to http://www.neo4j.org/learn to pick up the fundamental concepts; that should give you a feeling what such a DB is good at, and how it differs from a SQL DB.

    I am interested in learning about SQL DBs, the problem is I am interested in learning everything and I have a hard time establishing the priorities. But sure, learning about SQL DBs is close to the top of my priorities. <rhetorical question>Or should I learn first about graph databases?</rhetorical question>

    In that case I would start with a SQL DB, as they're used much more widely.
    Veerle Boer
    Greenhorn

    Joined: Oct 20, 2011
    Posts: 13
    Thank you for your answer, Winston Gutkowski!

    @Ulf: The DB hype made me overlook the XML alternative. I'll have to give it some thought too, because it is also a good choice and is important to get to know.

    Thank you for your help. I have learned a lot from you in this thread. I have already begun reading the information at neo4j/learn, and only asked you that hoping to grasp some of the better insight you obviously have. But you've given me more than enough already.

    Once again, thank you!
    Jayesh A Lalwani
    Bartender

    Joined: Jan 17, 2008
    Posts: 2383
        
      28

    Another thing that you may want to think about is that what happens when your data becomes too large to fit in the memory. Memory is a limited resource in any system (although is becoming quite large nowdays). Even if your users do have lot of memory, you still want to avoid hogging up their memory. XML is a good approach for consider. However, remember that with XML, you can go 2 ways:- a) load all the data in memory or b) read records from XML as you need. a) is simplest to implement but runs into memory limitations, b) is more complicated to implement.

    The thing is databases are designed to take care of things like these. The whole idea of having a database is the give application developers an easy way to store and retreive data, and the database takes care of the rest. The database designers have spent years and years considering issues like these, and it seems that you are kind of reinventing the wheel. IMO, you are better off using a database, even if it's an embedded database like HSQLDB. This is why storing data in databases is the de facto way of storing data in the industry.

    When you start learning how to store data in database, you might have a learning curve in the beggining, but you are better off in the long run.
    Veerle Boer
    Greenhorn

    Joined: Oct 20, 2011
    Posts: 13
    Jayesh A Lalwani , thank you for letting me know your opinion.

    I was afraid not to be reinventing the wheel, or do something else that isn't recommended, so as soon as I figured out I might do that I came here to ask for help. I guess it isn't hard for beginners to do these mistakes.

    I have worked many hours for this project, but I'm not afraid to start from scratch, even if I have to face a steep learning curve at the beginning. My only fear was about going the wrong way.

    The hours I've put into this until now are not wasted, I've learned and practiced.

    I will spend another day or two researching the options I have and then decide how to continue.





    Jayesh A Lalwani
    Bartender

    Joined: Jan 17, 2008
    Posts: 2383
        
      28

    Right. the best way to learn is from your mistakes. However, this does sound like this is something that you are going to sell as a product, and you are not doing for just learning. If you are doing this for learning, try every idea that comes to your head Building your own in memory database, can be very educational. However, if you are making something that you have to support and maintain over a long term, stick to using a database
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7892
        
      21

    Ulf Dittmer wrote:If the underlying data fits the graph model :-) Head over to http://www.neo4j.org/learn to pick up the fundamental concepts; that should give you a feeling what such a DB is good at, and how it differs from a SQL DB.

    Thanks again Ulf; a real eye-opener. Back in 1984/5 I worked on a project that used the IBM Data Dictionary, which was the first time I was introduced to relationships as something concrete, rather than just a line on a modelling diagram. Unfortunately, it never really caught on ... until now it would seem.

    I've obviously got a lot more reading to do, but it's funny how things come full circle sometimes.

    Winston
    J. Kevin Robbins
    Bartender

    Joined: Dec 16, 2010
    Posts: 983
        
      13

    Veerle Boer wrote: It is a very specific application and don't think it will evolve to something needed by a large amount of people,


    Red flag! This is the sort of assumption that will come back and bite you later. These things have a way of growing beyond the original specifications. If you build it to talk to a database, even a local one, using DAO's, then later on it's a relatively simple matter to change the DAO code to talk to a centralized database server.

    I would bet dimes to dollars that once the application is installed, the customer will say, "This is great. Now can you install it on Johns computer so he can access it when Jack is out of the office?"

    Now your single-user app just turned into a network app that needs a database server. But you are prepared for it because you anticipated it.


    "The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: What is the best approach for an application managing multiple persons and data related to them?