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.