Hi Graeme,
As mentioned in one of the earlier replies, it really depends on the
complexity of the application and the state of the Business Rules.
If I have a detailed definition of the Business Rules (a really rare
occurrence), I will start with the BOM and UI. I sometimes build in
some data fixtures without ever touching the database till I am
reasonably sure that the BOM/UI and Fixtures describe the Business
Rules. Then I will start moving the fixtures into the schema one or two
at-a-time with constant testing.
When I don't have a detailed definition of the rules (the usual case), I
start with top-level rules and one or two top-level tables, their
associated BOMs and UIs. After each set of BOM/UI/Tables I sit down
with the customer and demonstrate what I have so far. We then agree on
any changes that must be made and we iterate till that set of
requirements are being satisfied. Often we also agree on what part of
the rules should be implemented next.
Most of the time, the customer "waves her hands" to describe what the
program must do, so it is up to me to actually start developing the
Business Rules. When that happens, the second approach helps by
reducing the amount of throw-away code required till the customer gives
his/her approval. (Especially when the customers are my own daughter
and grand-daughter).
My most recent project was a translation of a pre-Windows c++ program
with a CLI for the user interface and no database into Lazarus with
sqlite3. Since the rules were well established, just implemented with
very old technology, I used the first approach and it worked very well.
I had almost the entire program working in test mode before I had to
touch the database for production.
Hope this helps.
Don Ziesig, ROP (Really OLD Programmer);-)
On 06/26/2015 07:30 AM, Graeme Geldenhuys wrote:
Hi,
Last night I was working on a relatively new project. This got me
thinking... How do others tackle such a task?
So here is my question:
When faced with a new database related project, where do you start? Do
you first design the database schema, then build the BOM (Business
Objects) accordingly? Or, do you first design the BOM, then design the
database schema to fit.
Personally, most of my project were started by first creating the
database schema. Don't ask me why, that is just what I did. Maybe it was
because many of the tools I use, can write much of the boiler plate code
for me, and they do that by querying a database structure. But I've been
thinking that with my next project, I'm going to start with the BOM
first, and see how it goes. I'm assuming the end result should be the
same, no matter which part I tackled first.
What's your thoughts?
Regards,
- Graeme -
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
