Почему я должен установить макс. длину каждого столбца текста в базе данных?
Почему случается так, что каждый RDBMS настаивает, чтобы Вы сказали это, чем макс. длина текстового поля будет..., почему это не может только вывести эту информационную форму данные, это помещается в базу данных?
Я главным образом работал с SQL Server MS, но любая база данных, я знаю также требования, чтобы Вы установили эти произвольные пределы для своей схемы данных. Действительность - то, что это не является особенно полезным или дружественным для работы с becuase изменения бизнес-требований все время, и почти каждый день некоторый конечный пользователь пытается поместить много текста в тот столбец.
Кто-либо с некоторым внутренним практическим знанием RDBMS знает, почему мы просто не выводим пределы из данных, это помещается в устройство хранения данных? Я не говорю о предположении информации о типе, но предположении пределов конкретного столбца текста.
Я имею в виду, существует причина, почему я не использую nvarchar (макс.) на каждом столбце текста в базе данных.
9 ответов
Потому что компьютеры (и базы данных) глупы. Компьютеры не очень хорошо угадывают, и, если вы им не скажете, они не могут сказать, что столбец будет использоваться для номера телефона или экземпляра журнала «Война и мир». Очевидно, что БД может быть спроектирована так, чтобы каждый столбец мог содержать бесконечное количество данных - или, по крайней мере, столько, сколько позволяет дисковое пространство, - но это было бы очень неэффективным дизайном. Таким образом, чтобы добиться эффективности, мы идем на компромисс и заставляем дизайнера сообщать базе данных, сколько мы ожидаем поместить в столбец. Предположительно, может быть значение по умолчанию, так что, если вы его не укажете, он просто будет его использовать. К сожалению, любой дефолт, вероятно, будет неприемлем для подавляющего большинства людей с точки зрения эффективности.
Это связано со скоростью. Если указан максимальный размер строки, вы можете оптимизировать способ хранения информации для более быстрого ввода-вывода. Когда скорость является ключевым моментом, последнее, что вам нужно, - это внезапная перетасовка всех ваших данных только потому, что вы изменили аббревиатуру состояния на полное имя.
При установленном максимальном размере база данных может выделить максимальное пространство для каждого объекта в этом столбце, и независимо от изменений значения адресное пространство не должно изменяться.
Это все равно что сказать, почему мы не можем просто сказать базе данных, что нам нужна таблица, и позволить ей сделать вывод, какой тип и сколько столбцов нам нужно, на основе данных, которые мы ей предоставляем.
Просто мы знаем лучше, чем база данных. Предположим, у вас есть шанс один из миллиона поместить в базу данных строку из 2000 символов, в большинстве случаев это 100 символов. База данных, вероятно, взорвется или откажется от строки из 2К символов. Он просто не может знать, что вам понадобится длина 2k, если в течение первых трех лет вы вводили только 100 строк длины.
Кроме того, длина символов используется для оптимизации размещения строк, чтобы строки можно было читать / пропускать быстрее.
На чем основывает свою догадку БД? Если бизнес-требования меняются регулярно, он будет так же удивлен, как и вы. Если есть причина, по которой вы не используете nvarchar (max), вероятно, есть причина, по которой он также не использует его по умолчанию ...
проверьте этот протектор http://www.sqlservercentral.com/Forums/Topic295948-146-1.aspx
В качестве примера я собираюсь перейти к некоторым зыбучим пескам и предложить вам сравнить их с приложениями, выделяющими память (RAM). Почему программисты не запрашивают / не выделяют всю необходимую память при запуске программы? Потому что часто они не знают, сколько им понадобится. Это может привести к тому, что приложения будут захватывать все больше и больше памяти во время работы и, возможно, также высвобождают память. И у вас одновременно работает несколько приложений, запускаются новые и закрываются старые. А приложениям всегда нужны непрерывные блоки памяти, они работают плохо (если вообще работают), если их память разбросана по всему адресному пространству. Со временем это приводит к фрагментированной памяти и всем тем проблемам со сборкой мусора, из-за которых люди рвали волосы на протяжении десятилетий.
Вернуться к базам данных. Вы хотите, чтобы это случилось с вашими жесткими дисками? (Помните, что производительность жесткого диска очень, очень медленная по сравнению с операциями с памятью ...)
Я думаю, это потому, что СУБД использует произвольный доступ к данным. Чтобы выполнить произвольный доступ к данным, они должны знать, на какой адрес жесткого диска они должны перейти, чтобы быстро прочитать данные. Если каждая строка одного столбца имеет разную длину данных, они не могут сделать вывод, какова начальная точка адреса, по которому они должны перейти напрямую, чтобы получить его. Единственный способ - загрузить все данные и проверить их.
Если СУБД изменяет длину данных столбца на фиксированное число (например, максимальную длину всех строк) каждый раз, когда вы добавляете, обновляете и удаляете. Это занимает очень много времени
Этот пост не только отвечает на ваш вопрос о том, следует ли использовать nvarchar (max) везде, но также дает некоторое представление о том, почему базы данных исторически не использовались не допускаю этого.
Похоже, ваше бизнес-правило таково: введите столько информации, сколько хотите, в любое текстовое поле, чтобы не злиться на администратора базы данных.
Вы не разрешаете пользователям вводить адреса из 5000 символов, так как они не поместятся на конверте.
Вот почему в Твиттере есть ограничение по тексту, что избавляет всех от необходимости читать кучу бессмысленной чепухи, которая продолжается и продолжается и никогда не доходит до сути, но только приводит в ярость читателя, заставляя его задуматься, почему у вас такое пренебрегая своим временем, выбирая эгоцентричный и бесчеловечный образ жизни, сосредоточенный на продвижении акта копирования и вставки столько данных, сколько позволят боги буфера памяти ...