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

Есть мысль сделать общий справочник для всех объектов в системе
что то типа номер,имя,тип,[ссылка на расширенные свойства]
где будут все справочники
Контрагенты вместе с товарами , счетами банковскими и т.д.

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

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

Стоит ли заморачиватся?

>А что за продукт:
Базка на MDB-ном Access сделана
предметная область бетонный завод
(привезли сырье - перемешали по рецепту - продали)
приход/расход дебиторка/кредиторка касса/шмасса
ну еще некоторые специфичкские цветные диаграмки/отчетики кот начальство из холдинга глядеть любит

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

>А если контрагент и клиент и заказчик, две записи делать?
сейчас типа того
Ну клиентов с поставщиками я объеденю канешна
а потом легко разъеденю по наличию документов (договоров на поставку/закупку и т.п.)
- тут у мине сомней нету
а вот объеденять ли клиентов с товарами
в этакий панимаиш глобальный справочник всех объектов системы

>простоту создания регистров оценить не могу, т.к. не являюсь специалистом по 1С.
1C тут совсем не причем
(меня вообще радует привычка 1С-цев присваивать авторство на то что существовало задолго до появления 1С в принципе )
регистр - стандартный инструмент практически любой системы учета
некаяя таблица накапливающая результаты операций над объектами учета
чтобы потом можно было легко отчеты построить
как та или иная характеристика ОУ изменялась во времени
например оборотносальдовую ведомость по счетам
Причем эти изменения ,как правило, приходится потом агрегировать
с учетом некой структуры связей между ОУ аля направленный граф
(или частного упрощенного случая оного "дерево" типа счета/субсчета)

>А что мешает добавить эти поля во все таблицы справочников, стесняюсь спросить?
в общем ниче не мешает
но обычно это не только поля а целый ворох функционала
ХП-ки форрмы разные и т.д.
2-3 разницы никакой скопировал и будя
когда 10-20 вроде намечается реальный выигрышь от единой структуры

но поскольку до конца так не делал ни разу
думаю стоит вообще заморачиватся или ну его.