Как интерфейс влияет на архитектуру. Контактные лица УНФ
Может ли интерфейс влиять на архитектуру БД? Казалось бы Нет, но на практике Да. Привожу пример из мира УНФ.
Контактные лица контрагентов реализованы не в виде табличной части КонтактныеЛица у контрагентов, а сделаны в виде регистра сведений СвязиКонтрагентКонтакт. Почему так?
Дело в том, что при добавлении нового контактного лица нужно создать для него элемент справочника КонтактныеЛица. Но как привязать этот созданный элемент к текущему контрагенту? Если бы контактное лицо хранилось в табличной части контрагента, нужно было бы сразу привязать это контактное лицо к контрагенту через запись карточки контрагента, иначе оно потеряется. Но пользователь может не хотеть записывать карточку при создании контактного лица. Это не очевидное требование.
Поэтому привязка связанных элементов справочников реализована не в табличной части. Если бы можно было записывать только табличную часть справочника отдельно, было бы другое дело.
Это не интерфейс влияет на архитектуру бд, а бизнес-модель, вписанная в рамки платформы 1с, реализуется тем или иным способом.
я не силен в терминах, но вот такое явление есть.
Причем тут интерфейс. Контактное лицо может быть одно и то же у разных контрагентов. Незачем плодить дубли.
прочитайте статью внимательнее. Там написано, причем тут интерфейс.
Табличная часть могла бы тоже содержать ссылки на КЛ, а не сами КЛ.
Табличная часть не элемент интерфейса.
Факт того, что ТЧ сохраняется (и существует) только вместе с основной сущностью — не относится к интерфейсу.
здесь речь о том, что способ использования данных (интерфейс) влияет на архитектуру данных, не более.
Можем обсудить именно конкретный случай.