Re: Is a RDBMS needed?
Date: Mon, 27 Jun 2011 09:22:28 -0500
Message-ID: <BANLkTi=NXkE2xkL3vTp0HJ-PXDzDe2ja8A_at_mail.gmail.com>
I have to say that my experience is exactly the opposite. Java developers I have tried to work with rarely had a good understanding of PL/SQL, and often had no idea how to even edit their SQL or PL/SQL code that was generated by their Java code generator. Most often they just took whatever was generated from their tool, and told me they had no idea how to modify the SQL code (with the unspoken statement that obviously since the code was generated, it must be right, and the database wasnt set up right). Most of the PL/SQL developers I have worked with have been happy to to work with me to improve their code.
On Mon, Jun 27, 2011 at 9:00 AM, Dba DBA <oracledbaquestions_at_gmail.com>wrote:
> 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.
>
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-lReceived on Mon Jun 27 2011 - 09:22:28 CDT