would update t-sql to be a more robust language, maybe then I'd do more
stored procs.
I've also never figured out a good way to create a stored proc for searching
a table if your search terms can be any combination of several items. The
only way I've done that is with a dynamically built query within a stored
proc and from what I gather, you lose all speed benefits with that design.
--
marlon
> Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
>
> > I don't think there have been convincing arguments that SPs help from a
> > security standpoint, but from a performance standpoint I don't think
> > it's debatable.
> >
> That is a myth. Stored procedures are only faster than dynamic queries;
> not prepared statements. In fact, in some cases it is possible for a
> stored procedure to actually be slower than a dynamic query.
>
> > 1. Stored Procedures allow developers to encapsulate business logic
> > and
> > provide users (programmers) with a simple interface to that logic. The
> > user doesn't need to know how they work, just what they do.
> Business logic shouldn't be in the database. It should be in the
> business tier where it belongs.
>
> > 2. By "hiding" database structure details behind stored procedures,
> > DBAs
> > can reduce the need to change other components (client
> > applications/middleware components) whenever they need to change the
> > database structure.
> The database structure should be abstracted by the data access layer of
> your application.
>
> > 3. Reduced network traffic. The more business logic that can be
> > implimented on the server (SPs) the less data will be transferred back
> > and forth through the network.
> Again, business logic shouldn't be in your database. Further, with the
> high-speed interconnects we have today, data transfer simply isn't an
> issue.
>
> > 4. Faster execution than ad hoc queries.
> >
> Again, this is a false statement.
>
> -Matt
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
