On Sat, 30 Jan 2016 23:03:29 +0000 Simon Slavin <slavins at bigfraud.org> wrote:
> > On 30 Jan 2016, at 8:13pm, Yannick Duch?ne <yannick_duchene at yahoo.fr> > wrote: > > > In my opinion (which some others share), OO is a bag of miscellaneous > > things which are better tools and better understood when accosted > > individually. Just trying to define what OO is, shows it: is this about > > late binding? (if it is, then there sub?program references, first?class > > functions, or even static polymorphism and signature overloading) About > > encapsulation? (if it is, then there is already modularity and scopes) > > About grouping logically related entities? (if it is, there is already > > modularity, and sometime physically grouping is a bad physical design). > > There are a number of problems in using a relational database for > object-oriented purposes. One is that to provide access to stored objects > you need to access the database in very inefficient ways which are slow and > are not helped by caching. [?] This matches what I had in mind with the short sentence ?And especially about OO and DB, I know there are complaints OO hides too much the data model of DBs?. I heard about an example with a video game engineer explaining OO typically impends efficiency for their use cases, in a way which can be related to a DB and its tables. Say an object has an attribute `x` among others. Say a big set of objects of this type is often iterated, but that's not really the objects which are iterated, that's their `x` attribute alone and no other attributes are accessed during this frequent long operation. Using OO, it is suggested `x` should be stored in the object instances (typically a kind of C?struct), so there is a large set of unused data coming with each `x` in an iteration, which prevents efficiency (poor caching, more memory access). In such a case, the `x` should not be stored in the object, rather in a dedicated list holding only the `x` attributes. That's about the same as with a DB when some columns are moved from a table to a specific table, while maintaining a relation between both. Where `x` should belong, that's not a conceptual picture about the attributes alone which says it, that's the typical operations referring to the attribute, which do, and that's as more important as the number of object instance grows. That's for a similar reason a DB may need to be refactored when new queries come, while from an OO point of view, this would just suggest to add a new method to an object, not to move `x` from the object to something else (something OO will never suggest). That's what make me agree a relational DB is not well suited to store objects (the models differ too much), unless the model of that object is broken down after the requirement of its individual operations, or the object instances are just to be stored as monolithic blobs. There are cases where the OO view matches well, and there are cases where it does not. There is no need to force one view to be the other. -- Yannick Duch?ne
