Jeśli masz coś bliskiego do wyboru, użyj zestawu znaków Unicode dla całej bazy danych. W ten sposób życie jest po prostu oślepiająco łatwiejsze.
- Istnieje wiele narzędzi i bibliotek innych firm, które po prostu nie obsługują kolumn NCHAR/NVARCHAR2 lub nie sprawiają, że praca z kolumnami NCHAR/NVARCHAR2 jest przyjemna. To bardzo irytujące, na przykład, gdy nowe, błyszczące narzędzie do raportowania nie może raportować danych z NVARCHAR2.
- W przypadku aplikacji niestandardowych praca z kolumnami NCHAR/NVARCHAR2 wymaga przeskakiwania przez niektóre obręcze, których nie wymaga praca z kolumnami zakodowanymi w standardzie CHAR/VARCHAR2 Unicode. W kodzie JDBC, na przykład, będziesz ciągle wywoływał metodę Statement.setFormOfUse. Inne języki i frameworki będą miały inne problemy; niektóre będą stosunkowo dobrze udokumentowane, a drobne inne będą stosunkowo niejasne.
- Wiele wbudowanych pakietów zaakceptuje (lub zwróci) tylko VARCHAR2 zamiast NVARCHAR2. Nadal będziesz mógł je wywołać z powodu niejawnej konwersji, ale możesz skończyć z problemami z konwersją zestawu znaków.
- Ogólnie rzecz biorąc, możliwość uniknięcia problemów z konwersją zestawu znaków w bazie danych i przeniesienie tych problemów na brzeg, na którym baza danych faktycznie wysyła lub odbiera dane od klienta, znacznie ułatwia tworzenie aplikacji. Wystarczy praca, aby debugować problemy z konwersją zestawu znaków, które wynikają z transmisji sieciowej — stwierdzenie, że niektóre dane zostały uszkodzone, gdy procedura składowana połączy dane z VARCHAR2 i NVARCHAR2 i zapisze wynik w VARCHAR2 przed wysłaniem przez sieć, może być nieznośnym.
Oracle zaprojektowało typy danych NCHAR/ NVARCHAR2 dla przypadków, w których próbujesz obsługiwaćstarsze aplikacje, które nie obsługują Unicode w tej samej bazie danych, co nowe aplikacje używające Unicode oraz dla przypadków, w których korzystne jest przechowywanie niektórych danych Unicode w innym kodowanie (tj. masz dużą ilość japońskich danych, które wolisz przechowywać przy użyciu kodowania UTF-16 w NVARCHAR2 zamiast kodowania UTF-8). Jeśli nie znajdujesz się w jednej z tych dwóch sytuacji i nie brzmi to tak, jakbyś był, za wszelką cenę unikałbym NCHAR/NVARCHAR2.
Odpowiadanie na Twoje uwagi
Nasza aplikacja jest zwykle sama w bazie danych Oracle i sama zajmuje się danymi. Inne oprogramowanie, które łączy się z bazą danych, jest ograniczone do Toad, Tora lub programisty SQL.
Co masz na myśli mówiąc „dba o same dane”? Mam nadzieję, że nie mówisz, że skonfigurowałeś swoją aplikację tak, aby omijała procedury konwersji zestawu znaków Oracle i że sam wykonujesz całą konwersję zestawu znaków.
Zakładam również, że używasz jakiegoś API/biblioteki, aby uzyskać dostęp do bazy danych, nawet jeśli jest to OCI. Czy sprawdziłeś, jakie zmiany musisz wprowadzić w swojej aplikacji, aby obsługiwać NCHAR / NVARCHAR2 i czy używany interfejs API obsługuje NCHAR / NVARCHAR2? Fakt, że otrzymujesz dane Unicode w C++, w rzeczywistości nie oznacza, że nie będziesz musiał dokonywać (potencjalnie znaczących) zmian w celu obsługi kolumn NCHAR/NVARCHAR2.
Używamy również SQL*Loader i SQL*Plus do komunikacji z bazą danych dla podstawowych instrukcji lub do aktualizacji między wersjami produktu. Nie słyszeliśmy o żadnym konkretnym problemie z całym oprogramowaniem dotyczącym NVARCHAR2.
Wszystkie te aplikacje działają z NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 wprowadzają dodatkowe komplikacje do skryptów, szczególnie jeśli próbujesz zakodować stałe łańcuchowe, których nie można przedstawić w zestawie znaków bazy danych. Z pewnością możesz jednak obejść te problemy.
Nie jesteśmy również świadomi, że administratorzy baz danych wśród naszych klientów chcieliby korzystać z innych narzędzi w bazie danych, które nie mogłyby obsługiwać danych na NVARCHAR2 i nie przejmujemy się tym, czy ich narzędzia mogą ulec awarii, w końcu są wykwalifikowani w swojej pracy i mogą znaleźć inne narzędzia, jeśli to konieczne.
Chociaż jestem pewien, że Twoi klienci mogą znaleźć alternatywne sposoby pracy z Twoimi danymi, jeśli Twoja aplikacja nie współpracuje dobrze z ich narzędziem do raportowania dla przedsiębiorstw lub narzędziem ETL dla przedsiębiorstw lub jakimikolwiek narzędziami komputerowymi, z którymi mają do czynienia, jest to bardzo prawdopodobne że klient będzie winił twoją aplikację, a nie swoje narzędzia. Prawdopodobnie nie będzie to przeszkodą na pokazie, ale nie ma również żadnych korzyści z niepotrzebnego powodowania żalu u klientów. To może nie skłonić ich do korzystania z produktu konkurencji, ale nie sprawi, że chętnie skorzystają z Twojego produktu.
Czy moglibyśmy również spodziewać się spadku wydajności, jeśli nasza aplikacja (skompilowana w Visual C++), która używa wchar_t do przechowywania UTF-16, ma najwyższą wydajność konwersji kodowania na wszystkich przetwarzanych danych?
Nie wiem, o jakich „konwersjach” mówisz. To może wrócić do mojego początkowego pytania, czy twierdzisz, że omijasz warstwę NLS Oracle, aby samodzielnie przeprowadzić konwersję zestawu znaków.
Najważniejsze jest to, że nie widzę żadnych korzyści z używania NCHAR / NVARCHAR2 biorąc pod uwagę to, co opisujesz. Istnieje wiele potencjalnych wad ich używania. Nawet jeśli możesz wyeliminować 99% wad jako nieistotnych dla twoich konkretnych potrzeb, nadal masz do czynienia z sytuacją, w której w najlepszym razie jest to przemycie między dwoma podejściami. Biorąc to pod uwagę, wolałbym pójść z podejściem, które maksymalizuje elastyczność w przyszłości, a to konwertuje całą bazę danych do Unicode (prawdopodobnie AL32UTF8) i po prostu go używa.
