"jeff archer" schrieb >From: "Olaf Schmidt" >Wednesday, November 10, 2010 9:07:19 AM > >>[Stored procedures in SQLite] >> >>IMO stored procedure-support only makes sense in >> "Server-Instances" which run on their own...
> I disagree. The overall design and structure of > applications using SQLite and therefor SQLite itself > would benefit from SQLite supporting stored procedures. > This would allow all code necessary for enforcing the > business rules of the data to be stored in the database itself. > This is just a good basic design principal. There was a somewhat similar sounding post (from BareFeetWare, sent on 20.Oct to this list) who also encouraged, to include "more logic" into the SQLite-Files itself, to reach more "portability". All nice and well, but the problem is two-fold IMO. Portability with regards to Application-Code (exchangeability of "The DB" among different languages) and on the other hand, portability of the Data (the DB, the "Backend"). >From my experience one should use "DB-internal mechanisms" only in a range, which is common among different DB-engines (Triggers for example, to ensure referential integrity at least). But a "Stored-procedure-language" which is more or less proprietary to a certain DB, does not work out that well, if your Application (or your Business-Layer with your "business-rules") needs to be able, to talk to a different backend (since your new customer "just made the wish"...;-) Then backend-portability is required - and the less voluminous and complex your "special code" in your current DB-backend is, the faster will be your switch to a new backend (using the App-language for the business-rules then, supported by some sort of "DB-Abstraction-Helper" of course - as e.g. JDBC, ODBC - or ADO/OLEDB in the Windows-world). And if you want to ensure (aside from easy backend- portability), that your "business-rules" (your business- layer) survives "App-language-switches" as well, then you should encapsulate it in a component (a Dll for example) - containing a public reachable API, which is usable/callable from different languages then. If such an "encapsulation of business-rules" is sitting in the DB itself - written in a proprietary "DB-dialect", then you cannot call such a thing a "business-layer" anymore. A layer is a thing, sitting "in-between" (to abstract from two sides, in this case the App-language(s) *and* the Storage-Engine(s)) ... and not a thing "sitting inside somewhere". Just my 2cts... Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
