desgin tables into objects or vice versa?

[Elhanan]

hi..

i'm a database kind of guy, when ever i apprached a new project i
always looked at it from tables point of view, how can normlize
correcly and them moved to the objects and desgined them accodging to
the tables..

i see that usually ppl go the other way, design objects and then desgin
the tables..

i was looking into my tables and usually i see i have column
type_of_somthing in it. like request_type in requests table or
order_type in orders tables, etc...
i was wondering, whenever i see this type of columns would it be right
to design a class tree according to it? for example abstract order
class and each subclass would correspond to an order type.

[Nick Hounsome]

"Elhanan" <em*****@hotmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...

hi..

i'm a database kind of guy, when ever i apprached a new project i
always looked at it from tables point of view, how can normlize
correcly and them moved to the objects and desgined them accodging to
the tables..

i see that usually ppl go the other way, design objects and then desgin
the tables..

i was looking into my tables and usually i see i have column
type_of_somthing in it. like request_type in requests table or
order_type in orders tables, etc...
i was wondering, whenever i see this type of columns would it be right
to design a class tree according to it? for example abstract order
class and each subclass would correspond to an order type.

If different types must be processed differently then inheritance and
virtual methods are probably good.

If the processing is the same apart from some extra fields the probably best
not to bother.

If the fields differ other than by addition then processing must be
different and inheritance and polymorphism would be good.

Sometimes it can be better to handle these issues by sticking with a request
type but rather than using switch or if...then..else you use a dictionary to
look how to process the data. The advantage of this method is that the
dictionary can be populated using resource files and reflection.

[Dale]

I'm a database kind of guy, myself. As such, all my training and every
database design book I have ever read, and most developer books as well, have
started out with similiar scenarios: a brainstorming session with sticky
notes and big whiteboards on which everyone identifies objects, which become
tables, and attributes, which become fields or columns. From these sticky
notes, the designer does his magic and creates a database design that
developers write software around.

Well, your question shows that you suspect the books might be wrong.

You're right - they are wrong.

A better way is to start with gathering user and business requirements, from
these you create Use Case documents. Use Case documents are then used to
create static class diagrams.

Once you have a model of the classes necessary to implement the business
rules and requirements, you design a database schema to persist those
classes. That is the role of the database: to persist objects.

There are a lot of ORM (Object-Relational Modeling) products that try to
automate this process and some do a fair job but, so far, none will create an
optimized data model based on your class structure. You can use them as a
starting point and manually tweak the design or you can use the static class
diagram as input for manually creating a data model. Which you choose
depends on the scope of the project, budget, and personal (or team)
preferences.

I suggest searching for, and reading up on, Extreme Programming, Agile
Process, and Rational Unified Process. While there are many people who, for
their own good reasons, swear by one process or another, you should read up
on and understand all three.

HTH
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Elhanan" wrote:

hi..

i'm a database kind of guy, when ever i apprached a new project i
always looked at it from tables point of view, how can normlize
correcly and them moved to the objects and desgined them accodging to
the tables..

i see that usually ppl go the other way, design objects and then desgin
the tables..

i was looking into my tables and usually i see i have column
type_of_somthing in it. like request_type in requests table or
order_type in orders tables, etc...
i was wondering, whenever i see this type of columns would it be right
to design a class tree according to it? for example abstract order
class and each subclass would correspond to an order type.

[Elhanan]

i never view the database as just something to persist objects in, if
i did, i would just use hibernate and forget all about it, however i
always thinking on how other applications might to datamine my own
applications so i desgin the database to be optimal first then and
desing the classes around it (that's why i end up with a cloumns
object_type and not sub classe).

i've read several books like C# Objects, but i don't work in a team,
all this team effort of uses cases and meetings to create digagrams,
but in my reality , i have to leave from hand to mouth.

for example i created a small desktop application in vb6 which uses an
object model dll (which i also created) to calulcate pension, then they
wanted it to be able to receive data from another web page (the reason
why it wasn't web from the first place was the reqiruiment it should
operate on a stand alone basis with field agents and laptops). ok, i
said give me 2-3 weeks to have web interface around the dll (the dll
need around 150 fields to enter) , they gave me 2-3 DAYS. so i had to
be 'creative' and according to a microsoft article of microsoft, i
created a new 'proposal' protocol, so each time a user enters something
like:
proposal:servername/proposal.asp, the desktop application is lanched ,
uses the proposal asp (it got from the command line) which behind the
scenes uses the same dll to persist data and send it as xml, to it's
clone brother in the desktop application which loads back the data.

so i got to 'reuse' my software. and have stand into conflicting
requirements, the same products needs to be able to compeletly cut off
from any central sysem, but still be able to recieve data from a
central system (actually few of them, one in oracle, another from
access, last from as400) each with a diffrerent data format.

[Dale]

That's what happens when you live and work in the real world, huh? All
those things that "ought to be" just don't always happen that way. :)
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Elhanan" wrote:

i never view the database as just something to persist objects in, if
i did, i would just use hibernate and forget all about it, however i
always thinking on how other applications might to datamine my own
applications so i desgin the database to be optimal first then and
desing the classes around it (that's why i end up with a cloumns
object_type and not sub classe).

i've read several books like C# Objects, but i don't work in a team,
all this team effort of uses cases and meetings to create digagrams,
but in my reality , i have to leave from hand to mouth.

for example i created a small desktop application in vb6 which uses an
object model dll (which i also created) to calulcate pension, then they
wanted it to be able to receive data from another web page (the reason
why it wasn't web from the first place was the reqiruiment it should
operate on a stand alone basis with field agents and laptops). ok, i
said give me 2-3 weeks to have web interface around the dll (the dll
need around 150 fields to enter) , they gave me 2-3 DAYS. so i had to
be 'creative' and according to a microsoft article of microsoft, i
created a new 'proposal' protocol, so each time a user enters something
like:
proposal:servername/proposal.asp, the desktop application is lanched ,
uses the proposal asp (it got from the command line) which behind the
scenes uses the same dll to persist data and send it as xml, to it's
clone brother in the desktop application which loads back the data.

so i got to 'reuse' my software. and have stand into conflicting
requirements, the same products needs to be able to compeletly cut off
from any central sysem, but still be able to recieve data from a
central system (actually few of them, one in oracle, another from
access, last from as400) each with a diffrerent data format.