<li>Why does a RDBMS require a structured datatype for each column? I&#x27;m wondering what the advantages are of requiring this as opposed to letting the user input what they want. Does it help with the amount of space used by the database or prevent errors?
<div class="ans">
    <p>Great question! Well, as you recall, we have to define a datatype for all our columns: int, datetime, char(9), varchar(30), etc.</p>
    <p>Why is that? Here are some reasons:</p>
    <ul>
        <li>correctness: if you know something is an integer or a datetime, the database can reject any input that isn't correct.
        <li>speed: if you know something is an integer, you don't have to put in run-time code to check its type and possibly convert it to the correct type.
        <li>compactness: if you know the datatype of something, you don't have to store any type information, either in the database or in memory once the data is read from disk.
    </ul>
    <p>All of the reasons above are the same as in programming languages. Consider Java (strictly typed) versus Python (dynamic typing).
</div></li>

<li>How do you handle relationships between collections in MongoDB if you can&#x27;t use joins?
<div class="ans">
    <p>Great question! There are several ways:</p>
    <ul>
        <li>denormalize: store something in multiple places. For
        example, the name of an actor in a movie could be stored in
            the movie's cast list, avoiding having to look it up.
        <li>Explicit lookup: have the middleware (Python/JS code) look
        up the movie, then do look up each of the actors in it. This
            requires multiple database interactions, but hopefully it's rare.
        <li>Modern MongoDB has a <code>$join</code> operator, so you
            can do a join in the database.
    </ul>

</div></li>

<li>Could you explain what does it mean that denormalized MongoDB documents can lead to inconsistency across shards?
<div class="ans">
    <p>Sure. That's another great question.
    <p>Suppose that someone whose name is "Ellen Page" has been in
multiple movies and those movies (and their cast lists) are in
different shards. (Denormalized the actor name information.)
    <p>Then Ellen changes his name to "Elliot Page" and we have to
        update the database.
    <p>There might be a time, hopefully brief, when the name has been
    changed in some shards, but not in others. So the database as a
        whole is inconsistent.
    <p>This can't happen in a normalized database, because the name is
    only stored in one place, so the update is atomic. But with
        denormalized data, we have to chase down all the copies.
    <p>Brief inconsistency is maybe not a problem in the WMDB, but we
    can try to come up with examples where it is: maybe a banking app
    where there needs to be global consistency. Or an e-commerce site
    where you can't sell somethign more than once.
</div></li>