Ok guys - here's the deal.

I have a large database management and monitoring utility licensed under a BSD simplified license. It's a pretty decent and comprehensive utility, and it is currently in use at several large IT shops.

The problem is, it's written in .NET. It supports anything, but the main executable itself has always been relegated to a Windows server, just by happenstance.
I'd really like to move it to something more portable, and quite possibly something that allows you to make updates without compilation (like PHP, Perl, etc).

I'm looking for opinions and ideas - right now, it's about 15k lines and growing, so I want to make this change before I start work on the next version (due this summer).

Any ideas? Is C# just fine? Should I switch to pure C/C++? Perl? Ruby? PHP?

Is it resource intensive ? I'm betting so if large is large, so yeah I vote for C/C++. If it's not that intensive, you can just use perl, or any other language you prefer, other than java of course.

1 members found this post helpful.

ROFL

It is/can be intensive. At one shop it's monitoring about 12,000 database instances, so when it creates a backup, space, or SOX report it can definitely take a while.

The more important question is what's the DBMS? That will determine what languages have bindings available. Does it have client library that can transparently make remote connections to it?
Kevin Barry

1 members found this post helpful.

Right now it supports Oracle, SQL Server, DB2 UDB, and Informix (though not as well as I'd like). It runs natively at the moment on SQL Server or Oracle, though I'm planning to convert it to SQL Lite with this next release (with an install-time option to pick a different datastore).

I've been requested to add MySQL and MySQL MaxDB/SAPDB support, which is still beta.

<edit>
To respond more clearly to the second part of your question - no, there is no actual API for my App (it's just a database that can be accessed directly if you care to, a server piece that does the collecting/reporting, and a web or desktop frontend that just reports on data in the internal database or manages the collection and reporting) </edit>

But if you are managing to do it in .Net, I have to believe that most modern scripting languages will do since running on the CLR is not much different than running an interpreted script at least not when it's Perl or Ruby.

I was a Perl advocate for years, but I find Ruby to be its perfect successor for all sorts of utilities. Sure, C/C++ might be highly efficient, but porting such code would be more difficult than you think, I believe. I have run the same Ruby code on a number of platforms without difficulty. What I've seen with Perl is that there are often issues with compiling the code for some library especially db stuff using gcc, and that means we're right back to dependency on C/C++ which puts you close enough to the hardware to make it a pain.

I qualify all my remarks by noting that without a lot more details, it's problematic to make this call.

1 members found this post helpful.

I agree - I was thinking roughly along these lines, since C# isn't really know for being a speed demon.


I think my biggest concern with porting is the supporting libraries needed to do all the DB calls. Right now I have the advantage of piggy-backing on ODBC essentially. Perl has pretty robust database drivers that are mostly cross-platform, which does make that piece easier.

Of course But over-burdening with a huge pile of code wouldn't help anyone, and the specs are pretty simple

If you're comfortable with Perl, comfort level must be factored in. My experience with Perl vs. Ruby, however, is that Ruby far outshines Perl for database access library code. Someone may care to argue that point, but I'm almost always doing something with a database using Perl or Ruby. It's mostly Ruby for the last couple of years. At least since Ruby on Rails came along, there is all sorts of stuff for database access. I rarely resort to ODBC because I don't have to. And I just love Ruby's "ActiveRecord." It's a brilliant concept, and not a bad implementation.

In general, speaking from the limitation of my personal experience, I find that Ruby is more up-to-date with the latest in database access libraries. I think Perl is languishing. But, if you like Perl and can find the libraries you need, I have found that Perl's performance is very good.

1 members found this post helpful.

I see C, Java, and Ruby are currently tied at one vote each as of now

Regarding Perl - yes, I would say I have an extremely high (though maybe not Perl Monk level) comfort with it. I've heard of Ruby, though I have also heard it's largely hype which leaves me a bit uncertain on it.

I checked out PHP due to the hype recently (after writing it off as a horrid pile of steaming c*** a few years back) and found it had improved. A bit. I tend to think of it as "lightweight Perl that uses the browser as stdout", and have done quite a few web-shims with it.

I have a scientific program written in C++ and POSIX C that does direct work in a PostgreSQL database (no user intervention aside from creating users and the database) and I've outfitted it so it can be run by shell scripts by users or by e.g. a PHP front-end. You might consider the opposite approach and use a simple, high-level, somewhat-portable language to make the database calls (most of the work there is done by the database server) and piping it to a more-capable language to do the processing. If that language was C++ or Java you could write it so it would compile on anything (because it would be purely a data process) and you'd have a hybrid system that would probably run on anything. C++ (and I imagine Java) is no fun to write compound SELECT statements in; I've essentially had to write a compiler that generates SQL statements.
Kevin Barry

PS I'd never use C to access a database unless the statements were static, for no reason other than that dynamic string manipulation in C is one of the worst punishments you could wish on a programmer.

1 members found this post helpful.

That's a good point - now, I do a considerable amount of SQL and PL/SQL (being a DBA by trade), so obviously I am a big fan of having the database do the heavy lifting.

The main work the app does is polling/scheduling/executing/collating (things like running a space or user query in different formats depending on MS-SQL, DB2, or Oracle) and then producing user facing reports. If I understand you correctly, you're recommending using something like Perl/PHP/Ruby to run the queries and populate the DB, then something like C++ to create the graphs and charts.

That is definitely not something I had not considered before - I've been thinking more along the lines of doing it all in one language.

ROFL

Looks like the poll is split evenly there - so I'm going to do some prototypes in Ruby, Perl, and C... maybe even in Java.

If anyone else wants to toss some stuff in here, I'll be happy to consider it as well.
My initial testing with sqlite (1 million inserts, 1 million reads) vs mysql and oracle certainly showed that sqlite is a decent choice for the underlying DB. It was staggeringly quick even on a laptop. I think I'll use that as my default "internal" DB, of course allowing users to pick any data source they like during install.