Magnitus (70) [Avatar] Offline
#1
Section 1.2.3:

This sentence caused me to pause my reading and ponder what the author meant:

Companies that want to capture and report on exception data struggle when
attempting to use rigid database schema structures imposed by RDBMS systems.


The example right after this sentence clarifies a lot, but that sentence is still a bump that disrupts the flow of the reading and frustrates the reader.

Maybe something like?: Companies that want to capture and report on data applying only to a few specific entries struggle when attempting to use rigid database schema structures imposed by RDBMS systems.
Magnitus (70) [Avatar] Offline
#2
Re: Personal Feedback
Section 2.5.2:

I think this sentence would be expended into it's full meaning or scrapped:

In BASE systems, the information and service capability are "basically available."


Overall, the description of "Basic Availability" and "Soft-State" are so similar that one of the 2 terms seems redundant (other than making a cool BASE acronym which complement ACID well for those who remember anything from their chemistry classes).
Magnitus (70) [Avatar] Offline
#3
Re: Personal Feedback
Section 3.2, page 53:

I'm not an RDBMS expert, but I found this sentence confusing...

Repeating fields are associated with parent rows by referencing the parent's row identifier.

Took me a few seconds to realize the book was referring to rows referencing other rows (most often in other tables) in a one-to-many relationship.

I've never though of it as a parent-childs structure and though I can see how it could be viewed that way, I'm thinking it might be confusing to readers who are not accustomed to thinking about it in those terms.

Also, they are not "repeating fields", they are distinct rows in a one-to-many relationship (which would be more intuitive as repeating fields, but can't be because of the database's architecture).
Magnitus (70) [Avatar] Offline
#4
Re: Personal Feedback
Section 3.3:

I think this whole section can be resumed like this:

The row store architecture of RDBMS doesn't support joins by itself. Rather, the support comes from low level design patterns on top of the row store.

Because of this, the row store architecture is not well equipped to express the close relation of certain rows in different tables (ex: an order in one table and it's items in the other table) and capitalize on this relation by only storing related rows from various tables in close physical proximity (ie, on the same node) as opposed to entire tables.


I think the above 2 paragraphs are the crux of what the author is trying to convey, but as it is, it is conveyed in a very round-about indirect manner.

The need to partition tables into related components that are more like objects (and the difficulty of achieving this out of the box in RDBMS) for more efficient storage is strongly implied toward the end of the section, but not directly stated.