On Mon, 27 Jul 2009, Beau Wilkinson wrote: > I am dealing with such a project now. The schema consists of time stamp > plus blob, where the blobs "map" directly to C++ structs. Of course, there > are all sorts of useful data items in those blobs, and many of the > capabilities of SQL are lost by reducing data to blobs. I think this is an > extreme example of what you describe. The architectural excuse given was, > I think, performance.
I'm not a professional coder or DBA, but I've been writing code and building database applications for about 3 decades. The problem, I believe, is shifting paradigms and the difficulties people have in doing so. The original spaghetti-code model I used with FORTRAN in the early 1970s gave way to structured programming with C. Most of us still effectively use structured programming with procedural languages, either compiled or interpreted. While OO is a nice concept, and does have use in the appropriate applications, it produces bloated binaries because all classes in the hierarchy need to be compiled and included, even if one function is all that's needed. However, even within the huge tribe of procedural languages, there are different paradigms that one needs to understand to most efficiently use a language. The differences between C and Common LISP immediately come to mind. Regardless, it is very common to see those new to SQL take whatever knowledge and experience they have with procedural languages and try to apply it to working with sets. Your project summarized above seems to be an example of this. Trying to apply the flow control and other structures of a procedural language to SQL tends to result in a mess. Too few books or other resources stress these differences so newcomers are taught to look at the whole database manipulation language (principally the SELECT statement) in a different way. What is more unfortunate is when someone with greater knowledge takes over a project but is prevented from re-doing it in a more efficient way because someone else's ego will be bruised or the powers that be cannot appreciate the need. Rich -- Richard B. Shepard, Ph.D. | Integrity Credibility Applied Ecosystem Services, Inc. | Innovation <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
