network topology including many services

From a generalist perspective, it looks like you've done due diligence on your overall network design. Here are some things I'd recommend you keep in mind:

• Hone your firewall rules down very carefully. As you already stated, your DMZ2 is not accessible from the public network or private. That's great! You also stated that only certain servers can access certain other servers. That's even better! Make sure that only your app server can access your SQL server and even then only on the ports that you need it to. Hone each and every node's access needs down to the most atomic level!
• Collect access logs from all of your devices and monitor them for events. Use Splunk perhaps? Even just Syslog. Make sure access and traffic data is kept long-term. Check for who is access your devices when and why.
• Enable network analysis on your devices if possible. Netflow / sFlow. Collect the data and use software that is capable of displaying it in meaningful ways. Analyze what types of data are flowing into, within and out of your network. If nothing surprises you about the traffic that you see, you're not looking hard enough.
• You should also hone down the individual software firewalls for each of those machines so that if, perchance, your hardware firewalls are compromised and/or an errant rule is put in place, the software firewalls are also blocking traffic that you don't want.
• Document until your fingertips bleed, your eyes tear up and you want to do bodily harm to the person that invented Wikis and document control repositories. Then document some more. You are entering a maze of twisty passages all alike. You will need to be so OCD with your documentation that you'll need palettes of Tofranil air-dropped to you (OCD patients will know what Tofranil is. ;) ). If anyone on your team does not document properly in such a complex networking environment, taze them.
• You may also want to consider encrypting data streams where possible. As far as your web tier is concerned, perhaps consider encrypting the streams with IPSEC. That may be a bit overkill, I admit.

The ultimate goal is not just to narrow down the attack surface, but to then watch the traffic that attempts to touch both the unavailable and available surfaces. It's a bit like making sure a bank has all the best locks, safes and mantraps, but then never monitoring the equipment to see if someone is attempting a heist. Assume that given enough unsupervised time, anyone can do anything.

Your web and database server are like golden vials of nitro glycerin. Assume that everyone wants them for their own profit and also want to explode your face with them in the process. Really, any public facing device is.

You're on the right track! Great job in segmenting your network. You're a head above your peers. Now try to stand head and shoulders above the norm.

So here's my 2 cents. You seem to be on the right track with network segmentation. Here are some thoughts.

Where is your IDS going to sit? IF you have 2 DMZs and a internal zone, then it would seem to me you would want IDS sensors in front of each of those zones. However you then need allow traffic from your IDS sensors in the DMZ into the internal zone.

And while I'm at it how are you providing DNS services for the devices in the DMZ.

One final thought be very suspicious and lockdown your public FTP server tight, they can be easily abused.

Yes, it's another one of those questions. You haven't been very specific in describing your needs/goals. The answer lies in your answer to questions such as (but not limited to):

How many users?

What services do you need to provide to those users?

What services do you need to provide to the outside world?

What are the business goals/requirements for implementing an IT infrastructure?

What does the DRP\BCP require?

Et., etc.

Your question in it's current form is like asking:

I'm baking a pie. I've got some apples and I'm thinking of using some flour and sugar. What do you think?