1. Quote of the Week
Karen Lopez: To bring others up to speed, Fabian is using an academic taxonomy for data modeling terms. It's valid. It's popular in research. It's not used in any major data modeling tool, nor in many practitioner resources. I have been using the industry vernaculars in my posts and here. Part of the debate that Fabian is having is because he does not tolerate the industry terms, so he chooses to attack others who use the mainstream terms. He believes they are "wrong" instead of "alternative". So that's part of the pain we have in debating his positions. I'm bilingual, but I choose to use just one set in my writings.
Fabian Pascal: Karen, bollocks. See, I can use non-academic terms too.
When, years ago in an online exchange, I argued that working with SQL DBMS's without knowledge and understanding of data and relational fundamentals is a costly proposition, an Oracle practitioner replied that "they train doctors on how to use medical devices, not teach them the theories behind them". I asked him what do doctors learn in their six years of medical school, but got no reply.
I have documented and debunked for decades the substitution of tool training for education and the ensuing "cookbook approach" to database practice it produces. While I have become more jaded, it is still difficult to run so frequently across something like
1. Quote of the Week
NULL values can be very useful, especially on indexes, as an indication of "index is not set" or "no index here", or "default inherited index applies".
I use Null values extensively (in huge database systems) with not only no problems whatsoever, but measurably signifcant advantages. People who try to tell you that "Nulls are the work of the devil", or :the sky will fall down if you allow nulls", or some such unsubstantiated childish delusion are exclusively ignorant of the correct ways to handle them. (Or too lazy/ineducable to learn their correct implementation and/or benefits.)
Fact, just plain indisputable fact. --bytes.com
My January post @All Analytics.
"Logical refers to the relationships among the components of the
relation, not to any arrangement of the components of a relation. Any
presentation that preserves those relationships and adds no extra ones
is acceptable. An R-table is one possible such presentation. The problem
is that people fixate on this one presentation, identifying it with
relation. They then go even further and force the physical
implementation of a relation to be table-like." -- David McGoveran
Read it all. (Please comment there, not here)
1. Quote of the Week
I don't know that I would say that the RM is dead per se, or even holding us back. But I have to ask... why the relational model? ...A Hierarchical Model would work. In fact if we look at these NoSQL databases ... Hierarchical Models work better than relational models. The point is that some of the factors which cause one to think in terms of relationships have changed. Disk is cheap. There are definitely problems where having a strongly typed and structured model make sense. Then there are problems where not having a rigid model make sense. Structure on read seems to make sense these days. PS... Relational models don't scale. Especially on MPP.
--LinkedIn.com
A serious problem in the database field is not just that many data professionals do not know and understand the RDM, but also that they believe they do and criticize it. It is relatively easy to detect such critics. In "Recognizing and Treating Tableitis" Gordon Everest tries to be humorous, but it ends up more sad than funny.
1. Quote of the Week
Table (n.) – a collection of information (data?) describing a population of entities which possess some common characteristics, called attributes. Tables are the building block of relational databases. Tables must generally be “normalized,” at least to 1NF. That may be an appropriate way to think of databases when implemented in a modern day DBMS. However, it is not the way the world thinks logically. People have no problem with commonly occurring phenomena such as:
* A multi-valued attribute, e.g., an Employee possesses multiple Skills.
* Many-to-many (M:N) relationships, e.g., as between Employees and Projects
* A relationship with attributes
--Gordon Everest, Recognizing and Treating Tableitis
