VARCHAR как полностью 1990-е? [закрытый]
Я знаю, знаю, но эй ...
const deepProps = x => x && x !== Object.prototype && Object.getOwnPropertyNames( x ).concat( deepProps( Object.getPrototypeOf( x ) ) || [] );
const deepFunctions = x => deepProps( x ).filter( name => typeof x[ name ] === "function" );
const userFunctions = x => new Set( deepFunctions( x ).filter( name => name !== "constructor" && !~name.indexOf( "__" ) ) );
использование:
class YourObject {
hello() { return "uk"; }
goodbye() { return "eu"; }
}
class MyObject extends YourObject {
hello() { return "ie"; }
}
const x = new MyObject();
userFunctions( x ); // [ "hello", "goodbye" ]
12 ответов
Вы соответствуете типу данных данным, которые будут храниться в столбце. Подобным аргументом Вы могли сказать, почему бы не хранить все данные в столбцах NVARCHAR, потому что числа и даты могут быть представлены как строки цифр.
, Если лучшее соответствие для данных, которые будут храниться в столбце, является VARCHAR, затем используйте его.
Точка 4 не имеет значения, потому что пространство памяти чрезвычайно недорого.
это не просто устройство хранения данных, но и пропускная способность - CPU, память, резервное копирование, восстановление, передача. Сохранить.
Я сказал бы, что существуют все еще допустимые причины не использовать nvarchar.
- Пространство памяти в большом почете, такой как на общем хосте, или база данных действительно огромна.
- Производительность очень важна.
- разработка Существующих производств (т.е. база данных имеет существующие таблицы то использование varchar).
- Вы интегрируетесь с другой более старой системой, которая только понимает однобайтовые символы и/или varchar.
Однако новая разработка должна, вероятно, использовать nvarchar особенно, так как 64-разрядные системы становятся нормой. Кроме того, компании (даже маленькие) теперь чаще всего глобальны.
Необходимо выбрать VARCHAR over NVARCHAR для многих различных типов столбцов, и выбор был бы на основе для каждого столбца.
столбцы Typical, которые не потребовали бы дополнительных издержек NVARCHAR, подвергаются, был бы:
столбцы идентификационного типа: Номерные знаки, SSNs, Терпеливые идентификаторы Диаграммы и т.д.
столбцы Code: Международные коды валюты (доллар США, UKP, и т.д.), коды страны ISO (США, Великобритания, и т.д.), коды Языка (en-us, и т.д.), бухгалтерские коды сегмента, и т.д.
Индекс и столбцы почтового индекса.
Я полагаю, что сравнение nvarchars является более дорогостоящим, чем varchars, таким образом, это совершенно допустимо и даже предпочтительно в местах, где Вам действительно не нужны unicode возможности, т.е. для некоторых внутренних идентификаторов.
И затраты на хранение все еще действительно имеет значение . Если у Вас есть миллиарды строк тогда, те "небольшие" различия становятся большими довольно быстро.
Я видел nvarchar столбцы, преобразованные в varchar по двум причинам:
-
Приложение использует MSSQL Express Edition, который имеет предел размера базы данных 4GB. Переключение на MSSQL Standard Edition было бы слишком дорогим, если бы существует много развертывания базы данных, как был бы в веб-приложениях единственного арендатора или приложениях со встроенным DBMS. Более дешевый SQL2008 Web Edition мог помочь здесь.
-
nvarchar (4000) недостаточно , но Вы не хотите столбца типа ntext. Таким образом, Вы преобразовываете в varchar (8000). Однако в большинстве случаев, вероятно, необходимо преобразовать в nvarchar (макс.).
Эти виды вопросов всегда имеют тот же ответ: это зависит . Нет никакого волшебного правила, что необходимо следовать вслепую. Даже использование GOTO на современных языках программирования может быть выровнено по ширине: он когда-либо выгодный для использования ' goto' на языке, который поддерживает циклы и функции? Если так, почему?
, Таким образом, ответ: используйте голову и думайте о конкретной ситуации. В этом конкретном экземпляре имеют в виду, что можно всегда преобразовывать от varchar до nvarchar в базе данных, если это оказывается изменением требований.
Ваша точка 3 недопустима. Системы, которые разработаны только для использования единственной страны, не должны волноваться о unicode, и некоторые используемые языки/продукты не поддерживают unicode или вообще или только частично. Например, TurboTax только для США (и даже с канадской версией с французским языком все еще просто ЛАТИНСКИЙ 1), таким образом, они не нуждались бы или имели бы для волнения о unicode и вероятно не поддерживают его (я не знаю, делают ли они или нет, но даже если они делают, это - просто пример).
"Сегодняшние приложения должны всегда быть совместимым Unicode".
, вероятно, более допустим выраженный как:
"Сегодняшние приложения должны всегда быть Unicode, совместимым, если ничто особые потребности для появления для обработки Unicode правильно, и ранее существующей кодовой базы или какой-либо другой части приложения не должно быть обновлено конкретно для поддержки его"
Как другие указали, это не просто стоимость устройства хранения данных.
длина столбца будет влиять на количество строк на страницу. Наличие меньшего количества строк на страницу означает, что меньше могут вписаться в Ваши кэши, который отбрасывает производительность. Я предполагаю, что в MSSQL, столбец NVARCHAR, который индексируется, израсходует больше пространства в индексе. Что означает меньше элементов индекса на блок, поэтому больше блоков в индексе, поэтому больше ищет при сканировании (или поиске) индексы, который замедляет индексный доступ также.
, Таким образом, это теряет Вас производительность на каждой передней стороне. Если Вы действительно не заботитесь (или может измерить уровень и довольны им, конечно), то это прекрасно. Но если у Вас есть подлинное требование для хранения unicode символов, конечно, используйте NVARCHAR.
я могу быть то, что пригодность для обслуживания, полученная при помощи NVARCHAR всюду по Вашей базе данных, перевешивает любую стоимость производительности.
Устройство хранения данных является менее дорогим, чем это когда-либо было исторически, но все еще если можно хранить вдвое больше данных на данном жестком диске, это привлекательно, не так ли?
Также существует RAM для кэширования и твердотельные диски, которые являются оба намного более дорогими, чем жесткие диски. Это выгодно для использования более компактных форматов данных, когда у Вас есть миллионы строк.
Я не эксперт по предмету. Но какая-либо причина, почему Вы не могли использовать UTF-8 для получения комбинации небольшого пространства и unicode?
Существует ли путь к Вашему серверу базы данных для использования UTF-8 в качестве кодирования? Вы тогда извлекаете пользу из низкого устройства хранения данных для главным образом загрузок ASCII и способность сохранить что-либо в диапазоне Unicode так, чтобы расширение было возможно.
я попросил бы, чтобы Ваш поставщик базы данных поддерживал UTF-8 как кодирование для VARCHAR тип SQL, также. Я не знаю, как другие серверы БД делают это, но я действительно знаю, что можно использовать UTF-8 в VARCHAR и TEXT поля, по крайней мере, в MySQL и PostgreSQL.
Все, что быть сказанным, хотя, единственная причина для не использует UTF-16, закодировало поле, - то, если необходимо взаимодействовать с приложениями, которые повредятся на входе UTF-16. Это было бы наиболее унаследованными приложениями, которые были разработаны для обработки ASCII или текстовой кодировки ISO 8815, которая будет более обеспеченной обработкой UTF-8.