luisrossa
Posts: 2
|
| Posted: 06/19/2007, 5:47 AM |
|
Hello all,
My question is a generic one.
I would like to hear your opinon about this subject:
In our Code Charge Projects there is (almost) always a relational database envolved which acts as the data repository.
The queries are responsible for filtering the data the software wants to display or to process.
What I would like to hear from you is the following:
What would be a good reason to put the queries along with the data in the database ?
What would be a good reason to put the queries in the Code Charge project ?
Thanks in advance for your replies.
|
 |
 |
klipkop
Posts: 16
|
| Posted: 06/19/2007, 7:57 AM |
|
It depends on your system management approach and the type of relationships you have in the DB.
Whenever you will UPDATE,DELETE from joined tables - best is to use stored procedures (SP) in the database. You then invoke the SP from within Codecharge by pasing the variables on.
By system management. Although SP's takes longer to code and call from codecharge you can
1. Re-use them all over codecharge
2. Manage any updates to your queries centrally in the DB rather than in every place.
The long and the short is - if it's a quick and dirty smallscale project - do it in Codecharge. If its a longterm, data intensive site - go the SP route
Maybe someone can add - disagree ?
|
|
|
|
E43509
Posts: 283
|
| Posted: 06/20/2007, 6:29 AM |
|
General rule of thumb ...
Do presentation logic (how it looks) in the web code.
Do heavy lifting of data (complex joins, views, ...) in the database.
If you have a complex query, create it as a view in the database since it will run much faster than sending the query over the wire to be parsed.
I do like Stored procedures as klipkop references above.
|
|
|
|
luisrossa
Posts: 2
|
| Posted: 06/25/2007, 2:59 AM |
|
Thank you, both klipkop and E43509.
|
|
|
|
|
