[GLLUG] General programming question

Sean picasso@madflower.com
Thu, 1 Aug 2002 22:01:51 -0400 (EDT)


Here is my 2 cents (which was 2 cents before the stock market crash). 

Use Postgres. period. You are going to do a lot more than MySQL handles   
effectively, and converting the databases over after you realize it is
gonna suck. Yes MySQL can be fast for simple database structures, however 
I can even imagine a simple accounting system especially for state 
government. 

With a background in C++ I would lean towards pointing you to java
servlets with tomcat especially if you have any hopes of reusing some code 
for standalone apps. Although I havent worked with it at all, I would 
imagine you can use some of the core functions over if you plan on it, and 
abstract the gui. 

PHP is also a great choice. Don't get me wrong. I use it. I think it is
more perl-like than anything. I guess I just saw the glimmer of hope of a
standalone non-web based application in your words.

My last comment would be that one of the best free RAD environments I have 
seen for Java comes with Apple's OS X developer tools. It was tuned for 
Apple (NeXT's) WebObjects when WebObjects moved from the OO environment to 
java and further tuned for OS X development and is included with the Apple 
Developer tools which only cost you time to sign up as a developer (no 
money and it includes a version of gcc.) 


On Thu, 1 Aug 2002, Matt Graham wrote:

> On Thursday 01 August 2002 17:02, after a long battle with technology, 
> Jason Green wrote:
> > After a bit of research, I'm leaning towards PHP on Apache with
> > PostgreSQL.  This will be used to develop an accounting system for a
> > niche market with customizable reporting abilities
> 
> > I've never used PHP (and not much HTML), but have a decent amount of
> > C/C++ knowledge.
> 
> PHP is IMHO closer to Perl than it is to C++, but the PHP syntax is very 
> easy to pick up if you know C++.  You will need to know at least a 
> little bit of HTML if you want to use PHP effectively.  A reasonable 
> reference manual to HTML can be found at 
> http://freespace.virgin.net/sizzling.jalfrezi .
> 
> > I like PostgreSQL's transaction support as well as the "better than
> > record-level locking" they use.  This application will need to
> > accommodate roughly 100 concurrent users.  
> 
> Postgres is certainly a fine database.  Provided the database server is 
> beastly enough, you shouldn't have a big problem with 100 users at 
> once.  Keep in mind that Slashdot runs on MySQL(!) and Slashdot gets 
> more traffic than you'll ever get.
> 
> > I really like Access for it's rapid application deployment abilities, 
> 
> <DIGRESSION>
> An application a couple of my cow-orkers use was developed in Java, with 
> RAD tools.  That obviously saved the original programmer a lot of time.  
> However, the completed app runs like a bloated sack, has inexplicable 
> bugs, and has probably cost us over a hundred man-hours of time in 
> covering up its deficiencies.  IMHO, RAD tools have their place, but 
> anything that's going to be used in the real world needs to be built in 
> something other than a RAD toolset.
> </DIGRESSION>
> 
> > So, has anyone developed any applications with this kind of usage
> > level? What would you recommend for database software, easy to
> > manipulate front ends (and intuitive for end users), or other general
> > suggestions?
> 
> 2.5 years ago, I created a scheduling application (shift workers signing 
> up for shifts, swapping shifts, saying "I can't be here from FOO to BAR 
> on date BAZ, can someone cover for me?") that used PHP and Oracle.  
> Later made it run on MySQL too.  It didn't have anywhere near the usage 
> you're talking about, but I gave it a test script far exceeding normal 
> usage, and managed to saturate the DSL line before the system load on 
> the database server got over 2.0.  Its user interface was a mite 
> confusing, but I never claimed to be a UI designer....
> 
> If you're using PHP and Postgres, you're not using a frontend.  PHP 
> directly executes SQL queries and/or Postgres commands.  You can use 
> PHP to *create* a specialized frontend application that will allow 
> users to manipulate databases in various ways--that's the way it's 
> usually used.
> 
> There doesn't seem to be an equivalent for "PHPMyAdmin" for PostgreSQL.  
> PgAccess looks like the best starting point for a "similar to MS SQL 
> Enterprise Manager".
> 
> > Any specific resources you've found helpful?
> 
> PHP tutorial:
> http://hotwired.lycos.com/webmonkey/99/21/index2a.html
> 
> All right, it's a little basic/sparse, and oriented towards MySQL.  
> Still could be useful.
> 
> PostgreSQL+PHP reference:
> http://www.php.net/manual/en/ref.pgsql.php
> 
> > Oh yeah, if you have a suggestion for database software, which OS 
> > works the best for it?  Thanks in advance!
> 
> There should not be any significant differences in performance between 
> running PostgreSQL on a *BSD, Linux, or OS X machine.  Best way to 
> improve database performance is to design your tables carefully (make 
> good use of those primary keys) then go over your queries carefully and 
> make sure they're not doing unnecessary garbage.  Second best is to 
> load the server up with RAM.  Storing large objects inside a database 
> might not be a good idea either--if you have a whole bunch of ~1M BLOBs 
> to keep track of, it could be a good idea to put them on the filesystem 
> and store pathnames in a table, instead of putting the BLOBs into the 
> 'base.
> 
>