это не очень хорошо потому что:
1) вашу систему будут ломать все кому не лень. (автоматически скриптами), нужно будет подерживать СУБД и накатывать обновления сразу же. в общем следить за секьюрити.
соответственно бэкапиться и изолировать внутр сетку просто обязательно
2)стоит посчитать нагрузку на канал.
3)вопрос об атомарности транзакций весьма серьезно надо будет подумать. (соединение сдохло и что же мы делаем дальше)


может всё таки 3-tier?

а что вообще за приложение?
тут ведь еще такая проблемка - данные о соединении тоже можно перехватить и в принципе можно послать произвольный запрос.
а из вопроса - кого ломали. ставишь несвежую версию СУБД. потом смотришь release notes и major security bugs. потом ищешь эксплоит и демонстрируешь

изменения в 5.5
#

Security Fix: The server failed to check the table name argument of a COM_FIELD_LIST command packet for validity and compliance to acceptable table name standards. This could be exploited to bypass almost all forms of checks for privileges and table-level grants by providing a specially crafted table name argument to COM_FIELD_LIST.

In MySQL 5.0 and above, this permitted an authenticated user with SELECT privileges on one table to obtain the field definitions of any table in all other databases and potentially of other MySQL instances accessible from the server's file system.

Additionally, for MySQL version 5.1 and above, an authenticated user with DELETE or SELECT privileges on one table could delete or read content from any other table in all databases on this server, and potentially of other MySQL instances accessible from the server's file system. (Bug#53371, CVE-2010-1848)
#

Security Fix: The server was susceptible to a buffer-overflow attack due to a failure to perform bounds checking on the table name argument of a COM_FIELD_LIST command packet. By sending long data for the table name, a buffer is overflown, which could be exploited by an authenticated user to inject malicious code. (Bug#53237, CVE-2010-1850)