Технически из-за чего такое ограничение дядьки из 1С реализовали.

потому что

и это официальная позиция 1С

(0) А зачем больше-то?

(0) а не влезало больше в ТЧ при разрешении 800*600

В индустрии 1С г0внокода и без наименований в 1000 символов достаточно.

Началось.

Я же написал, что интересны проблемы с которыми они столкнулись при наименовании > 150 символов

(6) сам виноват :-)

(0) а в чем собственно проблема то ?

(7) здравый смысл - это проблема?

(7) Индексы, вестимо :-(

(9) в индексах может быть

(10) он уже давно у адинеснегов не в авторитете

(11) Я сделал реквизит на 300 символов и поставил переключатель в индексирование. Все ок.

(14) кроссавчег!

(14) Наименование, кажись, в нескольких индексах используется. И "все ок" (поставился переключатель) не одно и то же с "работает быстро на больших объемах"

(14) Сделай 500 или 1000 - так круче

И измерения регистров строками

(14) я думаю тебе надо 29го числа на семинаре 1С во время речи БН выйти на сцену, и рассказать о своем открытии.

зал будет рукоплескать стоя..

ты станеш уважаемым и известным 1Сником...

(15) Лучше бы написал, что наименование участвует в индексировании записи по сравочнику. Умняшечка фигов

Но могли бы, конечно, не делать явного ограничения.
Сделали бы неявное индексирование по первым 25 символам, а так - хоть три тыщщи символов вбивай.

(14) Это ТВОЙ ЛИЧНЫЙ ВЫБОР, который ты сделал осознанно, зная параметры твоей базы, текущий и предполагаемый размер твоего справочника, необходимость применения индекса и пр. и пр. и пр.

А вот поле Наименование у справочников - это поле индексируемое в обязательном порядке (вне зависимости от желаний разработчика). И если размер этого поля сделать например в 400 символов и наколбасить в этот справочник несколько сотен тысяч элементов (а лучше несколько миллионов), то это может заметно сказаться на размере индекса и на производительности системы при работе с таким справочником.

(21) и тогда армия адинеснегов использующих НайтиПоНаименованию села бы в лужу? :)

(21) а контроль уникальности по индексам в таком случае?

(14) Хреново что неограниченную строку не проиндексировать. Вы бы развернулись...

(21)
...
Поскольку для хранения данных 1С:Предприятие использует СУБД (либо встроенную, либо Microsoft SQL Server), то и поддержка индексов таблиц базы данных целиком возложена на используемую СУБД
...
Насколько помню, по первым символам только в MySql можно индексы строить

(26) "Насколько помню, по первым символам только в MySql можно индексы строить"
Насколько я помню, в foxpro индексы вообще задавались в виде выражения c использованием функций, в том числе и определенных пользователем в коде! :)

(21) А смысл в таком индексе?

Правильный ответ в (16). Можно закрыть, а то фантазия и ЧСВ Джинов Шухардов Нуфов переполнят их и они взорвутся.

(27)
Я имел в виду серверные СУБД

(27) Давно 8.х на фокспре работает?

(29) Это не ЧСВ, это здравый смысл, теория СУБД и опыт.

Вас же можно поздравить с наличием минимум одного из двух главных профессиональных качеств одноэсника.

(32)  Я где-то написал в теме, что это ограничение неправильно. Хотел для себя понять. Но тут вас всех прорвало.

(33) Вы не хотели ничего понимать.

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

(35) У них другие индексы в формах используются или еще где-нибудь.

(35) Пользователи поиск ведут не по сущности, а по наименованию.

длиные наименования надо хранить в полном.
Кстати да конкретный косяк фирмы 1С что наименования всего 100 символов. Причем это касается и номенклатуры поставщиков в УТ11.

(37) Кто по чему хочет - по тому и ищет. Наименование для справочника - априори навязанная и не естественная сущность.

(39) Вы предлагаете пользователям искать по GUID, а не по наименованию?

(37) поиски надо любые делать запросами и не Спр.НайтиПоНаименованию.
И кстати при загрузке никто тож не мешает делать обрезку поисковой строки до 100 символов. Врдяли там найдется номенклатура у которой со 101 символа идут отличия.
У меня все поиски (больше 10 вариантов), одни из которых ограничивают строкуимпорт (проверка) до количества символов справочника и ищет - в любом из случаев срабатывает контроль если найдено больше 2х дублей. Пока что дубли не выпдали.
Другим решением является поиск по полному наименованию.

И самое важное как я писал - выполнять следует запросами и забить на стандартные метод - поиск по наименованию.
Во первых он никогда не выдаст дубли.

(40) Какая разница по чему искать. Вопрос в том чем наименование отличается от других полей таблицы справочников.

(42) тм что предопределенные поля всегда индексируются полнтекстовым (епнутым) поиском.

(41) С запросами согласен, с наименованием нет. Пользователи часто копируют элемент и в конец его поля наименования вставляют свой комментарий.

(42) В том, что оно предопределенное

(44) за такое заведение номенклатуры убивать надо.

(45) Это в платформе зашито, а SQL без разницы какое это поле предопределенное или нет.

(41) О да, в списке номенклатуры пользователь должен обязательно запросом искать! Без навыков кодирования кладовщику никак вообще.

в компьютерной торговле там наименования 300-500 под 1000 выходят. кстати да. при загрузке таких прайсов опа.

(48) а почему нет? я написал в списке поисковую строку на запросах - работает просто офигенно! никаких полнотекстовых. Своими методами запросы по любым слогам и словам - просто бомба! летает! а ищет как точно.
И все на зпросах.

(47) в платформе защит дурацкий полнотекстовый поиск. он вешет всю систему.

(50) Охренеть! Вы открыли для себя возможности типовой конфигурации!

(52) не понял и каких возможностях идет  речь. там поиск сделан через опу.