Zdecydowanie odradzam programy klienckie łączące się bezpośrednio z serwerem bazy danych przez Internet z następujących powodów:
- Biblioteki klienckie są projektowane i budowane w oparciu o założenie, że baza danych znajduje się w odległości kilku milisekund, szczególnie w przypadku bardzo gadatliwych protokołów (m.in. MSSQL). W rezultacie krótkie operacje mogą trwać znacznie dłużej.
- Jest to odpowiedzialność bezpieczeństwa, nie tylko wystawiasz swój serwer bazy danych na Internet, ale także osadzasz szczegóły połączenia (takie jak hasła) w swojej aplikacji.
- Nie nadaje się do skalowalności. Co jeśli wprowadzisz wiele serwerów baz danych z równoważeniem obciążenia lub przełączaniem awaryjnym, będziesz musiał przepisać swojego klienta.
- Zakłada również, że nie będzie żadnych problemów z łącznością. Wiele sieci (zwłaszcza sieci komórkowych) ogranicza aktywność poza portem 80/443, aby zapobiec nadużyciom ich sieci (takim jak przeprowadzanie ataków przez użytkowników zombie).
Idealnym rozwiązaniem w takich przypadkach jest opracowanie frontendu usługi sieciowej dla Twojej bazy danych; Twoja aplikacja będzie wtedy łączyć się z usługą sieciową zamiast z bazą danych. Ma to inne zalety.
Oczywiście klienci (zwłaszcza klienci mobilni) powinni używać pamięci podręcznej danych, aby aplikacja działała nadal w trybie offline.
Wracając do tematu:zakładając, że nadal chcesz korzystać z bezpośredniego połączenia, nie rozumiem, dlaczego biblioteka klienta MySQL nie będzie działać w wersji 4.5. Możesz zmodyfikować manifest/konfigurację zestawu, aby działał w przyszłych wersjach .NET CLR (problemy napotkasz tylko wtedy, gdy wspomniana biblioteka używa typów i elementów członkowskich od czasu usunięcia lub polega na zmienionym zachowaniu. .NET Framework ma dobra reputacja dzięki kompatybilności wstecznej i do przodu).
