database or object design first?

[fishfry]

I'm building a relatively small database-driven app. I'm accustomed to
first developing the schema and e/r (entity-relationship) model, then
writing the code against the db.

I'm relatively new to the OO way of doing things. Am I really supposed
to ignore db design and do my object design first, then use an
object-relational mapping layer and never actually do any db design?

Or is this more theory than practice, and real-world developers still do
their db schema design first?

Any and all viewpoints and suggestions for further reading are welcome.

 

[Robert kebernet Cooper]

I usually do ERD fist, with a mind to how it is going to map to
objects. Then I do my model layer objects and mapping configuration for
whatever persistence system I am using. You kinda have to do this a
few times to get the hang of it, really. You are balancing DB
performance issues, Object mapping issues and how you want to work with
the data issues all at the same time. One thing I would say is that
views are your friend. A lot of time if you need a very specialized
dataset and it seems particularly object intesive, don't be afraid to
map a specialized object to a view and use it in that individual
instance. Also, when mapping to object, normalization is MUCH more
important than most DB people tend to think. FNF is usually gospel.

This is all really "separate" from the design of my business layer
which is usually driven by the use cases and is sketched out before
work on the ERD even begins.

 

[The Abrasive Sponge]

I'm building a relatively small database-driven app. I'm accustomed to
first developing the schema and e/r (entity-relationship) model, then
writing the code against the db.

I'm relatively new to the OO way of doing things. Am I really supposed
to ignore db design and do my object design first, then use an
object-relational mapping layer and never actually do any db design?

Or is this more theory than practice, and real-world developers still do
their db schema design first?

Any and all viewpoints and suggestions for further reading are welcome.

Not me, objects first! This is particularly useful in knowing what will
be associations and what will be many-many relationships. In my
opinion, you will be working with objects more that the database as a
programmer. In addition to what I wrote, mapping tools like Hibernate
can do the work of building the database schema (with referential
integrity) automatically, so as a developer, you are moving more and
more from the database side to the object oriented side.

 

[Stephen Riehm]

fishfry wrote:

Not me, objects first! This is particularly useful in knowing what will
be associations and what will be many-many relationships. In my
opinion, you will be working with objects more that the database as a
programmer. In addition to what I wrote, mapping tools like Hibernate
can do the work of building the database schema (with referential
integrity) automatically, so as a developer, you are moving more and
more from the database side to the object oriented side.

Sounds reasonable, and is pretty much the approach I've taken for my first
db-driven java app. Now I'm trying to build a dao bridge between a bunch of
inter-related classes and a similar, but different set of tables. (ie: the
objects combine data from another app (provided by read-only tables, whose
structure is fixed) and enhance that data with data from my app, which
needs to
be stored in other tables.) If possible, I'd also like the app's objects
not to
know anything about SQL

So basically I want to merge the data from some classes into a single table,
and retrieve the contents of some classes from several tables.
Are there any tutorials for building abstraction layers like this?

I've seen this mentioned often, in terms of patterns (dao, bridge) but I've
seen very little code.

likewise for me ;-)

Thanks,

Steve

 

[elsid]

I'm building a relatively small database-driven app. I'm accustomed to
first developing the schema and e/r (entity-relationship) model, then

writing the code against the db.

I'm relatively new to the OO way of doing things. Am I really supposed
to ignore db design and do my object design first, then use an
object-relational mapping layer and never actually do any db design?

Or is this more theory than practice, and real-world developers still do
their db schema design first?

Any and all viewpoints and suggestions for further reading are

welcome.

Regardless of whether you use OO or not,

1. Determine the Outputs and the Inputs required to create them.
2. Determine what data will be retained in your data base.
3. Normalize the retained data.
4. Create your interface and its supporting code to interface with the
retained data.

Regards
Robert