Pokud máte na výběr cokoli, použijte znakovou sadu Unicode pro celou databázi. Život je tak obecně oslnivě jednodušší.
- Existuje spousta nástrojů a knihoven třetích stran, které jednoduše nepodporují sloupce NCHAR/NVARCHAR2 nebo které neudělají práci se sloupci NCHAR/NVARCHAR2 příjemnou. Je to například extrémně nepříjemné, když váš zbrusu nový nástroj pro vytváření přehledů nemůže podávat zprávy o vašich datech NVARCHAR2.
- U vlastních aplikací vyžaduje práce se sloupci NCHAR/NVARCHAR2 přeskakování některých obručí, které práce se sloupci s kódováním CHAR/ VARCHAR2 Unicode neumožňuje. Například v kódu JDBC byste neustále volali metodu Statement.setFormOfUse. Jiné jazyky a rámce budou mít jiné problémy; některé budou relativně dobře zdokumentovány a menší jiné budou relativně nejasné.
- Mnoho vestavěných balíčků přijme (nebo vrátí) pouze VARCHAR2, nikoli NVARCHAR2. Stále je budete moci volat kvůli implicitní konverzi, ale můžete skončit s problémy s převodem znakové sady.
- Obecně platí, že možnost vyhnout se problémům s převodem znakových sad v databázi a odsouvání těchto problémů na okraj, kdy databáze skutečně odesílá nebo přijímá data od klienta, značně usnadňuje vývoj aplikace. Je dost práce na odladění problémů s převodem znakové sady, které jsou důsledkem síťového přenosu – zjištění, že některá data byla poškozena, když uložená procedura zřetězila data z VARCHAR2 a NVARCHAR2 a výsledek uložila do VARCHAR2 předtím, než byla odeslána přes síť. být nesnesitelný.
Společnost Oracle navrhla datové typy NCHAR/NVARCHAR2 pro případy, kdy se snažíte podporovat starší aplikace, které nepodporují Unicode ve stejné databázi jako nové aplikace, které používají Unicode, a pro případy, kdy je výhodné uložit některá data Unicode s jiným kódem. kódování (tj. máte velké množství japonských dat, která byste raději uložili pomocí kódování UTF-16 v NVARCHAR2 namísto kódování UTF-8). Pokud se nenacházíte v jedné z těchto dvou situací a nezní to, že jste, vyhnul bych se NCHAR/NVARCHAR2 za každou cenu.
Reakce na vaše reakce
Naše aplikace je obvykle sama v databázi Oracle a stará se o data sama. Ostatní software, který se připojuje k databázi, je omezen na vývojáře Toad, Tora nebo SQL.
Co tím myslíš "stará se o data sama"? Doufám, že neříkáte, že jste svou aplikaci nakonfigurovali tak, aby obcházela rutiny převodu znakových sad Oracle a že veškerou konverzi znakových sad provádíte sami.
Předpokládám také, že pro přístup k databázi používáte nějaký druh knihovny API/knihovny, i když je to OCI. Podívali jste se na to, jaké změny budete muset provést ve své aplikaci, aby podporovala NCHAR/NVARCHAR2 a zda používané API podporuje NCHAR/NVARCHAR2? Skutečnost, že získáváte data Unicode v C++, ve skutečnosti neznamená, že nebudete muset provádět (potenciálně významné) změny pro podporu sloupců NCHAR/NVARCHAR2.
Používáme také SQL*Loader a SQL*Plus pro komunikaci s databází pro základní příkazy nebo pro upgrade mezi verzemi produktu. Neslyšeli jsme o žádném konkrétním problému s veškerým softwarem týkajícím se NVARCHAR2.
Všechny tyto aplikace pracují s NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 zavádí do skriptů některé další složitosti, zejména pokud se pokoušíte zakódovat řetězcové konstanty, které nelze reprezentovat ve znakové sadě databáze. Problémy však jistě můžete obejít.
Také si nejsme vědomi toho, že by správci databází z řad našich zákazníků rádi používali v databázi jiné nástroje, které by nemohly podporovat data na NVARCHAR2, a opravdu nás nezajímá, zda by jejich nástroje mohly narušit, přeci jen jsou ve své práci kvalifikovaní a mohou najít jiné nástroje, pokud jsou potřeba.
I když jsem si jistý, že vaši zákazníci mohou najít alternativní způsoby práce s vašimi daty, pokud si vaše aplikace nehraje dobře s jejich podnikovým nástrojem pro vytváření sestav nebo jejich podnikovým nástrojem ETL nebo jakýmikoli desktopovými nástroji, se kterými mají náhodou zkušenosti, je velmi pravděpodobné, že zákazník bude vinit spíše vaši aplikaci než své nástroje. Výstavní zátka to asi nebude, ale způsobovat zákazníkům zbytečně smutek také nemá žádný přínos. To je možná nepřiměje používat produkt konkurence, ale to v nich nevyvolá touhu přijmout váš produkt.
Mohli bychom také očekávat snížení výkonu, pokud naše aplikace (která je kompilována pod Visual C++), která používá wchar_t k ukládání UTF-16, dokáže provádět převody kódování na všech zpracovaných datech?
Nejsem si jistý, o jakých "konverzích" mluvíš. To se může vrátit k mé původní otázce, zda uvádíte, že obcházíte vrstvu Oracle NLS, abyste provedli konverzi znakové sady sami.
Sečteno a podtrženo, vzhledem k tomu, co popisujete, nevidím žádné výhody používání NCHAR/NVARCHAR2. Jejich používání má spoustu potenciálních nevýhod. I když můžete odstranit 99 % nevýhod jako irelevantních pro vaše konkrétní potřeby, stále čelíte situaci, kdy je to v nejlepším případě lavírování mezi těmito dvěma přístupy. Vzhledem k tomu bych mnohem raději šel s přístupem, který maximalizuje flexibilitu do budoucna, a to je převedení celé databáze na Unicode (AL32UTF8 pravděpodobně) a právě to použití.