Comment by swasheck | Hacker News Reader

Comment by swasheck | Hacker News Reader

Parent Full thread

I'm a dba so yes I can remember DBAs. I don't understand the condescension from you comment. As a DBA, I have never understood the argument of a mutating database as a solid justification. It just sounds lazy/unprepared, at best. Sure, there may be a valid complaint for the unicorns out there, but they represent such a small percentage of situations that I hardly see how ther experiences necessarily translate to everyone else's situation. "It's hard" or "it's difficult" sound like blame-shifting to cover for a lack of actually understanding requirements.

I don't mean to single you out in this comment. The reality is that your comment just really reiterates so many of the same arguments that are regularly trotted out as justification.

NoSQL already came and went. It was called ISAM. It has a use case, but it's not the silver bullet everyone wants it to be.

Oh yeah, as a DBA, I've loved hearing how NoSQL was going to do away with my job and that I am a 39 year old dinosaur who'd better catch up and get on board with DevOps. Guess who runs data CI where I am? Guess who manages our Mongo and Redis servers. Yep. The ancient DBAs.

How about some vitriol?

You know what the #1 feature of nosql is? NoDBA.

I can hear you screaming you'll still need a DBA. You don't get it. You won't need an Enterprise DBA.

Enterprise DBAs are almost invariably horrible blockades to data storage in any enterprise. All they do is lock away the database from developers, cram Oracle down their throats, do things as slowly as possible behind ticket walls. You lock the data away pining for your halcyon mainframe days of white coats and clean rooms, and force your slow ponderous overtenanted infrastructure.

Your profession, since you have proudly identified as a DBA, you are an Enterprise DBA, is a disgrace.

How about some vitriol?

How about not? Bad actors can be found in all domains, DBAs included. Painting all with such sweeping brushes does little to suggest people should take your comment seriously or advance the conversation constructively. There are also plenty of DBAs who know the strengths and weaknesses of many different data models, engines, and platforms, and work with developers to make decisions to ensure efficient data storage and IO for a successful application.

Edit to add:

Your profession, since you have proudly identified as a DBA, you are an Enterprise DBA, is a disgrace.

If you identify yourself as a DBA you must be an enterprise DBA? There are plenty of DBAs who are happy to dig into backend or frontend code as well, but have a lot of experience working with database systems. Many frontend and backend devs have experience working with databases, and similarly describe themselves to focus on their strengths. Are they enterprise frontend and backend devs?

To add to this point as well; agile methodologies work best when everyone is a generalist and the business is onboard with being involved in the development process.

DBAs are specialists which makes them inherently siloed.

I find your perception of DBA work to be quite narrow. Too many comments on here are based purely on colloquial evidence and not enough actual communication and understanding.

I'm afraid most NoSQL usage forces programmers to become, for all practical purposes, expert DBAs, or performance would be bad.

Using SQL requires competence too, but learning nonstandard exotic idiosyncrasies of a certain configuration of a certain bleeding edge system (the blood is yours) is much less useful than principled and somewhat standard techniques that can be readily adapted to any good RDBMS.

For example, there's a substantial difference between improving performance of a slow query by trial and error, rewriting application code to figure out what the current version of a bug-ridden interpreter/optimizer likes, and improving performance of a slow query by ENGINEERING, creating an index according to the reports of analysis tools, back-of-the-envelope estimates of size and performance and true understanding of different index types.

I'm sorry you've had such poor experiences with Enterprise DBAs. It sounds like you're drawing upon your personal experiences to make generalizations about a profession. We all do it, but professionalism requires us to step back from our frustrations and work together for the good of the team/organization/company/purpose.

As an Enterprise DBA, I know I have to be ready to be an SME on any number of topics at a moment's notice. I have to understand my data structures and logical modeling, I have to understand IO patterns and concerns (RAM and physical storage are the ones that crop up the most often for me), I have to understand security, I have to understand networking. I'm sure that you also have to consider many of these things as well so I'm not better than anyone, I'm just doing my job.

On top of that, I also have to make sure that my organization's best interests are considered. So if I'm slow to fulfill your request, or even if I say, "no, I can't do that" please don't take it personally. It's just that there are other things to consider than what you need right now and what you think is what you need to do what you need to do as fast as possible. Some times the "fast and easy" way to do things isn't the correct way to do them. Let's figure out a way to work together to do what needs to be done correctly the first time so that we're not plastered on an HN article that says, "why I moved from MySQL to Mongo to PostgreSQL."

Reply on news.ycombinator.com