zamichnikWKBAPKA...берем Access и пытаемся реализовать простой складской учет...
Полагаю, этот путь прошли многие :) Даже если довести до какого-то рабочего состояния, все равно получится что-нибудь а-ля 'Справочники, Документы и Регистры'
и я о том же... на выходе все равно прийдет логическое разделение таблиц на некоторые объекты или сущности

КантачесХод мыслей:
нужно связать контрагентов с программным продуктом (1:М), при этом контрагент может через какое-то время отказаться от одного ПП и купить другой -> структура: Контрагенты(1) -- РегистрСведений -- (М)ПП -> у справочников есть табличные части, в которых (думал только в рамках теории бд и sql) можно хранить "историю" -> Контрагенты.ТЧ -- ПП. То, что в рамках 1С это неправильно - я в курсе.
Интересно с точки зрения теории бд, т.к. я не уверен, что силен в ней, но по характеру интересно понимать, какие механизмы прячутся по той или иной оболочкой.

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

не нашел как редактировать, поправочка, справочники не могут двигать регистры накопления