Follow @DBDebunk Follow @ThePostWest

1. What's wrong with this picture?

"Can you have 2 tables
- VIEWS
- DOWNLOADS
with identical structure in a good DB schema (item_id, user_id, time). Some of the records will be identical but their meaning will be different depending on which table they are in. The "views" table is updated any time a user views an item for the first time. The "downloads" table is updated any time a user downloads an item for the first time. Both of the tables can exist without the other.

"I don't think that there is a problem, per se from a E/R modelling point of view, as long as they represent two semantically different entities."

"Are you saying that both tables have an 'item_id' Primary Key? In this case, the fields have the same name, but do not have the same meaning. One is a 'view_id', and the other one is a 'download_id'. You should rename your fields consequently to avoid this kind of misunderstanding."

 "Chris Date and Dave McGoveran formalised the Principle of Orthogonal Design. Roughly speaking it means that in database design you should avoid the possibility of allowing the same tuple in two different relvars. The aim being to avoid certain types of redundancy and ambiguity that could result."

"When designing a DB there are lots of different parameters, and some (e.g.: performance) may take precedence. Case in point: even if the structures (and I suppose indexing) are identical, maybe "views" has more records and will be accessed more often. This alone could be a good reason not to burden it with records from the downloads."

--Can you have 2 tables with identical structure in a good DB schema?, StackOverflow.com

2. Quote of the Week

"<From the tabular point of view, does it make sense why we can't have duplicate rows in a relation?>

John Sullivan: As with everything else in life, it depends what you are trying to do (and exactly what you mean when you talk about a DBMS table v. a formal relation). From an operational (transactional) database point of view, for obvious reasons, you don't want duplicate rows (enforce a natural key). But if you're analysing data from various legacy sources (e.g. spreadsheets) it might be useful. Then again, you might introduce a surrogate key to give you more control over what's going on - again, depends on what you are trying to do." --LinkedIn.com

3. To Laugh or Cry?

Unified Data Modeling for Relational and NoSQL Databases

4. Of Interest

Imperative vs Declarative Programming

And now for something completely different

The PostWest (The future of the West is all behind it)
See if you can detect a pattern:

• Google to power Stanford Medicine's Clinical Genomics Service
• Arianna Huffington steps down from HuffPo to Launch a Health and Wellness Company
• Bill Gates Has Spent $1+ Million To Get Mark Zuckerberg's Software In Schools
• The Economist becomes a family affair
• Billionaire Launches Free Code College in California
• Uber and Lyft Want to Replace Public Buses
• Secretive Alphabet division funded by Google aims to fix public transit in US

No? Then perhaps you will if you consider some of the consequences:

• Theranos: Marketing Trumps Science
• Aetna to Drop Some Affordable Care Act Markets
• Immigration Attorneys: Industry Pushes Foreign Labor, Claiming 'US Students Can't Hack It In Tech'
• UCSF chief makes millions from firms doing business with hospital
• Why LinkedIn should kill the résumé and replace it with the experience graph
• Confessions of a Community College Dean Cognitive Dissonance
• Uber introduces upfront surge pricing because math is for nerds

Pinch me of the week

Woman caught texting with hands, steering car with foot

Video of the week

Christopher Hitchens on Donald Trump & Hillary Clinton

Book of the week (purchase via this link to support this site)

Rajan, R. J., and Zingales, L., SAVING CAPITALISM FROM THE "CAPITALISTS"