Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2003
    Posts
    7

    Question How to map java classes into the database!! HELP!?

    So im having some trouble designing a database i want to use.
    here is an example of my object design
    [a] - abstract class
    int ID_NUMBER
    String NAME

    [a.1] extends [a] abstract class



    [a.2] extends [a] abstract class



    [b] extends [a.1] abstract class


    [c] extends [a.1] abstract class


    [d] extends [b]
    [e] extends [b]
    .
    .
    .
    [h] extends [b[

    so i have this tree type object design in which they all have an ID and a name... and ultaimatly a type .
    at first we had a table with a list of ID's names and "types" being some character that represented a type ( could possibly be looked up in some sort of a typeCode table") but since every object has a string of type associated with is it seems messy to store a bunch of tables just to m ap each object ( instance of) to its type..
    example
    u have a instance of type e... then u know its also of type b and not c as well as type a.1 and not a.2 ... is there a good source to look for as far as books or documentation to map these objects to database tables well?

  2. #2
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697

    Re: How to map java classes into the database!! HELP!?

    Are you sure the problem's with mapping it to the database and not with your class hierarchy?

    It sounds like you're making the classic mistake people do when they start out with OO: try to use lots of inheritance and interfaces without trying to figure out what a class or an object is supposed to be in a logical sense.

    Best plan: throw out your class hierarchy, and design a good database schema. Then map your objects to that.

    Otherwise you're going to have to write some kind of kluge, and you'd get more help in the Java section.

  3. #3
    Join Date
    Mar 2003
    Posts
    7
    well each one of thos sub classes has fields that are specific to them .. that was the reasoning for having that heirarchy. Im not too keen on designing a database schema that would them limit our resulting OO design... is that the only soultion? i tought u were able to have somethign like a class exist in a database?

  4. #4
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Originally posted by premesh
    well each one of thos sub classes has fields that are specific to them .. that was the reasoning for having that heirarchy. Im not too keen on designing a database schema that would them limit our resulting OO design... is that the only soultion? i tought u were able to have somethign like a class exist in a database?
    Well, this is an area of much debate, and because of limitations in SQL products we have to look first at the way it ought to be, and then at the way it is.

    First off, you don't really want the database schema to be exactly like your OO hierarchy. The #1 reason is that an RDBMS can handle integrity constraints far better than your application can. It takes all of one keyword to express a UNIQUE constraint in SQL, whereas even with the best Collections package you have to create a hashtable, check every insert and delete against the hashtable, free the hashtable up when you're done, etc, etc.

    The frustrating thing about SQL DBMS's is that they have most of the integrity constraints you could want, but then if you try to do something protected against it's very hard to (programmatically) determine what went wrong and give back a user-friendly error message.

    Second, what does inheritance *really* express in your OO hierarchy? Are you rigorously applying the Liskov Substitution Principle in all cases of inheritance? A few related tables, on the other hand, can be summed up in a few straightforward English sentences. One thing that's got me a bit skeptical of your design is that everything descends from a base class with an ID and a NAME. I'm skeptical only because I recall trying something similar and throwing it out. ;-) For example, there will be *some* tables that shouldn't have an ID field.

    Still, some implementation possibilities:

    You might want to do some digging on Enterprise Java Beans. I'm not an expert on them, but Sun's obviously dealt with the issues you're looking at. If you wind up writing pages of code for loading and caching and whatnot, you'll be wondering why you bothered with a DBMS in the first place.

    Some databases *do* attempt to emulate inheritance. PostgreSQL is one. Unfortunately there's a gotcha: to emulate inheritance, PostgreSQL uses an OID column for object ID. This works great with base tables, but when you derive a view, what should the OID be? If I do a join, whose OID do I pick?

    If you later want to allow other applications to access your database you're probably going to want to create a set of views over your base table since they won't want to see the exact same schema as the first application you wrote. Then the OID problem rears its ugly head because you've lost the equivalence between base tables and derived tables.

    So, IMHO, it's best to avoid inheritance if you can. And while it might cramp your OO a bit, think about it this way: if you didn't have the DBMS, you'd have no way to do ad hoc queries. *Every* management task has to be tediously coded. Life's too short.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •