Beau Wilkinson wrote: >>> There are still people who just want >>> a cursor to a chunk of data which they pull in and iterate over rather than >>> use SQL's power to manage data a set-at-a-time >>> > > 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. > > >>> Call me old fashioned but object-relational mappers worry me on this score >>> > > I agree, except that you're not old-fashioned. In fact, I think you're on the > cutting edge here. OO (including any attempt to apply it to database work) is > no longer trendy. At best, it is tolerated... perhaps many people still > haven't admitted that the proverbial emporer has no clothes, but no one's > bragging about his (i.e. OOP's) new jacket, either. > > Microsoft, for example, is moving rapidly to functional programming and > generic programming. Implementation inheritance has been lobotomized in C# > compared to C++, for example, and Microsoft's new "Linq" database client > technology is functional and generic. > > As for ORM, OODBMS (whatever that is), etc. proponents of such technologies > continue to hem and haw about "object-relational impedance." This is just a > fancy way of describing the problems that result when a good (Relational) > model of reality must interface with a dysfunctional (OO) model. OO creates > problems (or "opportunities"...) because it doesn't work. MIT has been saying > this for 30 years. Few people are willing to consciously stick their necks > out and say, "you know, I've always thought OOP was a bunch of B.S" but the > sentiment's out there and it's justified.
I believe this is too broad a condemnation. Every approach has limitations and areas where it is more or less useful; Object Oriented programming is no exception, and the fact that OO has been misused does not in and of itself support the assertion that it is "dysfunctional". To highlight two examples, functional languages such as Haskell are elegant and pure...until you add petty, non-deterministic things such as I/O and user interactions. Monads are a workaround, and even their physical and syntactic representation demonstrate the limitations of the pure functional approach. Example two is an oft asked issue with SQL in general. One of the most common needs of a system which interacts with a human being via a graphic interface is the ability to reference an object by its position within a given resultset. Although there are many workarounds for this issue, workarounds they are and a strategy which is both fast and non-cumbersome for accessing the nth element in a given resultset via pure SQL continues to elude the profession. The fact that monads are cumbersome and SQL cannot easily return results which can be accessed as though they were an array are not indictments of Haskell or SQL. Likewise the obvious issues of attempting a simple mechanism for persisting in-memory objects to an auxiliary storage medium are limitations of the Object Oriented approach, and, in my opinion, should not be considered a condemnation of Object Oriented design as a whole. Our organization has been using OO based languages for over a decade and, while we have encountered cases where other approaches are superior, we have found it in general to be an excellent method for solving our client's problems. FWIW John Elrick Fenestra Technologies _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
