2010-05-19 3 views
6

Почему каждая СУБД настаивает на том, что вы скажете, какая максимальная длина текстового поля будет ... почему он не может просто вывести эту информацию из данных, которые помещены в базу данных?Почему мне нужно установить максимальную длину каждого столбца текста в базе данных?

Я работал в основном с MS SQL Server, но каждая другая база данных, которую я знаю, также требует, чтобы вы установили эти произвольные ограничения в своей схеме данных. Реальность заключается в том, что это не особенно полезно или дружелюбно работать, потому что бизнес-требования меняются все время, и почти каждый день какой-то конечный пользователь пытается помещать много текста в этот столбец.

Кто-нибудь, обладающий некоторыми внутренними знаниями о СУБД, знает, почему мы просто не делаем вывод о границах данных, помещенных в хранилище? Я не говорю о том, чтобы угадать информацию о типе, но угадывая пределы определенного текстового столбца.

Я имею в виду, что есть причина, по которой я не использую nvarchar (max) для каждого текстового столбца в базе данных.

+0

У меня нет «внутреннего рабочего знания РСУБД», , но я не понимаю, почему вы думаете, что это проблема. Существуют несвязанные типы данных, такие как CLOB. Если это то, что вы хотите, используйте его. Если вам нужно облегчить сравнение текста, вам придется страдать от печатания (255) или чего-то еще. Кажется, не стоит жаловаться на меня. Но это всего лишь мои два цента. – MJB

+2

Стоит отметить, что SQLite не налагает это требование. – cikkle

+0

Логически невозможно вывести максимальную длину из фактических данных. Как долго база данных будет ждать, пока она решит: «ОК, я думаю, здесь не будет больше 255 символов»? –

ответ

5

Потому что компьютеры (и базы данных) глупы.Компьютеры не догадываются очень хорошо, и, если вы не скажете им, они не могут сказать, что столбец будет использоваться для номера телефона или копии «Войны и мира». Очевидно, что БД может быть сконструирована таким образом, чтобы каждый столбец мог содержать бесконечное количество данных - или, по крайней мере, столько, сколько позволяет пространство на диске, но это будет очень неэффективный дизайн. Чтобы получить эффективность, мы делаем компромисс и заставляем проектировщика сообщать базе данных, сколько мы ожидаем положить в столбец. Предположительно, может быть установлен по умолчанию, так что если вы его не укажете, он просто использует его. К сожалению, любой дефолт, вероятно, будет неуместным для подавляющего большинства людей с точки зрения эффективности.

+0

Столбец, содержащий номер телефона, обычно будет содержать около 10 символов. Когда это так, для базы данных имеет смысл рассматривать это как say varchar (13). Для столбцов, которые сильно различаются там, где нет единого мнения, худшим случаем было бы то, что столбец по умолчанию имеет значение varchar (max), и для этих сценариев было бы полезно иметь самонастраивающийся текстовый тип данных. –

+0

@John - так что вы действительно спрашиваете, не для текущих баз данных просто вывести по умолчанию, а скорее, что механизмы хранения базы данных принципиально меняют способ распределения хранилища. Я, честно говоря, не проводил много исследований по этой теме, но я бы предположил, что в конечном итоге схемы вроде этого в конечном итоге вытаскивают персональные данные в свой «контейнер», как и с теми же проблемами varchar (max). Это интересный мысленный эксперимент, но не особенно актуальный для моей повседневной работы. – tvanfosson

+0

Наверное, я. Хотя, я считаю, что тип данных varchar (max) намного лучше для этих сценариев, чем я сам думал. Похоже, что на самом деле он принимает некоторые решения в области хранения/вывода из строя в зависимости от размера значения. –

0

Я думаю, что это потому, что РСУБД использует случайный доступ к данным. Чтобы делать случайный доступ к данным, они должны знать, на каком адресе на жестком диске они должны перейти, чтобы быстро прочитать данные. Если каждая строка одного столбца имеет разную длину данных, они не могут сделать вывод о том, что является начальной точкой адреса, на который они должны прыгать напрямую, чтобы получить его. Единственный способ - загрузить все данные и проверить их.

Если СБДМ изменяет длину данных столбца на фиксированное число (например, максимальную длину всех строк) каждый раз, когда вы добавляете, обновляете и удаляете. Это чрезвычайно трудоемко.

+0

, за исключением того, что им удаётся по-настоящему оптимизировать это с помощью varchar - carchar (3000) все равно не выделяет все 3000 байтов;) – TomTom

