Monday, August 22, 2016

This Week

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:

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

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"

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:

5 comments:

  1. There was also this answer :

    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.

    Wondering why this one was not included.

    ReplyDelete
  2. Either because I missed it, or it was added after I read it. But I will add it because it focuses on another problem: why the meaning of relations is not in the attribute names a la CJD.

    ReplyDelete
  3. A dumb question being analyzed so seriously by experts :D

    ReplyDelete
    Replies
    1. Actually I think it's the answers, not the question itself that will be "analyzed so seriously" ...

      Delete
  4. No, it's not a dumb question, it's a question that is due to lack of proper education and foundation knowledge. And it involves some very important fundamental issues.

    ReplyDelete