Monday, January 15, 2018

This Week and The End of Empire

1. Database truth of the week

"ALL names are human created, either by non-algorithmic assignment, or via some algorithm. We ONLY know that two types of objects are distinct because they have different sets of defining properties and, for a given object type, we ONLY know that two objects are distinct because the values (observed or measured) of that object type's defining properties are distinct. Names (of objects of some type) allow us to distinguish two such entities ONLY when they are 1:1 with the values of the object defining properties. Two sets of names (whether human assigned or machine generated) consistently identify the same set of entities ONLY when they are 1:1." --David McGoveran

2. What's wrong with this database picture?

"I have to maintain some lists in DB (SQLServer, Oracle, DB2, Derby), I have 2 options to design underlying simple table:

 dept   HR
 dept   fin
 role   engineer
 role   designer
UNIQUE CONSTRAINT (NAME, VALUE) and some other columns like auto generated ID, etc.
dept   {["HR", "fin"]}
role   {["engineer", "designer"}]
UNIQUE CONSTRAINT (NAME) and some other columns like auto generated ID, etc.
"There is no DELETE operation, only SELECT and INSERT/UPDATE. In first advantage is only INSERT is required but SELECT (fetch all values for a given NAME) will be slow. In second SELECT will be fast but UPDATE will be slow. By considering there could be 10000s of such lists with 1000s for possible values in the system with frequent SELECTs and less INSERTs, which TABLE design will be good in terms of select/insert/update performance." --SQL TABLE to store lists of strings,

I have been using the proceeds from my monthly blog @AllAnalytics to maintain DBDebunk and keep it free. Unfortunately, AllAnalytics has been discontinued. I appeal to my readers, particularly regular ones: If you deem this site worthy of continuing, please support its upkeep. A regular monthly contribution will ensure this unique material unavailable anywhere else will continue to be free. A generous reader has offered to match all contributions, so please take advantage of his generosity. Thanks.

3. To Laugh or Cry?

Q: "Is the WWW a relational database?"

A: "No, if you’re searching for a database metaphor for the World Wide Web, the closest would be a highly-distributed Network model database, with strong elements of Document-oriented databases. You don’t “query” the WWW - you traverse nodes as you would a network or Graph database, although search engines like Google provide some element of archival querying of the WWW. Like all network-model databases, “joins” on the world wide web are physical links (or at least indirect physical links) using URLs. The fundamental thing that distinguishes these types of data joins from relational database joins is that relational joins are always computed from the data."
A: "This is an interesting question. As others have said, the short answer is no. What is WWW then? And does it in any way relate to relation databases? WWW is the prefix you see on many URLs. (i.e. It is used by your browser to figure out where to send requests for web based information. Behind the scenes, a service called DNS is used to convert the URL into an IP address which your browser then uses to communicate with the web server. Many of the web sites that have a URL that starts with WWW utilize relational databases to store and manage the information that is presented by the web site. But many other WWW web sites use non-relational databases (like mongo) or no database at all (i.e. static web sites)." --Is the WWW a relational database,

4. I Told You So

"Those who are in love with practice without theoretical knowledge are like the sailor who goes onto a ship without rudder or compass and who never can be certain where he is going. Practice must always be founded on sound theory." --Leonardo DaVinci

5. Publications

  • NEW! The Key to Relational Keys: A New Perspective, forthcoming.

6. Housekeeping:

To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the FUNDAMENTALS page. For detailed instructions on how to understand and use the labels in conjunction with the FUNDAMENTALS page, see the ABOUT page. The 2017 and 2016 posts, including earlier posts rewritten in 2017 are relabeled. As other older posts are rewritten, they will also be relabeled, but in the meantime, use Blogger search for them.

7. Oldie but goodie

Fabian Pascal Interview: Data Management's Misconceptions

 8. Elsewhere

9. The Data Industry

10. Of General Interest

11. Some Serious Stuff

And Now for Something Completely Different: A Failing Empire

 "The  stages of the rise and fall of great nations seem to be:
  • The Age of Pioneers (outburst)
  • The Age of Conquests
  • The Age of Commerce
  • The Age of Affluence
  • The Age of Intellect
  • The Age of Decadence.
Decadence is marked by:
  • Defensiveness
  • Pessimism
  • Materialism
  • Frivolity
  • An influx of foreigners
Decadence is due to:
  • Too long a period of wealth and power
  • Selfishness
  • Love of money
  • The loss of a sense of duty.
The life histories of great states are amazingly similar, and are due to internal factors. Their falls are diverse, because they are largely the result of external causes."  --Sir John Glubb, THE FATE OF EMPIRES AND SEARCH FOR SURVIVAL (William Blackwood and Sons, 1978)

Lessons From The Last Time Civilization Collapsed and here's a current example: Iran May Be On the Verge of Civilizational Death. So America Is Not Yet Lost? Judge for yourself:

Books of the week

Video of the week

    MUST WATCH: A Good American

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

    Do you like this post? Please link back to this article by copying one of the codes below.

    URL: HTML link code: BB (forum) link code:

    No comments:

    Post a Comment