Sunday, August 20, 2017

This Week

1. Database Truth of the Week

“... [one] limitation imposed by set semantics is the inability to express the concept of a computer variable to which values can be destructively assigned (or "updated") ... variables can be expressed in logic, but they cannot be expressed in elementary set theory, or first order predicate logic (FOPL) -- the foundations of the RDM. Other, more expressively powerful systems are required. Unfortunately, such powerful formal systems do violence to the RDM and its intent.” --David McGoveran

2. What's Wrong With This Database Picture?

"In my experience, using an object model in both the application layer and in the database layer results in an inefficient system. This are my personal design goals:
- Use a relational data model for storage.
- Design the database tables using relational rules including 3rd normal form
- Tables should mirror logical objects but any object may encompass multiple tables
- Application objects, whether you are using an OO language or a traditionallanguage using structured programming techniques should parallel application needs which most closely correspond to individual SQL statements than to tables or "objects".

3. To Laugh or Cry?

" of cloud-scale hierarchical filesystems as a replacement for object stores. Object stores have much in common with NoSQL databases. Both arose from scalability limitations in hierarchical filesystems and relational databases, respectively. However, many NoSQL databases are now being replaced by NewSQL systems that overcome the scalability limitations of single-node relational databases, but maintain the strong consistency guarantees of relational databases. Sometimes, you can have your cake and eat it." --Jim Dowling,

4. Publications

NEW!!! Paper #2 in the new UNDERSTANDING OF THE REAL RDM series, Logical Symmetric Access, Data Sub-language, Kinds of Relations, Database Redundancy and Consistency, is available for ordering here.

Paper #1 in the new UNDERSTANDING OF THE REAL RDM series, Interpretation and Representation of Database Relations is available for ordering here.



5. Oldie but Goody

On Grinding Water - Reply to St. Laurent

6. Of Relevance Elsewhere

7. Of Interest

And Now for Something Completely Different


This Week @The PostWest:

  • My Take of the Week
  • How I Know America (and Western Civilization) Is Finished!
  • Internal Collapse
  • External Demise
  • Anti-semitism, Hypocrisy, the Myth of a "Palestinian Nation" and the Peace Process Delusion
  • Pinch Me of the Week
  • Book of the Week

Dystopian Utopia: The Sillicon Valley State -- Mechanism of Tyranny and Destruction of Free Civilized Society

Tech companies banishing extremists after Charlottesville is a two-edged sword that America will live to regret.
See what I mean? 

Note: I will not publish or respond to anonymous comments. If you want to say something, stand behind it. Otherwise don't bother, it'll be ignored.

1 comment:

  1. "Tables should mirror logical objects but any object may encompass multiple tables" Any man can have one wife but any wife may relate to multiple men. Technically speaking, there is nothing wrong with that. Unfortunately, we're not in a technical business :-) And to those interpreting this word "mirror" in a very rigid one-to-one sense, the blatant contradiction should be obvious.

    What's wrong :

    "Use a relational data model for storage." (1) The kind of model that illustrates the structure of the world that is of interest to a business problem owner, is best called an information model, not a data model. (2) And of course relational illustrations of a business problem are not used "for storage", but for documenting the "logical nature/structure of the problem (and/or its solution). (3) And of course most likely the author confused fully formal logical models (which relational information models ought to be) with conceptual models (which are always informal to some degree) such as ER diagrams, but there is not enough material in the quote to evidence this suspicion.

    "Design the database tables using relational rules including 3rd normal form" Nothing wrong with that of course, though is best for the author to be aware of what 3d normal form actually really means, precisely. And I suspect that is far from certain.

    "Tables should mirror logical objects but any object may encompass multiple tables" Even if you consider a set of "tables" and a set of "objects [or classes thereof]" as distinct design artefacts, any designer should realize that there is still only one business problem, and that both the set of tables and the set of object classes should never be more than distinct incarnations of the very same single semantics : those of the business problem. It may be the case that the author is insufficiently aware of that, and its consequences for the degrees of freedom he has when doing his design work around the problem.


View My Stats