Journal Chacham's Journal: Verbiage: Tim Gorman rants on "DB independence" 8
Tim Gorman ranted about Database independence (thanx to Hemant for the link). Nothing too special, but it's a good point that not everyone gets.
My favorite line is: It is clear that, upon retrospection, in-house applications *rarely* have a need to be "database independent", but rather that databases have a need to be "application independent".
A co-worker pointed out the final line as his: Question authority -- especially IT people who have embedded the word "architect" into their job title...
Oh, how true.
moof (Score:1)
Not to take away from the point of the blog post, with which I agree, but I also agree with the featured comment at the end:
I too subscribe to the db being an efficient data store, and this means letting it sort and filter records on queries like its optimized to do, but
Re: (Score:2)
When a crapload of people / clients are going to use the exact same query over and over.
Put it in a Stored Procedure so it can be optimized, and you also remove the processor intensive SQL parsing out of the equation. This leads to a massive performance gain.
Other than Queries, and an occasional insert statement wrapped in a Stored Proc to simplify things, I agree.
Consider this (PostgreSQL):
CREATE TABLE foo (
SomeString text,
DMetaphoneCode text,
D
Re: (Score:2)
The only good reason I've ever seen to use a trigger is logging - and that isn't always necessary anymore with some products as they've added built in stuff as part of their security.
What is best then (Score:1)
for when db executes a command and gets updated data (external to organisation) which is then parsed and added to db. Data reflects current state of something and you want changes (above threshold X) notified to certain people, processes and or systems. Or is the type of logging you mean in a very general sense.
Re: (Score:2)
I mean logging in the security sense. Recording who does what in the database.
Everything else I'd probably rather see in the application. Data coming from outside is going through an app -- let it do the work.
Database independence is overrated (Score:2)
You end up stuck with the lowest common denominator, and before mysql development picked up, that was really damn low. Even now, there's a lot of stuff out there that's either non-standard or is standard but isn't supported in everything.
You can have my PostgreSQL SELECT DISTINCT ON () when you pry it from my cold, dead hands.
For... (Score:1)
For someone who has 25 years of development experience, he must be amazingly lucky to have never gone through an acquisition or merger which required a new database platform. In my paltry few years compared to him I have seen at least two. Sometimes the corporate overlords don't care what your product runs on the back end, but other times they demand a database different from what your product currently runs.
I agree with Bill Dog above on his view of triggers, and I would assume stored procedures also. I
Re: (Score:1)
I can understand having to implement a stored procedure for a true performance issue, but just because it is faster than executing on the client is not a good enough reason. Developer time costs a lot more than hardware, so your developers need to know everything that is happening as quickly as possible. Having to switch from Java, C, or whatever language the product is developed in to PLSQL or whatever other language is a cost of developer time.
The cost is saved by having a standard library for DB operatio