Пусть есть справочник Товаров.
На текущий момент предположим он достаточно велик, пусть 50 тыс записей.

Возникла необходимость добавить ещё одно текстовое поле, неограниченной длины /ещё одна характеристика товара/.

Оно будет заполнятся примерно у одного товара из 100.

Каким образом красивей решить данную ситуацию? Через добавление нового поля у справочника, или через создание отдельного справочника?
И если отдельного справочника, то через подчинённый справочнику товаров или не связанный с ним?

В подчиненном справочнике ИМХО есть смысл, если значений этого поля может быть у одного элемента справочника несколько. Если всегда одно - то проще реквизит добавить и не мучиться. Все равно, в случае неограниченной длины, физически данные будут в отдельной таблице храниться.

(0) Лучше создать подчиненный справочник. Или доп. значения использовать. Кто знает, может, еще через 50 тыс. записей захотят добавить еще один реквизит?

(1) авотхрен! Подчинённость - не обязательно "один ко многим". Это "один к любому количеству". Каковое может быть и нулем.

(0) посмотри, как сделаны в типовой тис свойства номенклатуры, и сделай так же.

(1) Лучше создать отдельный справочник со ссылкой на справочник "Товары". Подчиненные справочники штука удобная, но работать с ними неудобно, когда нужно быстро вытащить данные из базы.

(6) если использовать нормальные запросы - то несложно. но тут как всегда - меняем объем на время.

(4) Это понятно. (5) в двух словах - как?
Отдельный справочник, в котором одно из поле - это справочник товаров?

лучше и добавить 2 реквизита в существующий товар так как поле не ограниченной длины все равно хранить в другой таблице 1sblob  по моему , так что существенного увеличения справочника не будет
а плюшек больше от такого решения проще код и так далее

чем проще ко тем легче его потом вспомнить

новый справочник есть смысл только одном случае если будешь в дальнейшем обновлять
ТИС к примеру и то нужно еще подумать так как код показа данных этого справочника
все равно придется тащить в код формы который будет довольно таки громоздким

так что я бы добавил реквизиты и не мучался совестью

(9) проще вспоминать не простые вещи, а правильные. Поэтому лучше сразу сделать правильно - и тогда "добавлять реквизиты" можно будет в пользовательском режиме, без всяких дописок и разбирания кода. ровно то же касается и отчетов.

(7) Я сторонник работы с данными 77 исключительно штатными средствами. Считаю, что гораздо проще создать индексированный реквизит и написать по нему выборку, которая будет работать очень быстро для 77, и будет проверяемой в отладчике. "Чорные" запросы - штука крутая, но это чёрный ящик.

(12) вот и нужно использовать нормальные запросы, прямые. которые, в отличие от чОрных - не являются черным ящиком.
и проверяются они нормально. и пишутся нормально - и всегда знаешь, что ты получишь и почему.
ну и метание между клюшечным (переборы) и снеговиковным (запросы) подходом сглаживается...

(13) А что не так в чОрных? Вроде простые, как мычание...

(13) Я уже года полтора как отошел от 77, тттт. Ваше предложение отклоняется ))

(14) соединений всяких не хватает, условий, группировок...

(14) Это потому, что я расист!

(15) да я уж тоже последний год только зики обновлял.

(17) не люблю две вещи - расизм, и негров...©
ради удобства работы почти сразу ушел на прямые, и за лет 12 так и не освоил чОрные в клюшках.

(11) Не совсем понимаю вашу позицию, в чём плюсы отдельной таблицы?
Раз строка неограниченной длины не увеличивает по размеру справочник, то в чём плюсы?

(20) Ну плюс как минимум в том что эта строка не будет загружаться каждый раз при любом обращении к объекту, он ведь целиком читается в том числе и в чёрных запросах, даже если нужно только наименование.

(21) Тогда получаем - каждое поле в отдельный справочник? :)

(22) Это почти 5я нормальная форма...

(0) Красивей всего перейти на 8-ку

Неужели в данном вопросе истина не одна? )

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

(24) :) при любой непонятной фигне - переходите на 8ку?

Ну, если планируется в пользовательском режиме еще добавлять... То, да. А так, отдельный реквизит.

