Чому ще існує тип даних varchar?

У багатьох моїх базах даних є поля, визначені як вархари. Це не було багато проблем , так як я живу і працюю в Америці (де єдина мова , який існує це «американський». Гм )

Пропрацювавши з базами даних близько 5 років, я виявив, що врешті-решт я зіткнувся з проблемами з обмеженим характером поля варчара і мені доводиться змінювати свої поля для зберігання даних як nvarchars. Після того, як зробити ще одне оновлення таблиці, перетворивши поле варчара в nvarchar, у мене просто з'явилася думка-- чому ми все ще робимо це таким чином? Я давно прийняв розумове рішення визначити всі нові мої текстові поля на nvarchar, а не на varchar. Це те, що я навчився робити з своїх підручників, коли навчався в школі 10 років тому.

Настав 2011 рік, і минулого року вийшов новий реліз SQL Server. Чому ми продовжуємо підтримувати тип даних varchar, коли ми можемо / мусимо замість цього використовувати nvarchar?

Я знаю, що часто стверджується, що nvarchars "вдвічі більше", ніж varchars, тому використання місця для зберігання може бути однією аргументацією для основних варкарів.

Однак сьогоднішні користувачі можуть визначити свої nvarchars для зберігання даних як UTF-8 замість UTF-16 за замовчуванням, якщо вони хочуть заощадити на просторі зберігання. Це дозволило б виконати 8-бітове кодування, якщо це в першу чергу бажано, одночасно даючи впевненість, що рідкісний 2-8-байтний символ, який вставляється в їх БД, нічого не порушить.

Я щось пропускаю? Чи є вагома причина, чому це не змінилося протягом останніх 15-20 років?

1. Варчарська робота досить хороша для багатьох західноєвропейських мов (норвезька, датська, німецька, французька, голландська тощо), за умови деяких питань зіставлення

2. Дивіться це на SO varchar vs nvarchar продуктивність nvarchar має серйозні наслідки для продуктивності

3. Це банально порівняно з датами MDY проти DMY

Окрім відповідей, що стосуються стандартів та сумісності, слід пам’ятати і про продуктивність. Хоча дисковий простір легко сприймається як дешевий, DBA / Developers часто ігнорують той факт, що продуктивність запитів часом безпосередньо пов'язана з розміром рядка / сторінки таблиці. Використання, NVARCHARа не VARCHAR(коли це не потрібно), ефективно подвоїть розмір рядка для ваших полів символів. Якщо у вас є, скажімо, 5 або 10 полів довжиною 50, ви говорите про потенційне додавання додаткових 500 байт у рядку. Якщо у вас широка таблиця, це може пересувати кожен рядок на кілька сторінок і негативно впливати на продуктивність.

У багатьох організаціях все ще є велика встановлена ​​база додатків, інтерфейсів, платформ та інструментів, які припускають однобайтові символи. Бази даних рідко живуть ізольовано - вони є частиною ІТ-екосистеми. Якщо у вас є тисячі компонентів і мільйони рядків коду, залежних від однобайтових символів, тоді вам знадобиться вагомий привід вкласти час і гроші, необхідні для переходу на unicode. Зміни в такому масштабі можуть зайняти роки. У деяких місцях Unicode все ще відносно новий, рідкісний або не повністю підтримується.

VARCHAR і NVARCHAR є частиною стандарту ISO SQL. Видалення або зняття підтримки VARCHAR у SQL Server було б кроком назад у сумісності та портативності.

Крім того, сьогоднішні користувачі можуть визначити свої nvarchars для зберігання даних як UTF-8 замість UTF-16 за замовчуванням, якщо вони хочуть заощадити на просторі зберігання.

Саме це робить більшість баз даних з відкритим кодом VARCHAR.

• MySQL забезпечує utf8і ucs2"зіставлення".
• SQLite дає вам вибір між UTF-8 (за замовчуванням) та UTF-16.
• PostgreSQL підтримує UTF-8 (але не UTF-16).

Не потрібно мати два окремі типи рядків.

Майкрософт відрізняється тим, що 8-бітні рядки призначені для застарілих кодувань та Unicode = UTF-16. Це, мабуть, пов’язано з самим API API charта wchar_tтаким чином.

Оскільки деякі з нас будують легші, менші додатки на менших, ніж у найсучасніших апаратних засобів, які не потребують можливостей Unicode. Можливо, нам знадобиться це змінити пізніше, але поки це нам просто не потрібно. Мені подобається, що мої струни займають 1/2 місця, яке вони інакше мали б мати під NVARCHAR.