4 ms·

I don't get why you were downvoted, as this is so true. I'd rather throw hardware at a problem, than having to get developers to work on a rewrite on the databa

by sp4rki 16y ago

I don't get why you were downvoted, as this is so true. I'd rather throw hardware at a problem, than having to get developers to work on a rewrite on the database level. It's cheaper, easier, and totally not risky in comparison. I've always seen databases as an index storage layer and thought that "outsourcing" the apps job to the database while convenient in a lot of cases, are hell to maintain at scale.

jbooth 16y ago
Hey, you got downvoted too. Gave you a bump. Dunno why everyone's taking this so personally. It's like they're personally threatened and their approach is to get angry rather than try and understand.
- gaius 16y ago
  If I had to guess, I'd say that people are downvoting you because even the MySQL guys who spent the 90s arguing against it have now come around to thinking that foreign keys and transactions and stored procs are good things, and they can't be bothered to engage in the discussion again.
  - jbooth 16y ago
    My beef was PL/SQL and too much of the transactions/storedprocs thing. Foreign keys can be a good thing.
- sp4rki 16y ago
  ^^ I don't get it either. If someone doesn't agree they might as well say so and give reasons to get a discussion going. Instead we get this "Ohh the article said X so you're wrong, I'll downvote and move along" attitude. I guess people don't appreciate debating anymore.
ora600 16y ago
You are paying developers to rewrite features that already exist in the database and you think this is "throwing hardware at the problem"?
- jbooth 16y ago
  Snurf blerg schlep albargady! ^^ That's me deliberately misinterpreting your comment, beating the straw man with a killer counter-argument and declaring victory.
- sp4rki 16y ago
  No you got what I said wrong. I'd rather pay developers to keep the logic in the application and throw more hardware when I need more webservers, than pay developers to develop a 'database logic' solution and having to get them to rewrite for efficiency when the database starts getting blocked and saturated. It's always a good idea to plan for growth, as long as it doesn't mean delaying the app too much. So yes I rather keep my databases light and get the app to deal with the processing as much as possible, throwing a new webserver at it when the growth requires it.

by sp4rki 16y ago

jbooth 16y ago

Hey, you got downvoted too. Gave you a bump. Dunno why everyone's taking this so personally. It's like they're personally threatened and their approach is to get angry rather than try and understand.

gaius 16y ago
If I had to guess, I'd say that people are downvoting you because even the MySQL guys who spent the 90s arguing against it have now come around to thinking that foreign keys and transactions and stored procs are good things, and they can't be bothered to engage in the discussion again.
- jbooth 16y ago
  My beef was PL/SQL and too much of the transactions/storedprocs thing. Foreign keys can be a good thing.
sp4rki 16y ago
^^ I don't get it either. If someone doesn't agree they might as well say so and give reasons to get a discussion going. Instead we get this "Ohh the article said X so you're wrong, I'll downvote and move along" attitude. I guess people don't appreciate debating anymore.

ora600 16y ago

You are paying developers to rewrite features that already exist in the database and you think this is "throwing hardware at the problem"?

jbooth 16y ago
Snurf blerg schlep albargady! ^^ That's me deliberately misinterpreting your comment, beating the straw man with a killer counter-argument and declaring victory.
sp4rki 16y ago
No you got what I said wrong. I'd rather pay developers to keep the logic in the application and throw more hardware when I need more webservers, than pay developers to develop a 'database logic' solution and having to get them to rewrite for efficiency when the database starts getting blocked and saturated. It's always a good idea to plan for growth, as long as it doesn't mean delaying the app too much. So yes I rather keep my databases light and get the app to deal with the processing as much as possible, throwing a new webserver at it when the growth requires it.