LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

View Poll Results: Best language to switch to
Leave it C# 0 0%
Switch to PHP 0 0%
Switch to Perl 2 33.33%
Switch to C 1 16.67%
Switch to Java 1 16.67%
Switch to Ruby 2 33.33%
LOLCode FTW 0 0%
Voters: 6. You may not vote on this poll

Reply
 
Search this Thread
Old 01-06-2010, 10:56 AM   #1
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Rep: Reputation: 57
Question Opinion/Advice: Best language to which to convert a large Database monitoring utility


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?
 
Old 01-06-2010, 11:41 AM   #2
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
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.
Old 01-06-2010, 11:47 AM   #3
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Original Poster
Rep: Reputation: 57
Quote:
Originally Posted by H_TeXMeX_H View Post
or any other language you prefer, other than java of course.
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.
 
Old 01-06-2010, 12:49 PM   #4
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
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.
Old 01-06-2010, 01:11 PM   #5
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Original Poster
Rep: Reputation: 57
Quote:
Originally Posted by ta0kira View Post
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
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>

Last edited by MBybee; 01-06-2010 at 01:20 PM. Reason: didn't clearly respond to second part of the question
 
Old 01-06-2010, 04:03 PM   #6
vrmartin2
Member
 
Registered: Dec 2009
Location: NE Ohio
Distribution: Open SUSE
Posts: 43

Rep: Reputation: 19
Performance

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.
Old 01-06-2010, 04:27 PM   #7
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Original Poster
Rep: Reputation: 57
Quote:
Originally Posted by vrmartin2 View Post
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 agree - I was thinking roughly along these lines, since C# isn't really know for being a speed demon.


Quote:
Originally Posted by vrmartin2 View Post
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 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.

Quote:
Originally Posted by vrmartin2 View Post
I qualify all my remarks by noting that without a lot more details, it's problematic to make this call.
Of course But over-burdening with a huge pile of code wouldn't help anyone, and the specs are pretty simple
 
Old 01-06-2010, 05:11 PM   #8
vrmartin2
Member
 
Registered: Dec 2009
Location: NE Ohio
Distribution: Open SUSE
Posts: 43

Rep: Reputation: 19
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.
Old 01-06-2010, 06:43 PM   #9
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Original Poster
Rep: Reputation: 57
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.
 
Old 01-06-2010, 07:24 PM   #10
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
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.

Last edited by ta0kira; 01-06-2010 at 07:31 PM.
 
1 members found this post helpful.
Old 01-06-2010, 08:27 PM   #11
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Original Poster
Rep: Reputation: 57
Quote:
Originally Posted by ta0kira View Post
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
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.

Quote:
Originally Posted by ta0kira View Post
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.
ROFL
 
Old 01-08-2010, 04:16 PM   #12
MBybee
Member
 
Registered: Jan 2009
Location: wherever I can make a living
Distribution: PC-BSD / FreeBSD / Debian / Ubuntu / Win7 / OpenVMS
Posts: 438

Original Poster
Rep: Reputation: 57
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.
 
  


Reply

Tags
bsd, cc++, enterprise, gcc, language, net, odbc, perl, ruby


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
your opinion: eclipse vs anjunta vs kdevelop vs younameit for large C++ OpenGL app maxreason Programming 20 08-20-2008 07:16 AM
Now where was that ethernet monitoring utility. . . jcubed Fedora 3 09-13-2004 06:30 PM
convert utility Zingaro2002 Linux - Software 2 04-11-2003 12:34 PM
Opinion/Advice needed on a setup: tarballed Linux - General 3 11-20-2002 05:26 PM
convert utility o_helman Linux - Newbie 3 07-24-2002 12:42 AM


All times are GMT -5. The time now is 03:50 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration