Importance for a program to be data aware? 1

[keyser456]

I'm currently developing a commercial application that will be using a datasource (SQL Server in most cases) w/ several tables. My last few attempts have ended up in the recycle bin after I became discouraged and knew I could do better. Now I'm basically starting over (minus the knowledge and experience gained from my past attempts) and see two basic options:

1 - I can design the database first complete with stored procedures. Then write a minimal amount of code to pull items from the database using simple forms and the stored procedures. In this case, the program really won't know much about the data it's pulling from or storing to the database.

2 - I can design the code first, implementing classes for every aspect necessary for this program. Then I could model the database after these classes. In this case, the program would be much more aware of the data and would act as the gatekeeper. Data validation would be much more clean since I could implement it at the class level, however this appears to be infinitely more work. Any changes made to code later may require changes to the database's design as well.

I was hoping to hear arguments for each side. Naturally, I want my program to be aware of what it's handling, but I want to make sure it will be worth the extra effort required before I decide. Thanks!

 

[stefanwagner]

I would model the data towards NF3, but perhaps not use stored procedures, since they are rdbms-specific and since I'm not firm in stored procedures.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[jfrost10]

It really depends on what the application has to do.

Personally, I'd do a combined analysis/design of hte application.

Putting all your eggs in the database basket (option 1) means increased overhead on the database server, because your stored proc's need to handle all the calculating. This is generally frowned upon, since it makes more sense to let the client machine handle that processing instead of overloading the database server.

Creating a great object model (classes) is the best way to approach it, although it does add work as opposed to just displaying data in some controls on a form...but again, it depends what your app needs to do. Classes are always preferred to just straight displaying on a form.

But the big thing is how do you model the requirements: database first, or class first. I say: both. When I do my requirements, I create a pretty static class diagram...nothing fancy as far as functions or anything, just fields, relationships, etc.

From there, I'll do my ERD for the database, and my class diagram...because databases have relationships, classes could have composition...so they have to be diagrammed differently, but they still come from the same base requirements.

hth

D'Arcy

 

[jwenting]

the fact that you say SQL Server in most cases tells me you should refrain from using code that's specific to any database engine.
That precludes stored procedures.

Rather create a database access layer that handles all database operations for you and make a rather dumb GUI on top of that (with maybe an additional layer for calculations and validation in between if those are more than trivial).