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_somthin g 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.