Design and Performance question

Hi
I'm working now on a project that is Database oriented, and this
Database is so big and has millions of records, my question is:
Where must I put the business logic?
1- Client side: where client is responsible for the business logic.
2- Server Side: exceute the business logic in the server using stored
procedures and triggers...
3- Hybrid schema load balancing on the two sides.
I'm using MS.SQL Server2000
I have many of very complex queries, and many of complex views.
and finally can I depend on Jobs in MS.SQL Server in some tasks with
out impact the perfermance down.
Please reply ASAP
thanks a lot.
I try to put it where it is best suited.
Anything set based which acts on a large amount of data should be in stored
procs or performance will suffer.
Always interface with the db via SPs as you can monitor and correct problems
and change the database tructure without changing anything outside the db.
Anything not set based is up to you and may just depend on the avalability
of development expertise.
You can rely on jobs. Whether they mipact anything depends on what they do.
"Yousef Absee" wrote:

> Hi
> I'm working now on a project that is Database oriented, and this
> Database is so big and has millions of records, my question is:
> Where must I put the business logic?
> 1- Client side: where client is responsible for the business logic.
> 2- Server Side: exceute the business logic in the server using stored
> procedures and triggers...
> 3- Hybrid schema load balancing on the two sides.
> I'm using MS.SQL Server2000
> I have many of very complex queries, and many of complex views.
> and finally can I depend on Jobs in MS.SQL Server in some tasks with
> out impact the perfermance down.
> Please reply ASAP
> thanks a lot.
>
|||"Yousef Absee" <youstec@.gmail.com> wrote in message
news:1131554866.394769.115640@.g47g2000cwa.googlegr oups.com...
> Where must I put the business logic?
> 1- Client side: where client is responsible for the business logic.
In the bizClasses that are called by the GUI and directly interact with the
db. If that is via metaData it's even better.

> 2- Server Side: exceute the business logic in the server using stored
> procedures and triggers...
Well sure, These rules may not be business rules but basic data handeling
instead. Triggers that generate data in other tables for necessary reasons
is a good thing.

> 3- Hybrid schema load balancing on the two sides.
> I'm using MS.SQL Server2000
> I have many of very complex queries, and many of complex views.
> and finally can I depend on Jobs in MS.SQL Server in some tasks with
> out impact the perfermance down.
Depends on what the job is to do and what is happening at the same time?