There is another reason to have stored procedures: encapsulating logic across
apps/clients.
A great deal can be done in triggers, but not much in terms of queries or
complex parameterized updates.
It would be great, imo, if triggers could have durable local storage (ie.
variables) and if this were built upon to allow stored procedures, life would be
much more fun.
Parameterized multi-query SQL statements returning event just a single row set
would be fine.
On 16/04/2017 2:18 AM, Richard Hipp wrote:
On 4/15/17, Manoj Sengottuvel <smanoj...@gmail.com> wrote:
Hi Richard,
Is it possible to create the Stored Procedure (SP) in Sqlite?
if not , is there any alternate way for SP?
Short answer: No.
Longer answer: With SQLite, your application is the stored procedure.
In a traditional client/server database like PostgreSQL or Oracle or
SQL Server, every SQL statement involves a round-trip to the server.
So there is a lot of latency with each command. The way applications
overcome this latency is to put many queries into a stored procedure,
so that only the stored procedure invocation needs to travel over the
wire and latency is reduced to a single server round-trip.
But with SQLite, each statement is just a procedure call. There is no
network traffic, not IPC, and hence very little latency. Applications
that use SQLite can be very "chatty" with the database and that is not
a problem. For example, the SQLite website is backed by SQLite (duh!)
and a typical page request involves 200 to 300 separate queries. That
would be a performance killer with a client/server database, but with
SQLite it is not a problem and the pages render in about 5
milliseconds.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
