Design Question - RDB, objects, and rows

Design Question - RDB, objects, and rows

Post by Sean P. LeCro » Tue, 27 Jul 1999 04:00:00



Hello,

        I have a general design question.

        When design an OO system that is processing records in a RDBMS
what is the best way to achieve this mapping.  For instance, there is
a table in the DB that represents a credit card, the table being
comprised of 50+ fields.  What is the best pattern for designing
Credit card object that represents one row from this table?

        I'm really struggling with this.  I have tried designing a
Credit card object with getters and setters for each field, and that
seems to be massively "fat."  I have tried just passing the result set
to the client, but this seems like tight-coupling.

        I would like to hear any thoughts or suggestions on this
issue.  If someone can recommend articles or books discussing this
problem, I would like to know that as well.

Thanks,
SPL

 
 
 

Design Question - RDB, objects, and rows

Post by jianpin » Tue, 27 Jul 1999 04:00:00



> Hello,

>         I have a general design question.

>         When design an OO system that is processing records in a RDBMS
> what is the best way to achieve this mapping.  For instance, there is
> a table in the DB that represents a credit card, the table being
> comprised of 50+ fields.  What is the best pattern for designing
> Credit card object that represents one row from this table?

A table with 50+ fields may indicate a bad design in your table structure.
For example, people may have several Credit cards, but their addresses and
phone number will not change. What you can try is to partition your "fat"
table into several relatively smaller objects. I can't see any
relationship between the design for this problem related to any known
patterns.

>         I'm really struggling with this.  I have tried designing a
> Credit card object with getters and setters for each field, and that
> seems to be massively "fat."  I have tried just passing the result set
> to the client, but this seems like tight-coupling.

>         I would like to hear any thoughts or suggestions on this
> issue.  If someone can recommend articles or books discussing this
> problem, I would like to know that as well.

> Thanks,
> SPL



 
 
 

Design Question - RDB, objects, and rows

Post by Sean P. LeCro » Tue, 27 Jul 1999 04:00:00




>> Hello,

>>         I have a general design question.

>>         When design an OO system that is processing records in a RDBMS
>> what is the best way to achieve this mapping.  For instance, there is
>> a table in the DB that represents a credit card, the table being
>> comprised of 50+ fields.  What is the best pattern for designing
>> Credit card object that represents one row from this table?

>A table with 50+ fields may indicate a bad design in your table structure.
>For example, people may have several Credit cards, but their addresses and
>phone number will not change. What you can try is to partition your "fat"
>table into several relatively smaller objects. I can't see any
>relationship between the design for this problem related to any known
>patterns.

The problem at hand (and I should have expressed this in my previous
post) is that we are dealing with a legacy system.  Unfortunately we
do not have the luxury of changing the file formats.  

I should also state that the database is fairly normalized.  Client
name, address, phone, etc. is maintained in separate tables.  Mainly
this table contains card specific information (card number, expiration
date, usages information, flags, etc).  If anyone has ever dealt with
credit card processing, you will know that there are many status
flags, dates, and counters to keep up with.

I think that there has to be a reasonable way to deal with this issue.
Maybe the solution is to break the fields down into logical groups and
express those as separate objects in a container.  I'd just like to
get advise on the subject because we have many objects that map to
tables that will have this problem.

- Show quoted text -

>>         I'm really struggling with this.  I have tried designing a
>> Credit card object with getters and setters for each field, and that
>> seems to be massively "fat."  I have tried just passing the result set
>> to the client, but this seems like tight-coupling.

>>         I would like to hear any thoughts or suggestions on this
>> issue.  If someone can recommend articles or books discussing this
>> problem, I would like to know that as well.

>> Thanks,
>> SPL


 
 
 

Design Question - RDB, objects, and rows

Post by patr.. » Tue, 27 Jul 1999 04:00:00



:       When design an OO system that is processing records in a RDBMS
: what is the best way to achieve this mapping.  For instance, there is
: a table in the DB that represents a credit card, the table being
: comprised of 50+ fields.  What is the best pattern for designing
: Credit card object that represents one row from this table?

As you clarified in a later message, these fields represent various
status about the credit card and not "denormalized" information such
as customer name, address, etc. Will the applications always use all
of the information, or will some use just part of the information? Are
there logical groups of this information that are typically used
together?

:       I'm really struggling with this.  I have tried designing a
: Credit card object with getters and setters for each field, and that
: seems to be massively "fat."  I have tried just passing the result set
: to the client, but this seems like tight-coupling.

For large aggregations of attributes it is sometimes cleaner to
implement one getter and one setter where they are parameterized over
the attribute to get. This is especially useful when not all instances
have or use the same set of attributes or when there are may useful
default values, etc.

public interface CreditCard
{
  // Use int codes for attributes if they are determined a priori.

  public Object get(String attribute_name);

  public Object put(String attribute_name, Object value);

  ...

Quote:}

--

 
 
 

Design Question - RDB, objects, and rows

Post by Wolfram Puecher » Wed, 28 Jul 1999 04:00:00



> Hello,

>         When design an OO system that is processing records in a RDBMS
> what is the best way to achieve this mapping.  For instance, there is
> a table in the DB that represents a credit card, the table being
> comprised of 50+ fields.  What is the best pattern for designing
> Credit card object that represents one row from this table?

> Thanks,
> SPL


Hello,

do you have a persistence and transaction environment (i.e. persistence
service class, transaction service class) in your software system?

Do you deal with transactions?

If you do so then use the persistency service to map classes to the
RDBMS-table. I don't think you use ONE persistence class. There are many
classes represented by tables. They have to get organized by a
transaction service and a GOOD persistence service.

Wolfram Pchert
--
http://come.to/weepee

 
 
 

Design Question - RDB, objects, and rows

Post by Ajit De » Fri, 30 Jul 1999 04:00:00


try www.ambysoft.com and follow the "White papers about OO development and
related issues" link


>> Hello,

>>         I have a general design question.

>>         When design an OO system that is processing records in a RDBMS
>> what is the best way to achieve this mapping.  For instance, there is
>> a table in the DB that represents a credit card, the table being
>> comprised of 50+ fields.  What is the best pattern for designing
>> Credit card object that represents one row from this table?

>A table with 50+ fields may indicate a bad design in your table structure.
>For example, people may have several Credit cards, but their addresses and
>phone number will not change. What you can try is to partition your "fat"
>table into several relatively smaller objects. I can't see any
>relationship between the design for this problem related to any known
>patterns.

>>         I'm really struggling with this.  I have tried designing a
>> Credit card object with getters and setters for each field, and that
>> seems to be massively "fat."  I have tried just passing the result set
>> to the client, but this seems like tight-coupling.

>>         I would like to hear any thoughts or suggestions on this
>> issue.  If someone can recommend articles or books discussing this
>> problem, I would like to know that as well.

>> Thanks,
>> SPL


 
 
 

Design Question - RDB, objects, and rows

Post by Damon Feldm » Thu, 05 Aug 1999 04:00:00



>        When design an OO system that is processing records in a RDBMS
>what is the best way to achieve this mapping.  For instance, there is
>a table in the DB that represents a credit card, the table being
>comprised of 50+ fields.  What is the best pattern for designing
>Credit card object that represents one row from this table?

Stop thinking about the table, if possible, and think about a good OO system.

Design a solution that will probably have a credit card object.  Then think
about what is natural to ask this object:

You may end up with:  Card.retrieveFor(Customer c), Card.readAll(), etc.

This should greatly direct your solution about how to build this card from
your legacy DB.  If the number of fields or amount of data makes it hard to
implement the objects you designed, *then*, if necessary, start thinking about
changing your object model based on what the developers of your legacy system
did 10 years ago.

d.

 
 
 

Design Question - RDB, objects, and rows

Post by akmal b. chaudhr » Thu, 05 Aug 1999 04:00:00




> Hello,

>    I have a general design question.

For general answers, try looking at some of the references on O<-->R
mapping at Cetus:

http://www.cetus-links.org/

There are also patterns-related papers that you might find useful here:

http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm

>    When design an OO system that is processing records in a RDBMS
> what is the best way to achieve this mapping.  For instance, there is
> a table in the DB that represents a credit card, the table being
> comprised of 50+ fields.  What is the best pattern for designing
> Credit card object that represents one row from this table?

>    I'm really struggling with this.  I have tried designing a
> Credit card object with getters and setters for each field, and that
> seems to be massively "fat."  I have tried just passing the result set
> to the client, but this seems like tight-coupling.

>    I would like to hear any thoughts or suggestions on this
> issue.  If someone can recommend articles or books discussing this
> problem, I would like to know that as well.

> Thanks,
> SPL


akmal

--
akmal at bigfoot dot com | www.bigfoot.com/~akmal/

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

Design Question - RDB, objects, and rows

Post by Jeffery Can » Fri, 06 Aug 1999 04:00:00




> Hello,

>    I have a general design question.

