Foxpro Developer vs. DBA

[robsuttonjr]

I have recently moved from being the sole FoxPro developer/SQL DBA to a FoxPro development team which has a SQL DBA as 1 person solely responsible for all DBA functions. I am trying to push the point that FoxPro developers anymore should also be SQL DBA's to a point. It doesn't makes sense to me that we simply develop FoxPro code then have to go through a DBA to create stored procedures etc. I need to hear from others who have been in this situation and can offer any thoughts about this?

Regards,

Rob

 

[mkrausnick]

Ah yes, the owner-operator vs the hired gun. I've been in both places. The operative word here is discipline. The dedicated DBA as gatekeeper keeps the developer from negatively affecting the work of the end-user or other developers.

When you ran your own show, if it broke, you said "oops" and maybe "sorry about that" to the client, then fixed it and moved on. You were the only one affected. Now you're part of a larger more complex machine (the team) and your work affects other developers as well as clients, maybe even some who are not YOUR clients. Everyone can't have willy-nilly access to the database. It would be chaos.

You don't say whether multiple developers are working on the same project or database, but if they are, controls must be in place to keep one developer from stepping on another developer's work.

Then there's the issue of performance. The DBA knows (or is supposed to know) the larger picture relative to hardware resources, workloads, and the effect of specific operations or queries on database performance.

Unfortunately DBAs sometimes see themselves as gods. But a good DBA will implement your requests quickly and make suggestions for improvements in your SP code and help you avoid pissing off the overworked programmer in the next office.

Short story: play nice with the other kids and everybody gets along.

Mike Krausnick
Dublin, California

 

[Mike Lewis]

The issues that the other two Mikes have raised are very true, especially when the database is a back end like SQL Server or Oracle.

But when the database is the native VFP engine, the DBA functions are much more closely integrated with the development role. In fact, I can't imagine anyone other than an experienced VFP developer being responsible for optimising queries, creating stored procedures, managing triggers, etc.

A separate DBA could be responsible for things like backups and scheduling routine maintenance, but many of the traditional admin functions are really things that should be the preserve of the developer.

I'd be interested to hear what other think.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[robsuttonjr]

FoxPro is considered a 'database' application programming language. Using SQL, creating databses, manipulation of data programmatically, etc are all native and daily routine for most FoxPro developers in the business world. I don't see much difference between doing these tasks in FoxPro or SQL server other than syntax and other differences in methodology. I see FoxPro and Sql Server as a happy marriage. A FoxPro developer that creates Sql Server stored procedures is a far more powerful programmer with many more options in the bag of tricks. It allows such a developer to balance how much data manipulation occurs in FoxPro vs. Sql Server. For those of you who use FoxPro and Sql Server you probably already have found yourself putting more and more into Sql Server procedures which used to be exclusively done in FoxPro. A FoxPro developer who never creates Sql Server stored procedures may not know they can do this or that within a stored procedure which may lead them to embed more business logic into FoxPro. The benefit to companies that have more business logic embedded in Sql Server is to allow for an easier transition to .NET or Java. More and more companies are converting their FoxPro application to .NET. Lastly I would add that Sql Server is integrated into the .NET IDE. Developers of 'database applications' in my opinion should be a hybrid of developer of programs and database architects.

Regards,

Rob

 

[Nigel Gomm]

Rob,

In any team there should be clearly defined roles and responsibilities. e.g. The developer writes the code ; The DBA administers the database.
In most teams i would expect the developer to create the SP in his development environment and then submit it to the DBA for inclusion in the QA and production servers.
The DBA would have final approval over standards and conventions and will reconcile differing requirements from other developers and users.
Some DBAs like to write the SPs themselves... if you're not happy with that you can try sending him a working SP as a 'rough draft'. He can then concentrate on optimizing it. He's a specialist so hopefully you can learn from him. Whatever you do - BE HIS FRIEND.

Having your own development server and database will help avoid a lot of contention.


hth

Nigel