Your question is a little vague, so I would advise that you consider what threat models you're trying to protect yourselves from.
The first thing to do is to define that a DMZ is a region in your network which is considered wholly or partially untrusted, because it is attached to the Internet (or some other untrusted and hostile network). The DMZ defines a security boundary between that infrastructure and your internal, more trusted environment. That security boundary is usually enforced by a firewall or similar network controls. You might be saying "yeah, I know this", but I've seen people completely misunderstanding the point of a DMZ and I want to make sure we're on solid ground.
My understanding is that you're concerned about keeping your database in the DMZ along with the web server, because you've got internal equipment from your trusted network connecting into that database. This is a common configuration, and many people do indeed get by just fine by allowing connections from the trusted network to the database in the DMZ.
However, one thing to consider is the authentication model. If you're authenticating to an MSSQL server in the DMZ via AD, and your domain controller isn't in your DMZ (I hope it's not!) you'll need to allow that AD traffic through the firewall. This isn't a good idea, really. So, utilising database replication to sync data through the DMZ boundary so that the inner database can be authenticated to via AD, while the outer (i.e. DMZ-based) database doesn't need to speak to the DC, is actually a pretty good solution.