>> Rich Shepard wrote: >>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.
I think my knowledge is just broader than my predecessor on that project. He cultivated a really detailed knowledge of the Windows / Intel platform, which didn't seem to allow any time or brainpower to learn about more general concepts. I try to be more of a generalist, although it can be unpopular. My colleagues seem to prefer to pick a single nascent technology and cling mightily to it until they perceive something better. Trying to discuss architecture with people who do that is like talking to someone in a cult... no matter what the topic or question is, the discussion eventually flows back to You Know What. The sad result is that I end up gravitating toward maintenance programming, simply because the arguments have already been had. ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On Behalf Of Rich Shepard [rshep...@appl-ecosys.com] Sent: Monday, July 27, 2009 10:46 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] What is a Relation? 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 The information contained in this e-mail is privileged and confidential information intended only for the use of the individual or entity named. If you are not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and delete any copies from your system. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
