Наименование справочника не больше 150 символов #631168

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

потому что

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

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

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

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

Началось.

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

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

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

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

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

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

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

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

кроссавчег!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не ЧСВ, это здравый смысл, теория СУБД и опыт. Вас же можно поздравить с наличием минимум одного из двух главных профессиональных качеств одноэсника.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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