4 replies to this topic

[mouse]

Hello, in college during our software development, our professors taught us to first create a data schema from where we could base our object schema/architecture and source code. But then, when there are changes to the data schema or to the physical database, we have to also change our objects. Is this approach right or should the object schema drive the data schema and source code?

[WingedPanther]

It tends to depend a LOT on what's going on. If you add a new feature, you often have to update both the object and data schemas. All of it boils down to changing how you store information.

[LuthfiHakim]

I agree with your professor, based on the following reasonings.

• You must optimize database as much as you can for speed. This especially true for database server (used by many applications at once). Therefore you must pick the best data schema for your data, not by the behavior of your objects.
  
• It's much easier to change behavior of the objects than changing the database structure respecting the above reason.
  
• You can use views or stored procedure/functions should you need complex entity structure, if you want to avoid complex queries in your objects.

[mouse]

Thank you for the reply LuthfiHakim. I was just curious if you do this approach when you are developing systems or applications. Do you design the data schema first then objects? When do you identify object behaviors?

[LuthfiHakim]

mouse said:

Do you design the data schema first then objects?

Technically there is no definite order which one you must do first. In practice sometimes I do data schema first then objects, especially some system by nature coupled tightly with data structure (e.g. accounting application, order processing, reports). But mostly lately I started with analyzing objects behavior first, and then data schema.

Quote

When do you identify object behaviors?

Lately I started designing by identifying the basic object behavior first. In UML (unified modeling language) this step usually called domain modelling. It's identifying needed classes/objects and their relationships with each other. No fine details done in this phase, but I think it's qualifying as identify object behaviors.