+0

@Tomtom - кажется, что нет аргументов в пользу того, чтобы не устанавливать каждый из них (8000), поскольку память это не проблема. – JeffO

1

This post не только отвечает на все вопросы относительно того, следует ли использовать nvarchar(max) всюду, но также дает представление о том, почему базы данных исторически не допускают этого.

1

Это как сказать, почему мы не можем просто указать базу данных, которую хотим получить в таблице, и дать ей понять, какой тип и сколько столбцов нам нужно из данных, которые мы даем.

Просто мы знаем, что лучше, чем база данных. Предположим, у вас есть один шанс на миллион в 2000 строк в базу данных, большую часть времени - 100 символов. База данных, вероятно, взорвет или отменит строку символов 2k. Он просто не может знать, что вам понадобится длина 2k, если в течение первых трех лет вы ввели только 100 строк длины.

Кроме того, длина символов используется для оптимизации размещения строк, чтобы строки могли быть прочитаны/пропущены быстрее.

0

В чем будет базироваться БД? Если требования бизнеса меняются регулярно, это будет так же удивительно, как и вы. Если есть причина, вы не используете NVARCHAR (макс), то, вероятно, причина, это не по умолчанию к этому, а также ...

2

Это связано со скоростью. Если задан максимальный размер строки, вы можете оптимизировать способ хранения информации для более быстрого ввода-вывода. Когда скорость ключевая, последнее, что вы хотите, это внезапное перетасовка всех ваших данных только потому, что вы изменили аббревиатуру состояния на полное имя.

С максимальным размером базы данных база данных может выделять максимальное пространство для каждого объекта в этом столбце и независимо от изменений в значении, которое не требуется изменять адресному пространству.

+1

но это не так - плохие новости. Любая достойная база данных НЕ использует 3000 байтов для хранения поля varchar (3000) с только 4 символами;) Давным-давно - их. С 20 лет - нет. – TomTom

+1

@TomTom: Однако для базы данных полезно знать, что поле varchar (3000) не будет содержать более 3K символов. Очень сложно настроить хорошее сопоставление строк с дисковыми секторами, не зная, как большая строка может получить. –

+0

Как я могу сказать, что mycolumn varchar (max) отличается от базы данных, запрашивающей таблицу для MAX (LEN (mycolumn))? В какой-то момент времени он всегда сможет сказать, что mycolumn строки имеет определенный размер, но размер не будет постоянным. –

0

Для примера, я собираюсь перейти на несколько зыбучих песков и предложить сравнить его с приложениями, выделяющими память (ОЗУ). Почему программисты не запрашивают/не выделяют всю память, которая им нужна при запуске программы? Потому что часто они не знают, сколько им нужно. Это может привести к тому, что приложения будут захватывать все больше и больше памяти при их запуске и, возможно, также освобождая память. У вас одновременно работает несколько приложений, запускаются новые приложения и закрываются старые приложения. И приложения всегда хотят смежных блоков памяти, они работают плохо (если вообще), если их память разбросана по всему адресному пространству. Со временем это приводит к фрагментированной памяти и всем этим проблемам сбора мусора, которые люди отрывают свои волосы на протяжении десятилетий.

Перейти к базам данных. Вы хотите, чтобы это случилось с вашими жесткими дисками? (Помните, что производительность жесткого диска очень высока, очень медленный по сравнению с операциями с памятью ...)

+0

Я не вижу, как это уместно. Я бы никогда не позволил пользователю управлять произвольными выделениями памяти. Это просто безответственный и потенциально угроза безопасности. База данных может составлять разум на основе статистики, если консенсус не может быть достигнут, тогда он по умолчанию говорит varchar (max), однако это вряд ли произойдет каждый раз. –

0

Похоже, что ваше бизнес-правило: введите как можно больше информации в любом текстовом поле, чтобы вы не получили сумасшедший в DBA.

Вы не разрешаете пользователям вводить 5000 символов, поскольку они не помещаются на конверте.

Вот почему у Твиттера есть текстовое ограничение и с легкостью избавляет всех от необходимости читать через кучу бессмысленной болтовни, которая продолжается и продолжается, и никогда не доходит до сути, но только умудряется, что он заставляет задуматься, почему у вас есть такие неудобства для своего времени, выбирая эгоцентричный и бесчеловечный образ жизни, ориентированный на продвижение акта копирования и вставки как можно большего количества данных, так как боги буфера памяти позволят ...

Смежные вопросы