If it's a separate schema/database/whatever, then this can be a valid approach so long as there is *no* chance of it touching production data. In practice this is very hard to guarantee.

Smoke tests (also called validation or deployment tests) should be non-destructive in production.

As far as the heated discussion goes, you can absolutely write tests depending on the DB being in a particular state, and that is exactly why there are setup and teardown and fixtures. But I don't think running the full test suite in production is necessary: again, non-destructive tests are fine.

Typically deployment tests just validate that certain expected actions happen in production. If you do a search nothing comes back but you know something should have, that's a good enough test. It doesn't have to be a particular set of data to test a deployment. The time for precise functional and integration validation was before you hit staging, not in production. In production you just want to know that you deployed the system properly and all of it is running.