Peering into Data Management - 5/5
To get past the stigma around cheating in exams, I call it a #Lifehack. (Taken from: https://www.matrixmath.sg/)

Peering into Data Management - 5/5

Part - 4 is here.

Surprise Quiz, folks.

Below are five questions to test your DBMS knowledge. DBAs and anyone developing DBMS software should be able to answer at least three. The average dev should be able to answer at least two.


Questions:

  1. Explain ACID properties.
  2. Explain BASE properties.
  3. Explain the CAP theorem.
  4. What is implied by Referential Integrity?
  5. How many clustered indexes can a table have - one OR more than one? Both answers are correct with proper reasoning.

No alt text provided for this image
Scroll down for answers

Answer - 1:

ACID properties are guarantees that a DBMS can provide.

Atomicity - If I'm starting a transaction, all transaction steps will be complete, or none will.

Consistency - implies that finishing a transaction should take the database from one consistent state to another. Hence, appropriate constraints, cascading ops, and triggers should kick in when executing a transaction.

Isolation - guarantees that when multiple transactions are going concurrently, then at the end of all the transactions, the DBMS should be in a state that it would be in if the transactions had happened serially. The order of serialization doesn't matter. {T2 -> T1 -> T3} is an acceptable order, even if T1 was started before T2 and T2 was started before T3.

Durability - implies that after a transaction is finished, if the DBMS crashes even one millisecond later, the transaction should be preserved when the DBMS is revived.


Answer - 2:

BASE acronym exists because it is easier to remember that it is the opposite of ACID.

Basically Available - The reads in a distributed system will be available, even if not consistent.

Soft State - The update to a value may not have propagated throughout the system, so a value's read will be softly correct, sometimes returning a stale value. It's essential that while you may be returned a stale value, you will never be returned a wrong or garbage value.

Eventually Consistent - If you stop issuing any new transactions, your entire distributed system will become consistent in some time, and all reads will return the same (correct) value.


Answer - 3:

CAP Theorem (also called Brewer's Theorem) says that out of the following three, only two can be guaranteed in a Distributed System:

  1. Consistency: When a value is written, all reads will return the same latest version.
  2. Availability: A non-failing node will give a response in a reasonable time. No infinite hanging and no error are acceptable.
  3. Partition Tolerance: A distributed system will continue functioning in the face of a network partition.

Eventual Consistency implies prioritizing Availability over Consistency so that the system is more responsive, even if returning stale values.


Answer - 4:

In DBMS, where data is referred between tables (using foreign keys), the idea that the data is not valid in just one row or table but across the entire database is called Referential Integrity.


Answer - 5:

The clustered index follows a table's physical order of data; therefore, only one clustered index for a table is possible.

However, you can always create a view on a table. Some DBMSs allow you to create a clustered index on a view. So you can leverage that to create a view over the table as 'SELECT * FROM MyTable;' and then create a clustered index over this view.

This way, you get another clustered index of a table by creating a full copy of the table. So more than one clustered index of a table is possible by paying O(n) space costs.


The end.

要查看或添加评论,请登录

Anilesh Sharma的更多文章

  • Man on the Moon - 7/7

    Man on the Moon - 7/7

    Part - 6 is here. Recursive application of PPP We can assume that creating a rocket object is not a single-line…

  • Man on the Moon - 6/7

    Man on the Moon - 6/7

    Part - 5 is here. PPP template for Unit Tests The proof of the pudding is in the eating.

  • Man on the Moon - 5/7

    Man on the Moon - 5/7

    Part - 4 is here. Maintaining consistent abstractions If, at any time, for any method, we need more than seven plain…

  • Man on the Moon - 4/7

    Man on the Moon - 4/7

    Part - 3 is here. We can delve into the first comment - “// Take a man” - and write code for it.

  • Man on the Moon - 3/7

    Man on the Moon - 3/7

    Part - 2 is here. Pseudocode Programming Process Instead of jumping into writing code, start with writing steps in…

  • Man on the Moon - 2/7

    Man on the Moon - 2/7

    Part - 1 is here. Writing code for humans Simple explanations are a strong marker of clear understanding.

  • Man on the Moon - 1/7

    Man on the Moon - 1/7

    We need to (1) take a man, (2) put him on the moon, and (3) bring him back. This is not an attributable quote, and I am…

  • Peering into Data Management - 4/5

    Peering into Data Management - 4/5

    Part - 3 is here. Since the DBMS architecture is mature, there are two ways to create a new DBMS: Making changes to…

  • Peering into Data Management - 3/5

    Peering into Data Management - 3/5

    Part - 2 is here. The architecture of a DBMS Here is the high-level architecture of a DBMS.

  • Peering into Data Management - 2/5

    Peering into Data Management - 2/5

    Part - 1 is here. DBMS taxonomies Unless developing a DBMS, most devs are okay with a surface-level understanding of…

社区洞察

其他会员也浏览了