in reply to Is Perl the right solution...

I am beginning the design phase of a small business application. ... My question is, all biases aside, is Perl the right thing? Would C/C++ or even VB be a better platform to do this in?

Most biases aside, I'd be surprised if something basic like order workflow for a small business isn't already available off-the-shelf.

If you want or need to go the build-it-yourself route, you'll find that Perl is very flexible. You can get at Access from Perl via either OLE or ODBC. That said, for simple things VB can be flexible, and you'll have the advantage of a lot of Microsoft-centric books with lots of examples. I would not go with C++. You'll spend too much time fighting the language and environment, and not enough time fighting the problem.

I infer from your PWS reference that you are building a browser-based application. If you were to require a native looking windows UI, VB is probably the way to go. (You can get there in Perl, but the learning curve is steeper and the path isn't as well documented.) But the playing field is more level when it comes to HTML-based UIs.

I do some personal development with Perl CGIs on PWS, and have found no problems moving that code to IIS (and no appreciable problems moving to Apache).

One warning: Microsoft Access is not a multi-user database, and isn't suitable for heavy concurrent access. Don't expect something build using Access to scale well.

Replies are listed 'Best First'.
Re: Re: Is Perl the right solution...
by jlongino (Parson) on Dec 13, 2001 at 04:40 UTC
    As I was reading your post I was in complete agreement until your penultimate sentence: One warning: Microsoft Access is not a multi-user database . . ."? Don't get me wrong, I'm not a disciple of Bill or anything but did you forget to qualify that in some way? Our Academic Computing Offices use it for our custom written HelpDesk and Campus IP Address database applications and they are quite stable and are used by as many as 15 people.

    True, It doesn't scale too well, but if we get to the point where scalability is an issue, we'll migrate to MS SQL Server. Granted I'd love to have written them in a Perl/Web Server/RDBMS environment, but that decision wasn't mine to make.

    Were you talking in terms of a Perl/MS Access/ODBC DBI environment? I'm not very knowledgeable in that area, so it would be handy to know.

    --Jim

[reply]
      True. I should have qualified the statement (that Microsoft Access is not a multi-user database) by filling in some details.

      My experience with Access -- or, more accurately, accessing the underlying JET engine through ODBC -- is that it didn't stand up under (simulated) heavy load, and that we could fairly reliably corrupt the repository. Under lighter load, things would seem fine for quite a while, then WHAM! Under single-user load, no problem at all. We suspected a concurrency problem, but with no source to read or debug, we were left at the "we suspect" level. Plus, conventional wisdom at the time was also that Access/JET was not suited for multi-user applications.

      This was on NT4.0 in the SP5 timeframe. Something may have changed in the meantime to fix that (there have been at least two service packs, SP6 and SP6a) in the meantime, plus Win2K (and one? service pack there) and XP. I since moved on to relyling on heavier-duty RDMBSs, and haven't reevaluated Access. Nor do I plan to.

[reply]

      From memory (and i will stand corrected) doesnt access load a copy of the entire db onto the local machine (if on a LAN)? Given this, wouldnt there be problems with locking? - Hence the scalability issues

      Has the original poster considered Delphi? Its damn easy to use, got a nice RAD env, heaps of DB connectivity modules, is completely compiled, and doesnt need those silly run time libraries. Having said that, there is always Kylix for a nicer environment in which to work.. :-)

      As i've mentioned in other posts, I like Postgres and perl, coz its so damn easy to set up, maintain and write code for.

      If a web interface is decided on, you have the nice flexibility of a remote access gui, and its easy to make some kind of redundency in your final solution. ie a simple (cheap intel) two machine setup, if one machine fails, just bring up the other machine with the database and webserver on one box.

      If you wanted to get really tricky, use one machine as primary, one as secondary, both installed with a webserver and database, and have the primary roll its data across to the standby, so in the event of a failure all the data is upto n min's/seconds old. Easy, cheap, flexible, scalable and sensible for a SME whose data is their business.

      ahhhh!, the feature creep!, the damn feature creep..

[reply]
        From memory (and i will stand corrected) doesnt access load a copy of the entire db onto the local machine (if on a LAN)? Given this, wouldnt there be problems with locking? - Hence the scalability issues
        In a Windows environment (LAN or otherwise) record locking is handled via "*.ldb" files in the same directory as the "*.mdb" file. On the local computer the entire db is not copied although occasionally small temporary files may be necessary for the jet engine.

        If I remember correctly, the primary scalability issue is poor performance under increased user load (for Windows/LAN environments).

        Again I'm not very knowledgeable about Access/Perl/ODBC DBI performance issues so I can't comment there although I would be interested in hearing other monks discuss their successes/failures as dws has. Particularly if they have had any success under heavy usage.

        If it were up to me, I would also like to use an Apache/Postgres/Perl DBI environment (even though the learning curve would be steep for me).

        --Jim

[reply]

In Section Seekers of Perl Wisdom