Design question - Inherit or not

  • Thread starter Thread starter Steve Barnett
  • Start date Start date
S

Steve Barnett

I have a database with two tables "Structure" and "Data". The Data table
contains the data for my application, so no problem there. The Structure
table effectively puts some organisation to the Data table. It contains a
"tree structure" of records linked by parent/child/sibling pointers plus the
key of the data record that it refers to. It is possible for the same data
record to be referred to in more than one place in the structure.

Now, when I translate this to objects, I get a Data object with the data in
it and a Structure object with the structure in it. However, in order to
render a structure object on screen, it requires some of the data from the
data object.

So, should "Structure" be derived from the Data object, or should the
Structure object contain a Data object? My initial reaction is that
Structure inherits Data, but thinking about it, the Structure object
requires very little of the Data object in order to render it, so inheriting
a full Data object seems like way too much of an overhead. I could create a
Structure object that contains some of the data from the data table, but
that feels too much like data duplication.

Anyone got any opinions (As you can tell from the description, I'm very much
a beginner at this stuff).

Thanks
Steve
 
Steve,

What database are you using.

In my opinion has a good database all that what you call Structure explicit
in it.

Should you not review your design if you are not creating things which exist
already?

Cor
 
The database will be Access. Maybe I'm out of date, but I don't know how the
database can provide a hierarchical structure (like a tree - think of it
like your folder structure in Windows Explorer) with facilities to quickly
reorganise the structure with drag and drop.

Then again, I'm still stuck in the DAO days, maintaining an 11 year old app,
so maybe things have moved on. Can you provide me with any references as to
how to do this kind of structure in the database?

Steve
 
Sorry, I understand the concept of master/detail records. That's not how my
data is organised though.

Think of it like the structure of a set of windows folders:

The root (C) has four folders under it called Windows, Program Files, My
Documents and Documents & Settings. Expanding My Documents reveals more
folders called My Library, My Pictures and My eBooks. So you end up with a
structure like:

C:\
Windows
Program Files
My Documents
My Library
My Pictures
My eBooks.
Documents & Settings

Each of these folders has attributes, such as the folder name, security
settings and icons etc... My "Structure" table defines the folder structures
(or relationships) and my "Data" table defines the attributes of the
individual folders.

In the structure table there are four pointers; the parent node, the
previous sibling the next sibling ad the first child node. It also contains
the key of the record that it relates to in the data table. In my structure,
you can have the same folder in more than one place, hence the reason for
splitting the structure and the data in to two tables.

In order to display the tree, I need to retrieve the structure information
from the structure table and the folder name from the data table. So my
question is;

1/ should the Structure object inherit the Data object (so including a
lot of data that I don't need)

2/ should the Structure object contain a reference to the data object
(same problem - but I have the option not to fill in the data until I need
it).

3/ should the Structure object just retrieve what data it needs from the
Data table (so introducing the possibility of data duplication).

Sorry if my earlier explanation wasn't clear. I tending towards option 3 now
I've written it out. It's not pure object oriented design, but it's
practical.

Thanks
Steve
 
Steve,

Maybe I miss something however what you tell looks for me as how the dataset
is organized.

The dataset exist from
DataTables
DataColumns which desctribes the attributes
DataRows which hold the data in items conform the describtion DataColumn
DataRelations
Describes the relations between Parents and childs tables (for the rows
of course)

http://msdn2.microsoft.com/en-us/library/dbwcse3d.aspx

However, maybe I am completely beside your problem.

Cor
 
Cor
Thanks for hanging in here. I think we're getting hung up on the
database organisation too much. I'm looking for guidance on the definition
of "Objects", not the table relationships. I'm VERY new to objects! Lets
simplify it a little.

I have two tables (a) and (b). In order to display the data in table (a), I
need a subset of the information that is in table (b). I already have an
Object defined that encompass the full content of table (b) and now want to
define the object that I need in order to display a record from table (a).

Should my (a) object contain an instance of object (b), should (a) inherit
(b) or should I forget that there is an object (b) and create a new object
(a) that contains just the data I want from table (b) even though this might
lead to data duplication.

Steve
 
Steve,

Why don't you accept the build in class "dataset".

It is a fully OOP class, which you need to instance to get an object.

In my opinion does your current approach leads to an own build solution,
which never sustain very long.

In the beginning of .Net we saw a lot of people trying to do with what you
are busy with (if I understand you well).

However just my idea and I can completely misunderstand you.

Cor
 
Back
Top