Добрый день.
Есть регистр сведений, там будут храниться пути к файлам, в среднем будут символов 100 не больше. На данный момент поставил тип реквизита Неограниченная строка, размер базы вырос чуть ли не в 2 раза. Конечно записей в регистре много, но насколько я знаю для реквизитов неограниченной длины не выделяется место?
Подскажите, как лучше хранить такие строки, и почему база выросла, если данных еще нет в данных реквизитах?

P.S. В базе около 100 тыс записей в этом регистре.

(0)Делай 150 символов и все встанет на место. Хотя гдето слышал что в 8.3 проблему увеличения размера базы от неограниченных строк вроде решили.

(0) наверно у вас была полностью типовая конфа до этого, а теперь измененная

(2) Конфа самописка. Релиз платформы 8.2.18.109

С сайта http://its.1c.ru/
1.4 Если длина строки не регламентирована, то рекомендуется выбирать такую длину, которой достаточно для хранения данных в большинстве случаев. Например, для хранения полного наименования контрагента в подавляющем большинстве случаев достаточно 250 символов, максимальная длина имени файла в большинстве файловых систем – 260, полное имя физического лица – 100 и т.п.

Ну а еще свойство Допустимая длина ставь в значение Переменная.

(0) 255 символов в мелкомягкой системе

(0) Ну во первых (5)
Во вторых. Если хочешь заморочиться с объемом хранимой информации то вот вариант.
Хранить все пути в текстовом файле упакованном Zip. В регистре хранить номер строки в этом файле.
Файл можно хранить в хранилище значений в константе или еще где. Но это извращение. Сжиматься будет хорошо, т.к. пути скорее всего будут иметь общее начало. Так же можно стандартизировать путь.
Ну в общем вариантов уйма.

(5) а если добавить в начало префикс "\\?\" ?

(7) а пофик, где то читал константа в винде стоит на максимальную длинну 256

100 000 *100 = 10 млн.
умножить на 2, да хоть на 10
100 Мб будет
это разве те объемы о которых стоит думать?

(0) "размер базы вырос чуть ли не в 2 раза" - если клиент-сервер, трехзвенная база, то это не сервер 1с "виноват", а сервер базы данных прихватил "с запасом" место (согласно своим настройкам). Ваш кэп.

Длина пути 255 была во времена имен файлов ~8.3

NTFS: общее ограничение - до 32767 символов Юникода; длина каталога или имя файла — до 255 символов.
Ваш Кэп.

PS: делай неограниченную строку.

(5) это имя файла 255 символов. ты ещё не учел путь до этого файла.

(8) Ну, поздравляю с успешным завершением анабиоза!
https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath

(14) (12)  Это пути в NTFS. А если он собирается хранить пути из сетевой файловой системы (NFS)?

а если он с САП соберется интегрироваться, то вообще придется обходиться 100 символами и без русских букв. всего не предусмотришь, не зная общей ситуации. исходить из разумной достаточности, при возникновении проблем анализировать причины. идеального решения на берегу никогда не принять. и уж точно не стоит принимать решения, даже которое выглядит идеальным если оно имеет проблемы с дальнейшей модификацией/расширением.

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

по этому строки неограниченной длинны и имиджи имеют такое хитрое поведение по раздуванию базы совсем не кратно размерам данных...

(17)
то есть если мы переделили колонку как "неопределеной длинны" то в строке с короткой строкой - вся строка поместится в колонке и блоба не будет вовсе....

(15) Продам учебники английского. За отдельную плату научу читать.
Это WinAPI. Ограничения файловой системы - вообще другой разговор. Ты еще про Fat16 расскажи и регистрозависимость.