Comment Re:Foreign Keys (Score 1) 390
Wow. Just wow. Setting aside, for an instant, the whole DB issue, there is something fundamental that is being flat missed here.
In any proper development environment, robustness and exception management should occur at the lowest level possible. Always. A great app, written against a shaky O/S, running against bogus BIOS calls will never be a great app. Ever. Someone was sleeping during design 101 if they miss this fundamental design concept.
This is the only efficient, and only reasonable development strategy. You can't honestly expect to code "create socket - Did my socket really get created? - try socket out - did that really work?" and think that you've got something solid - no, you've just got a pile of inefficient code on top of a bad socket call that should have reliably returned a status and/or failed gracefully to start with.
The arguments I see against a solid DB design ensuring integrity boil down to one thing, and one thing only, "Gee, we only code in Ruby and that DB stuff is sooooo weird".
Please show me one instance, just one where it's ok to create a product shipment record against an order record that never got created. Explain to me just why a properly designed database should even allow such things from an application, then how it's any more efficient to check for the same potential pitfalls in a dozen pieces of application than it is to get it right at the lowest level to start with.
In any proper development environment, robustness and exception management should occur at the lowest level possible. Always. A great app, written against a shaky O/S, running against bogus BIOS calls will never be a great app. Ever. Someone was sleeping during design 101 if they miss this fundamental design concept.
This is the only efficient, and only reasonable development strategy. You can't honestly expect to code "create socket - Did my socket really get created? - try socket out - did that really work?" and think that you've got something solid - no, you've just got a pile of inefficient code on top of a bad socket call that should have reliably returned a status and/or failed gracefully to start with.
The arguments I see against a solid DB design ensuring integrity boil down to one thing, and one thing only, "Gee, we only code in Ruby and that DB stuff is sooooo weird".
Please show me one instance, just one where it's ok to create a product shipment record against an order record that never got created. Explain to me just why a properly designed database should even allow such things from an application, then how it's any more efficient to check for the same potential pitfalls in a dozen pieces of application than it is to get it right at the lowest level to start with.
