3 ms·

Programmers avoid working with DBAs because programmers think of SQL and databases as an annoyance that gets in the way of just shoving data into a hole somewhe

Programmers avoid working with DBAs because programmers think of SQL and databases as an annoyance that gets in the way of just shoving data into a hole somewhere. This is why MongoDB et al are so popular; they've provided cover for programmers to drop any pretense that organized data is useful. The end result is a continuous stream of data catastrophe after data catastrophe, and thousands of wasted man-hours trying to figure out how to do something with Mongo/Hadoop/whatever that is simple with a SQL server (and often reaching incorrect conclusions anyway). I'm not saying there's never a good reason to use a doc DB like Mongo or a "Big Data" implementation like Hadoop, but programmers don't choose to use these things for good reasons 95% of the time. They choose to use them a) because they're new, and they want the resume points; and b) because they allow them to shed the pesky DBA and the pesky database engine, always in their hair about the "Right Way" to do things so that the data can be recalled and analyzed quickly, easily, and repeatably. There is absolutely a flip side to this too, where DBAs behave in a massively unjustified manner toward non-DBAs. IMO the heart of the issue is the bifurcation in roles. Both DBAs and traditional coders are programmers/developers. Both should be trained in the others' concerns and expected to help out in both parts of the system, and the role distinction of 100% DBA or 100% non-DBA should not exist. This keeps balance in the incentives on both sides.

Pxtl 10y ago
My problem, as a developer, is how much database behaviour seems actively user-hostile. The horrifying implications of tri-value logic and the lack of a modern type-system to allow us to have a sensible alternative to NULL is infuriating. The bipolar attitude about how normalizing data is so important but how so much falls apart when you actually have normalized data. How infuriatingly hard basic, sane code-reuse is. "Don't use scalar UDFs" basically screams out to me "this is a bad programming language". Is it any wonder that developers go running to NoSQL solutions? It's not "relational algebra" that they're running from - schemaless behavior is just gravy on top of escaping dealing with the muddy, deceptive black-box world of databases. The database takes care of everythign until it doesn't.
- cookiecaper 10y ago
  Yeah, this is actually a great example of why it's important that if you're developing an application, you need to do some of its database work, and if you're developing a database, you need to get into the application and write code that accesses the database. If you're a hobby programmer and do full-stack stuff on your own to make your dreams real, you organically stabilize on a pretty-reasonable balance between database-side accommodation and application-side accommodation. Since you have to feel the full impact of the tradeoffs made, you select the most efficient, reasonable tradeoff available in the large-scale sense. When you introduce a hard separation between data-side and app-side responsibilities, it's just human nature to get that complexity off of your plate and onto theirs. This competition to put the burden on the other group burns bright and causes massive resentment between DBA and dev. Unify the roles and watch this disappear. Psycho DBAs who insist on fifth normal form everywhere will gain an appreciation for data locality and consider trivial bloat in table size an acceptable tradeoff, because it will make their application-side code tasks much more tolerable. Self-important developers who treat the DBA like their personal data lackeys will gain an appreciation for good data organization and reporting facilities, because it will make their database-side management and reporting tasks much easier. Database and application are too tightly coupled to ever successfully divorce the areas of responsibility. You just end up with people at each others' throats all the time. Merging the responsibilities (and thus the incentives) is the only way you'll get these two groups to adopt a unified perspective.

Pxtl 10y ago

My problem, as a developer, is how much database behaviour seems actively user-hostile. The horrifying implications of tri-value logic and the lack of a modern type-system to allow us to have a sensible alternative to NULL is infuriating. The bipolar attitude about how normalizing data is so important but how so much falls apart when you actually have normalized data. How infuriatingly hard basic, sane code-reuse is. "Don't use scalar UDFs" basically screams out to me "this is a bad programming language". Is it any wonder that developers go running to NoSQL solutions? It's not "relational algebra" that they're running from - schemaless behavior is just gravy on top of escaping dealing with the muddy, deceptive black-box world of databases. The database takes care of everythign until it doesn't.

cookiecaper 10y ago
Yeah, this is actually a great example of why it's important that if you're developing an application, you need to do some of its database work, and if you're developing a database, you need to get into the application and write code that accesses the database. If you're a hobby programmer and do full-stack stuff on your own to make your dreams real, you organically stabilize on a pretty-reasonable balance between database-side accommodation and application-side accommodation. Since you have to feel the full impact of the tradeoffs made, you select the most efficient, reasonable tradeoff available in the large-scale sense. When you introduce a hard separation between data-side and app-side responsibilities, it's just human nature to get that complexity off of your plate and onto theirs. This competition to put the burden on the other group burns bright and causes massive resentment between DBA and dev. Unify the roles and watch this disappear. Psycho DBAs who insist on fifth normal form everywhere will gain an appreciation for data locality and consider trivial bloat in table size an acceptable tradeoff, because it will make their application-side code tasks much more tolerable. Self-important developers who treat the DBA like their personal data lackeys will gain an appreciation for good data organization and reporting facilities, because it will make their database-side management and reporting tasks much easier. Database and application are too tightly coupled to ever successfully divorce the areas of responsibility. You just end up with people at each others' throats all the time. Merging the responsibilities (and thus the incentives) is the only way you'll get these two groups to adopt a unified perspective.