Yes, please include it in the FAQ along with a description of the SQLite stored procedure pattern syntax which is never disclosed in these replies:
CREATE TRIGGER my_sproc INSTEAD OF INSERT on my_sproc_caller_view BEGIN --My procedural code to be prepared and stored in the database. END; --Called by the following syntax with specific VALUES(): INSERT INTO my_sproc_caller_view VALUES(); --And results returned in the requisite my_sproc_work_table upon which my_sproc_caller_view is created. As for the chattiness of client/server DB's, there is a more frequent cause of that inefficient pattern. In particular, there is often a ham fisted design which keeps vital model data in application code or in tables which are not SQL joined to get the final result. Often the vendor will encourage the same incompetent programmers to recast their inefficient queries within the bodies of stored procedures as proof that the firm needs to buy much larger and more expensive hardware and requisite software licenses. [Filed under vendor contracts for $435 hammers and $600 toilet seats.] On Sat, Apr 15, 2017 at 11:33 AM, Christian Werner < christian.wer...@t-online.de> wrote: > On 04/15/2017 06:18 PM, 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. >> > > May I vote this conversation to be included in the SQLite FAQ. > > Best, > Christian > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
