OK, with respect, "a dozen tables and a few queries" does not constitute serious rocket science unless your tables each have millions of fields and your queries are seriously convoluted.
Let's try and break this down and see if we can't make a big thing into a more manageable series of little things. I've always felt that the big things are made up of little things, so if you get the component parts right everything else just kind of clicks.
Can you be a bit more specific without breaking any national secrets on what it is you want to do ?
You said "Basically, I need to collect application data, orders, set up FAQ's, etc from the web."
If we take that as:
1. Collect application data (I need to know what that means in your particular situation)
2. Collect orders.
3. Set up FAQ's
4. etc...
What I'd say is that you have four (or possibly more) very individual processes going on there. Your FAQ's need not have any direct database involvement unless you need it to. I often prep a series of FAQ's as nothing more than a two window web page with a series of jump links down the left side. Each hyperlink jumps to the target subject or FAQ and beside that FAQ is a jump link ^^back to top^^.
Serving FAQ's from a database is sometimes using a sledgehammer to crack a nut. A lot of program Help files are little more than an indexed series of FAQ's compiled into a help document, but they start out as a plain and simple series of HTML pages. Unless the FAQ's section becomes so large and unwieldly it is impractical in plain vanilla HTML there are alternatives to database involvement which effectively removes your requirement for ASP or any other dynamic page for this element. I'm not guaranteeing that you can get away without ASP, I'm merely saying that it may not be necessary and so far, you haven't given enough of the game away for me or anyone else to advise properly.
There's an open source PHP/MySQL FAQ generator at this link:
and there are more little programs out there to help you than you can shake a stick at for little outlay
Now,
collecting orders is the tricky bit. The easy option is to go without secure order processing for card transactions and have your order forms generate email replies. This is how it works:
Customer selects quatities of goods, fills in personal details or account information if they have an account with you and clicks the submit button. A couple of seconds later your inbox has an order for you. You reply to their order request with a confirmation letter detailing the amount due (from a template of course) and await payment. Client calls and pays through whatever means are necessary/desirable. You deliever the goods. Job done.
The more complicated methods involve a database of products that offers stock control and order processing. You have to watch which payment providor you deal with because some of them will keep on selling your items even if you have nothing left in stock, while others will offer you a stock management system with your subscription to their service.
The inbetween method is to code up a form that calculates value of product by quantity ordered then totals all items picked. You can get the form to add sales tax, offer discounts if a minimum amount is reached and so on. And you don't need an underlying database of products to do this. You can use ASP, PHP, JavaScript, CGI/Perl and one or two others for this approach, and the final order is emailed or printed off and mailed to you for processing.
Either way, it's as hard as you want to make it and while forms can be an issue to some people I certainly don't mind lending a hand if you supply some details of what it is you want to be aboe to do.
So, out of your "collect application data, orders, set up FAQ's, etc" the only real problems as I see them are 'collect application data' and that rather ambiguous etc you tagged onto the end.
More information required methinks. If the project is of a sensitive nature say so and we'll do go to alternative communication.
Good luck with it.
