I wrote on Friday night about my experiences that day.
I am a very opinionated person. I believe, whole-heartedly, that the database is severely under-utilized, especially at my current employer.
I believe that one of the big draws of MySQL is that it's easy for web/application people to pick up. I also believe, in our situation, that's it's a way for application developers to skirt the whole "data" problem. They'll just pawn it off on the Production DBAs to keep the database running.
Amusingly, some of our application developers brought down one of our Oracle instances, more than once. Pretty tough thing to do I always thought.
I've read articles on bind variables since the beginning, but since it had been drilled into me, I found it quaint. Who would do that?
From a C# app someone passed in hundreds of thousands of un-bound INSERT statements. It flooded the shared pool (is that right?) and brought it to a screeching halt.
Anyway, back to the point.
I've been very vocal lately about MySQL. A few of my friends have begun to warn me that I may be crossing the line towards arrogance. That I will come off as someone resistant to change.
I don't see it. But sometimes we're the last to see our own reflection.
I don't believe that I am resistant to change. I like change. I just want it to be proven, that's all. I embraced ApEx because it made my life easier. That's all I want.
Does this make me arrogant?
3 comments:
Arrogant has the wrong connotations. Lets say that you come across as highly confident.
And no, I don't think it is arrogant to point out that right now Oracle is years ahead of MySQL in terms of features, stability and maintainability.
On one hand, I fully believe that MySQL is a well marketed but barely functional DB. On the other hand, YouTube is running on MySQL, so maybe it is better than I imagine.
You can view MySQL as a huge opportunity, though. Oracle world is full of great theory and practices. The nice folks at OakTable worked on it for at least 10 years. MySQL, OTOH, has non of it. MySQL developers have no idea how often to commit, when to rebuild indexes, how to tune performance, etc. Well, maybe they have some idea, but not in the methodological and scientific way that Oracle folks like.
You said you want to be Tom Kyte? Maybe this is your chance.
Good point.
I like Oracle better though and I've spent way too much time learning it...I'm not giving up on Mr. Kyte just yet. :-p
Speaking to one of our VPs today (he's graciously heard me out on this), he offered me training on MySQL. I think I'll have to accept to truly see what it can do.
No, you're not being arrogant; and yes there are quite a few people out there (myself included) that share your views. Personally, I think it stems from the culture of disorganization that we seem to be building.
If you take a closer look, a whole lot of the applications that use MySQL (or PostgreSQL or other 'light', open source DBs) are not very transactional.You mentioned YouTube; how much of what they do is transactional? Heck, the last I heard, even Google used MySQL in considerable part; but how much of what they do is transactional???
I share a lot of your sentiments too. For quite some time, I've felt that there are just too many web apps out there that treat the database merely as a data store- basic table-per-entity/screen, no referential integrity design. Surprisingly my current PM say's that on all of the projects he's worked on, they never used foreign keys! (I know, YIKES!!! :S)
I know it seems pretty bad, especially with Rails getting getting way too much air time. I mean, if you just want an application that that babysits a DB, why should you have to write ANY code at all!?! ApEx does most of that just fine. This is going to take a cultural shift, if not a paradigm shift.
Another interesting observation is that most developers today seem to view the DB as an internal component of the application. That might hold true for small apps where the user doesn't care much for configuration, but any decent sized organization is already using applications from other vendors that require DBs which they host on centrally. I don't think they're going to be very excited about installing a whole new DB just to run your app. And I don't think the people who maintain those DBs (might I say DBAs at the risk of being slandered by agile/ruby/rails/mysql proponents!) feel very comfortable with your 'application' automatically running 'migrations' on their DB every time it builds/deploys.
Post a Comment