>    When design an OO system that is processing records in a RDBMS
> what is the best way to achieve this mapping.  For instance, there is
> a table in the DB that represents a credit card, the table being
> comprised of 50+ fields.  What is the best pattern for designing
> Credit card object that represents one row from this table?

If you're working in Java, you can serialize your credit card object to
a byte stream and then store this byte stream (along with its key) in a
LONG RAW or BLOB type column in the RDBMS.  This decouples the mapping
between columns in the database and member fields in your object.
If you later add a field to your object, you don't have to add
another column to the database because the entire (serialized)
object is stored in one column.

** BEWARE ***
Beware that this limits your ability to query the object using the DBMS
SQL engine (unless you're using Oracle 8i) because it is merely a stream
of bytes, stored in the database.  This technique also would limit your
modeling ability in the RDBMS, i.e., it would be imposible to break a
serialized object into a parent-child pattern.

For more info on serializable, check out the java tutorial:

http://java.sun.com/docs/books/tutorial/essential/io/serialization.html

Jeff

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

Design Question - RDB, objects, and rows

Post by Natan C » Thu, 16 Sep 1999 04:00:00




>>>         I have a general design question.

>>>         When design an OO system that is processing records in a RDBMS
>>> what is the best way to achieve this mapping.  For instance, there is
>>> a table in the DB that represents a credit card, the table being
>>> comprised of 50+ fields.  What is the best pattern for designing
>>> Credit card object that represents one row from this table?

>>A table with 50+ fields may indicate a bad design in your table structure.
>>For example, people may have several Credit cards, but their addresses and
>>phone number will not change. What you can try is to partition your "fat"
>>table into several relatively smaller objects. I can't see any
>>relationship between the design for this problem related to any known
>>patterns.

>The problem at hand (and I should have expressed this in my previous
>post) is that we are dealing with a legacy system.  Unfortunately we
>do not have the luxury of changing the file formats.  

>I should also state that the database is fairly normalized.  Client
>name, address, phone, etc. is maintained in separate tables.  Mainly
>this table contains card specific information (card number, expiration
>date, usages information, flags, etc).  If anyone has ever dealt with
>credit card processing, you will know that there are many status
>flags, dates, and counters to keep up with.

>I think that there has to be a reasonable way to deal with this issue.
>Maybe the solution is to break the fields down into logical groups and
>express those as separate objects in a container.  I'd just like to
>get advise on the subject because we have many objects that map to
>tables that will have this problem.

Sometimes it is hard. Especially with legacy-systems. But it should be
possibly to simplify some things.

Status can often be set from functions internal to the class, so even
if there are a lot of getters and setters (or direct access if you
really want) a lot of those will be private and will only be accessed
via other setters.

Usage information is also only set when other events occur, so those
do not need to be public either. 2 dates sometimes are an interval,
and if intervals are used often it is a very handy abstraction..

Sometimes you can split the table in logical groups. In 1 project we
had a Customer-table and where able to split it up into classes such
as Identity, Address, UnemplomentStatus (a big one!!) and some others.
But I must admit, it wasn't the best database ever designed.

Natan

 
 
 

Design Question - RDB, objects, and rows

Post by Damon Feldm » Thu, 23 Sep 1999 04:00:00


Quote:>>>>         I have a general design question.

>>>>         When design an OO system that is processing records in a RDBMS
>>>> what is the best way to achieve this mapping.  For instance, there is
>>>> a table in the DB that represents a credit card, the table being
>>>> comprised of 50+ fields.  
>>>> What is the best pattern for designing [this system]

"Buy it don't build it"

OO-RDB mappings are an impedence mismatch.  They are harder than people
typically expect.

d.

 
 
 

Design Question - RDB, objects, and rows

Post by akmal b. chaudhr » Fri, 24 Sep 1999 04:00:00




Quote:> >>>>         I have a general design question.

> >>>>         When design an OO system that is processing records in a
RDBMS
> >>>> what is the best way to achieve this mapping.  For instance,
there is
> >>>> a table in the DB that represents a credit card, the table being
> >>>> comprised of 50+ fields.

> >>>> What is the best pattern for designing [this system]

> "Buy it don't build it"

> OO-RDB mappings are an impedence mismatch.  They are harder than
people
> typically expect.

> d.

Mind you, there are plenty of perls of wisdom on how to do it if you
really want to. Cetus is always a good place to start:
http://www.cetus-links.org/

Regards,

akmal

--
akmal at bigfoot dot com | http://www.bigfoot.com/~akmal/

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.