What database features/elements are
necessary for a programmer to
understand in order to create
non-trivial applications?
Più esperienza con la progettazione e la normalizzazione del database, meglio è. Troppo poco (ad esempio, le tabelle non possono essere 1NF) può essere altrettanto grave (EVA).
SQL di base può risolvere la maggior parte dei problemi che possono essere superati facendo domande su SO.
Gli sviluppatori dovrebbero anche sapere cosa significa ACID , con un'idea di cosa significa.
L'altra cosa che gli sviluppatori dovrebbero sapere è che a volte accadono cose brutte alle transazioni e la tua applicazione dovrebbe aspettarsi che ogni transazione funzioni sempre. Ecco una citazione da un articolo di Rico Mariani
One Last Warning
If you consider what I said, about the
natural occurrence of failures in a
database, then you’ll soon realize
that it is normal, using Linq
parlance, for db.SubmitChanges() to
throw an exception from time to time.
If you are trying to write a robust
application with high reliability you
need to think about that.
In addition to obvious things like,
“the network went down”, “the database
went down”, there are less obvious
things like, “there was a deadlock”,
“there was an optimistic lock
conflict” that can and do happen.
Those latter two things should be
appropriately retried because nothing
bad has happened. The strategy you
choose, especially for cases where the
optimistic lock failed, can have a
profound impact on your performance
and certainly you can’t just let those
exceptions flow to the user. I think I
can safely say that my mom doesn’t
want to hear about how table X on
connection A deadlocked with table Y
on connection B.
If you’ve been reading carefully then
you’ll see that it’s also “normal” for
a foreach operation over a Linq query
to fail from time to time – you need a
retry strategy for those too to be
fully robust.
Don’t get down on Linq though, those
problems exist with all data
solutions, the productivity benefits
you get from Linq will go a long way
to helping you to add the robustness
you need in the areas you need it.
Don’t read “too much” at once. Don’t
write “too much” at once. Handle
deadlocks, they’re normal. Handle
optimistic lock failures, they’re also
normal. You should land in the Pit of
Success.
Per quanto riguarda quella linea nella sabbia? Direi che gli sviluppatori non hanno bisogno di sapere nulla sull'operazione fisica, dimensionamento, partizionamento, monitoraggio, (backup / ripristino), sicurezza, alta disponibilità, ripristino di emergenza, configurazione iniziale, ecc.