Если проблема со временем добавления реквизита в справочник - поищите, была моя тема, совсем не давно, как это делать быстро.

(26) В том плане, что очень долго индексация идёт?

(0) ничего не кодить, добавть свойство номенклатуры

(30) Ну на 50 тыс записей не долго.
Но вот если их 500000 - 1000000 уже да долго.

(31) нет у него свойств.... там вообще конфига лет на 7 расстрела...

(21) с точки зрения 1с нет плюсов в отдельной таблице все и так быстро работает а удобство обращение
спр.РеквизитХХХ  все перевешивает
все таки 1с это не чистая база в понятиях нормализации
и тут прежде всего рулят быстрота сопровождения отладки и так далее

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

(24) зачем если и так работает зачем ломать то что отлично работает
переход на 8-х не всегда оправдан

(34) ох, знал бы ты, как достало это "удобство обращения перевешивает"...
"прежде всего рулят быстрота сопровождения отладки и так далее" ага, и копипаст, мля, копипаст!
накопипастят, а потом удивляются почему отчет работает 15 минут вместо 30 секунд...

(34)"один минус есть это если справочник огромен то займет много времени может сутки если не делать определеных манипуляций"
Да там манипуляции не сложные, на 10 минут с перекурами... С использованием стороннего редактора DBF, вот, я подробно описывал: Как быстро добавить реквизит в "большой" справочник?
Там, в середине темы, подробная, пошаговая инструкция.

(37) а если добавить "свойством", то и манипуляций не надо совсем, и даже кодить не надо.

+(38) не то, чтоб я боялся ручных манипуляций с таблицами/индексами/данными (в общем, я втуда умею)- просто если есть возможность сделать один раз универсально, расширяемо (без кодинга), устойчиво, и не нуждающееся в обслуживании - почему м не сделать именно так?

(34) Хех..
Забываешь добавить одно маленькое но очень важное "Но". Все это "..и так быстро работает.." пока сидишь в локальненькой DBF базе.
И почему это тут утверждают что "..Все равно, в случае неограниченной длины, физически данные будут в отдельной таблице храниться.."
В случае SQL это в той же самой таблице колонка типа text.
И когда начинают по сети у SQL сервера запрашивать черным запросом такие
реквизитики оно резко вдруг становится совсем не ".. и так быстро работает".

(37) А вы уверены, что сможете правильно добавить реквизит "неограниченной длины"?

(40) не знаю всегда работало и не тупило а тут резко xex
36ГБ 56 юзверов taySQL модуль + 1С++ и ничего не тупит от слова совсем
и сервер не сервер а так железка i5 еще древний

и в задаче нет слова SQL база от слова совсем совсем

(42) А в задаче и слова DBF не от слова совсем :)
И вот неужели твой toySQL объекты целиком из базы таскает или все таки только запрошеные поля, да и при этом всю логику отбора, группировки, сортировки и прочего делает средствами скуля.
А ведь ".. С точки зрения 1С" это делается совсем по другому. ВСЕ участвующие объекты в полном составе включая табличные части документов даже если в запросе нужны только реквизиты шапок выкачиваются и обрабатываются у клиента.

(41)А это вопрос конечно интересный... По идее, если на пустой дбф-ке, в конфигураторе добавить реквизит неограниченной длины, то создастся отдельная таблица, пустая... Надо посмотреть, что будет в новой колонке пустой дбфки, и если ничего(реквизит то пустой тоже) - то проблем нет, а если там ссылка на эту новую таблицу, тогда проблема...
(42)(43)Ну, действительно нет в задаче ни слова, какая база. Но, если человек боится, что долго будет добавляться реквизит - то ясно, что дбф... Вроде как sql такая проблема и не возникает, не даром советовали при добавлении реквизита перевести временно базу на sql, а потом вернуть обратно(хотя, как я понимаю, это тоже не быстро).

(44) Всё строки неограниченной длинны хранятся в 1sblob.dbf, не будет никаких новых таблиц.

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

(45)одновременно! :-)

(46) Ну так в этом и суть. Все строки в одной таблице и каждый раз когда нужно просто получить допустим наименование 1С будет искать и читать все поля из таблицы самого справочника и перечитывать этот blob столько раз, сколько есть неограниченной реквизитов в справочнике.