Go with your experience. If you have coded in one of those technologies
before, use it again.

Lot's of nice stuff is written in PHP, and you can certainly create a mess
using j2ee and .net also. But, if your application need enterprise services
like transaction handling and distribution, go for .net or j2ee. .net is
perfectly well structured, so you shouldn't let that stop you. It sounds
like you're designing some kind of workflow, some kind of queueing could
help you with that. in j2ee you'd use jms and possibly message driven
beans.

The datagrid component I'm sure is available in asp.net. There isn't really
defined any web-components besides the basic html web controls in j2ee. But
different vendors typically include such stuff with their development
environment, I'm sure you'll find something datagrid-ish in JDeveloper or
JBuilder. (Actually JDeveloper has a very nice licence scheme and you can
download and use it without -- I believe, please check the licence -- any
cost. The latest early access 10g v 1013 build has support for JSF design,
and you aren't locked into using oracles appserver, deploying to say jboss
works just fine too.)

When it comes to web-ui j2ee itself hasn't really delivered, in my opinion.
Using .net you have webforms and that's it. In j2ee you have jsp and
servlets, and in addition you have to choose one of literally hundreds
webframeworks for the more highlevel support. Struts is the
industry-standard here. We are also beginning to see support for JSF (java
server faces) around in the various tools around. JSF is to j2ee somewhat
the same as webforms is to .net. I'm not saying j2ee has bad support for
web-applications, just that you'd have to pick and choose, just like you'd
have to pick and choose your j2ee implementation (jboss or weblogic or ...)

When it comes to database; if oracle is an option go for it over mysql any
day. mysql may serve your needs just fine, but if oracle is available just
go for it instead. While mysql is catching up nicely these days, oracle has
had all the features you expect in a database for a very long time. MySQL
has also been more geared towards "website" stuff, ie. fast reader but not
so much optimized for concurrent transactions. However, both are widely
used and are proven in the field. Another alternative is PostgreSQL (free),
which has had most of the features of oracle for many years and is a mature
product where MySQL is playing catchup.

Finally, if you consider not using j2ee, I don't see how you can implement
your application at all in java. You could use J# on .net, but then it'd
probably be better to write in C#. Skipping j2ee entirely means you can't
use jdbc for databaseaccess and not some form of servlets (or jsp) for
web-gui. It's pretty hard to get by without j2ee. But you certainly don't
need to use all j2ee-technologies at the same time. You can skip ejb, and
use spring or hibernate instead, or even make a 2-layer app where you use
jdbc calls in your jsp-code (which is kind of low-level but still using
j2ee). Then your app will run fine in a webcontainer like tomcat, and you
don't need a full j2ee stack (like jboss, weblogic, ias etc.). And while
jdbc is part of the j2ee standard, the interfaces are distributed in the
standard edition sdk, so it's obviously meant to be used in settings that
aren't strictly enterprisish ...