title: EF Core - why ClientSetNull is default OnDelete behavior for optional relations (rather than SetNull)
body: <p>For optional relationships (when Foreign Key can accept <code>Null</code>), a new <code>ClientSetNull</code> behavior has been introduced since EF Core 2.0 as the <strong>default</strong> option for delete behavior <code>DeleteBehavior.ClientSetNull</code>.
  This has <code>SetNull</code> semantics for tracked entities and <code>Restrict</code> (no action) behavior for database records not loaded into memory.</p>
  
  <p><a href="https://i.stack.imgur.com/06XFK.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/06XFK.jpg" alt="Cascade Delete behaviors"></a></p>
  
  <p><a href="https://docs.microsoft.com/en-us/ef/core/saving/cascade-delete" rel="noreferrer">Microsoft docs</a> say that:</p>
  
  <blockquote>
    <p>If you want the database to also try to propagate null values to child
    foreign keys even when the child entity is not loaded, then use
    <code>SetNull</code>. However, note that the database must support this, and
    configuring the database like this can result in other restrictions,
    which in practice often makes this option impractical. This is why
    SetNull is not the default.</p>
  </blockquote>
  
  <p>But I think it is usually normal to set FK of dependent entities to Null when the associated parent is deleted (every where in db). And also, what's those "other restrictions, which in practice often makes this option impractical.." as claimed above?</p>