Re: Is a RDBMS needed?

has anyone on this list ever used this tool? If its a university setting,
the scaling concerns may not be real high anyway. The time to develop may be
faster and the costs lower since you don't have to pay a DBA, the developers
can do everything, and the developers are too lazy to learn how the database
works. On small to medium sized projects these kinds of things work well. In
certain special implementations outside the box systems work (Google,
facebook). However, the people who work on the higher end implementations
tend to be some fo the best people in our business and are typically far
better than the developers on our teams.

I am not close  minded to other solutions. However, on larger projects, I
see issues with it. I have been on alot of different projects. From small to
large. From 5 people to 400. From oltp to datawarehouse, to a mixture of
both. I am not going to say no to something just because I am a DBA. I think
DBAs make that mistake since databases is what we know. The java guys throw
out their cliches about how "we don't want to do anything in the database"
and about how "we don't want to write sql because databases are hard and
slow". DBAs then throw out the cliche "we think its better to do everything
in the database". DBAs say that since that is typically all they know. Yes
there are exceptions on this list who know far more than just databases, but
in general most DBAs do not.

One big problem that people here are overlooking is that there isn't alot of
talent out there that knows how to code and develop in an rdbms. Most DBAs
are operations DBAs and do not have time to code or even really help the
developers unless and until there is a problem. Showing up at a design
review without being familiar with the requirements or the functionality
leaves the DBAs unable to really provide good feedback. On the flip side,
DBAs generally don't show alot of interest in learning this. Most of the
reason is we don't have time and there are not enough resources to free
people up to do this. Most teams have really scaled back on the number of
development DBAs on a team. Most DB people on the development team are just
pl/sql developers and the quality of pl/sql developers is very low. They
only know pl/sql and sql. Some know a little unix scripting. Most do not
know enough about the operational side of DBs to be a DBA.  Further most
pl/sql developers write really lousy loop based code, do not know how to
tune queries. and in general are not very good. Companies are typically
cutting back on people who only know pl/sql.

Another problem that happens when you have pl/sql developers and application
developers on the team is that you get a random hodgepodge of code in the
database and code in the application. This makes the application far more
complicated. Basically managers will grab whoever is available to do
something instead of deciding making a strategic decision on what goes
where. To make things worse, pl/sql developers do not know any application
code. The java developers will know pl/sql (and since the pl/sql developers
are often pretty bad) they often know as much as the pl/sql developers. I
have even seen development DBAs that absolutely refuse to log into the
application. They cannot even test their code since they won't use the
application. This also limits their functional knowledge of the application
and their usefulness to the team.

I think the best solution for DBAs to make is to improve our coding skills
and to learn the functionality of the application. Log into the application
and see what it does. Learn how the application language that the developers
are using works. Code in it outside of work some to learn it somewhat. Try
to get the java guys lingo (they do have their own internal lingo). We can't
control what developers can do, but we can improve our own skills. If you
learn to talk to developers like a developer its easier to get them to
listen to you. You will also have better suggestions since you understand
the application better. Alot of this just comes from talking to developers
and asking questions. I have found that developers are frequently willing to
share information if you show interest.

Other related posts: