Follow @DBDebunk Follow @ThePostWest

Pls see PAPERS page for the current version of this paper, when it becomes available.

Follow @DBDebunk Follow @ThePostWest


Conveying the theoretical foundation of database management to practitioners without losing either precision/rigor, or the audience is a non-trivial endeavor, the skill for, or interest in which very few possess. More often than not one or the other are lost.

In Relations and Relationships I referred to the following LinkedIn exchange:

AT: ... William Kent and his book "Data and Reality" [1978] ... is devoted to "attributes", and (in my words) William confesses that he can not distinct [sic] between "relationships" and "attributes". Thus, the later might be completely redundant. 

GE: This confusion of entities vs. attributes has been with us a long time. Several years ago [a student] ... discovered a paper ... that discussed this dilemma. He proposed calling the thing, which we could not determine whether it was an entity or an attribute, an "entribute." Beautiful, eh? That was in 1939.

Follow @DBDebunk Follow @ThePostWest


1.  Quote of the Week

As you might have gathered, I think NoSQL is technology to be taken very seriously. If you have an application problem that maps well to a NoSQL data model - such as aggregates or graphs - then you can avoid the nastiness of mapping completely. Indeed this is often a reason I've heard teams go with a NoSQL solution. This is, I think, a viable route to go - hence my interest in increasing our understanding of NoSQL systems. But even so it only works when the fit between the application model and the NoSQL data model is good ... And of course there are many situations where you're stuck with a relational model anyway. Maybe it's a corporate standard that you can't jump over, maybe you can't persuade your colleagues to accept the risks of an immature technology. In this case you can't avoid the mapping problem.
--martinfowler.com

2. To Laugh or Cry?

Which database type to use (one big database or many smaller)?

3. Online

Check out the last update's exchange--more comments have been posted since:

RELATIONAL DATABASE

4. Elsewhere

Set In Stone

5. And now for something completely different

Multivitamins Doctors Say Stop Taking Them

Half of U.S. adults take vitamins, supplements routinely

Draw your own conclusion.

Follow @DBDebunk Follow @ThePostWest


To all my readers and colleagues, happy holidays and a healthy and prosperous new year!

Follow @DBDebunk Follow @ThePostWest

I've finally found a concrete case to share that demonstrates most of the costly consequences of what happens when you engage in database practice without a good grasp of data fundamentals. A web application developer authored the article describing this case. The developer is competent enough to give an excellent post-facto description of the project that enables assessment but, as is usually the case, fails to associate problems with poor foundation knowledge. That's where I come in.

Follow @DBDebunk Follow @ThePostWest


1. Quote of the Week

If SQL is based on relational algebra which is based on set theory where the concept of null set (empty set) is an axiom of the theory. In this theory empty set is not the same thing as nothing. A point that confuses many people.

Relational algebra is based on 3VL predicates, that is, the answer to any predicate can have three states true, false or unknown. Unknown is caused by the use of a operator on an the absence of a value (null). Within relational algebra null is not to be treated as a value but merely a marker of unknown (absence of a value).

None of this is rocket science and I suggest doesn't result in bad implications. I suggest the so called "bad implications" are only introduced as people use null as a patch for problems for example the division by zero. indeterminate state, open ended ranges, data states to name a few. That is, the issue is not the concept of null but its abuse as a patch for other issues. 
--LinkedIn.com

2. To Laugh or Cry?

Why You Should Never Use MongoDB

3. Online debunking

RELATIONAL DATABASE

4. Elsewhere

Next gen NoSQL: The demise of eventual consistency

5. And now for something completely different

23andMe Is Terrifying, But Not for the Reasons the FDA Thinks

Follow @DBDebunk Follow @ThePostWest

WS writes:

I thought Happiness is a glass half empty might be suitable for the "and now for something completely different" part of the site.

Sadly the museum of failed products doesn't contain any software products, but I suspect that if it did, it would contain a lot of products that were going to definitely replace the relational model. I also suspect that many of these products would be reiterations of previously failed products marketed under a different name.

I think there are also some interesting points about how some people believe that their talents are innate and others believe that anything can be learned, given enough time and effort. I wonder if there is some connection between overestimating one's abilities and believing one has an innate talent for some discipline. From my own personal experience I would say that I have often overestimated my abilities when I believed I had a gift for some subject. If I have struggled hard to master something then I generally have a better idea of how much I still have to learn.

I have also found that having a better knowledge of the theory of data management has helped me to see clearly at the start when something is doomed to failure.

If 'replacement' is used in the theoretical sense, I've always claimed that an alternative to predicate logic and set theory as a formal basis for database management is a rather tall order, to put it politely. What is more, if DBMS designers and users don't even know what a data model is, or that database management is impossible without one, what is the chance that some such alternative will emerge?

If used in the implementation sense, we can't really talk of replacement of what was never truly and fully implemented and adopted--SQL is hardly it. As to relabeled reiterations, those who don't know the past...

In general there is an instinct to believe better of oneself than is justified. It is an important objective of intellectual development, of which the scientific method and theoretical foundations are a core element, to bound that tendency and bring overestimation closer to reality. This explains the common disdain of many data professionals who are only tool trained, but not educated, for what I refer to as the tyranny of knowledge and reason, that "robs them of their "freedom" to do whatever they happen to think is best"to achieve the purpose.

The article refers to failed consumer products that "nobody wanted to buy". There is an important difference between most of those and technological foundations on which they are based: either you like them immediately upon use, or you don't--it's a matter of sheer, opinion, preference, or taste. The same attitude to theoretical foundations can lead to serious trouble which will materialize in the long term. It is training without education that tends to induce the notion that nothing but innate talent and practice/experience are sufficient for competence.