Database Reference
In-Depth Information
Predictability
This section could just as well have been titled "standards compliance," but I decided
against it because the benefits of standards compliance in corporate projects are not
obvious. The limitations of the common databases are well documented, and I will
show you a few websites in a moment where you can make a comparison of who has
the most "unintended behavior". I encourage you to read the material while thinking
to yourself about the question, "Which method of feature development is most likely
to make my application break in the future?"
Spoiler alert
: Stricter adherence to standards comes at the cost of not allowing am-
biguous behavior. Not allowing ambiguous behavior makes the developer's life more
difficult. Making the developer's life more difficult ensures that the interpretation of the
commands that the developer gives will not change later, breaking the application.
Just how lazy can you afford to be? I'm not sure how to measure it. PostgreSQL is
available for no cost future predictability, so I don't have to answer the question.
Sure, PostgreSQL also has some bugs listed. However, changes to the database core
have a tendency to make the engine work like the documentation says it does, not like
the documentation should have said. The PostgreSQL developers don't have to say
"oops, I didn't think of that", very often. And when they do, PostgreSQL just becomes
more standards compliant.
