Вопрос больше теоретический: почему так часто поступают, а не только в контексте 1С?

В конфигурации ДО (3.0) много связей через поля «Идентификатор», в которых хранится GUID. Можно было бы создать справочник, где эти идентификаторы были бы элементами без имени. Почему так не сделали?

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

Почему так делают? В чём преимущество?

Единственное, что приходит в голову касательно 1С, — это упрощение работы с полями составного типа. Вместо множества типов данных используется один — GUID, а остальное решает алгоритм. Для СУБД это проще. Но почему в реляционных СУБД редко хранят связи?

>>Реляционные базы данных обычно не хранят связи внутри себя

Это очень смелое утверждение, требующее аргументации

(0)[Реляционные базы данных обычно не хранят связи внутри себя.]
100% бред, реляционные базы созданы именно для этого

(0) Скорее всего, это вызвано тем, что определенный функционал ДО 3 должен работать через Api в системе, в которую интегрируется БИД (ERP, например, или ЗУП КОРП, или УХ).

(0) А зачем лишняя сущность?
Когда достаточно хранить УИД, причем из другой базы 1С

(1) (2) Покажите схему связей таблиц в базе данных информационной базы 1С. Где эта информация хранится в базе данных на уровне СУБД?
Много вы видели прикладных баз данных, которые есть в реляционных СУБД, и чтоб на уровне механизмов СУБД хранились связи? Даже Microsoft это не делает.

(4) (3) А вот это интересные варианты. 👍

(5) 1С использует СУБД без связей, но это не значит, что связи (FOREIGN KEY) не используются в других системах. А откуда информация, что не используются в майкрософт?

(7) Разгребал таблички SharePoint и Project server.

(5)[Много вы видели прикладных баз данных, которые есть в реляционных СУБД, и чтоб на уровне механизмов СУБД хранились связи?]
десятки, включая тиражные приложения

(0) Обход работы с полями составного типа для реализации бесшовной интеграции с другими продуктами. Где-то на вебинаре мне запомнилось, смотрел на тему что нового в ДО 3, там кто-то это вопрос задавал.

(9) Ну что ж. У нас разный опыт. Тут спорить не буду. Мне такие базы редко встречались, но надо признать встречались.
(10) 👍

Использование синтетического первичного ключа для таблицы - так себе. На курсе "теория субд" за это двойки ставили. Но это позволяет легко создавать базы, без серьезной аналитической предварительной работы по построению моделей данных и нормальных форм.

(0) "Реляционные базы данных обычно не хранят связи внутри себя. Логика взаимосвязей передаётся алгоритмам."

Да что ты чёрт побери такое несешь

(13) Он как бы правильно сказал
Но не совсем, забыл про внешние ключи
В самих таблицах никаких связей нет, там просто ключи (идентификаторы)
К какой таблице или таблицам относится ключ хз
Для этого служит дополнительная сущность, которая по истории реляционных СУБД появилась сильно позже (когда на практике столкнулись что надо где-то хранить), причем в теории никак не фигурирует
Т.е. связи это внешняя и дополненная сущность

(14)+ Кстати индексы - это тоже внешняя дополнительная хрень, к теории реляционных баз никак не относится
Как например и кэш в wiki:Архитектура_фон_Неймана

[Реляционные базы данных обычно не хранят связи внутри себя] - а что ты имеешь ввиду под "реляционной базой"?
Только набор табличек сам по себе или их же с "обвязкой" в лице СУБД?

Так-то, в теории, слово "relation" и есть "связь", собственно, поэтому они "реляционные".

(14) Как раз в теории со связями всё хорошо. На практике бывает по-разному

(17) Да сама теория подразумевает связи
Но их поначалу не хранили а подразумевали в алгоритмах

(0) Ничего не понял, но проблема видимо актуальная. :)

(18)+ Кстати в языке SQL это сохранилось как рудимент
Любое соединение всегда требует указать по чему соединяем
Даже если есть внешние ключи для некой связи таблиц

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

(16) Да, не однозначно выразил свою мысль. Тут больше "обвязка" с СУБД.

(21) Может
Речь о том, что связи (внешние ключи), могут быть не прописаны в базе.
Если этого не требуется для каскадного удаления и т.д.
На работу SQL запросов это никак не повлияет.

Т.е. выделение внутренних или внешних ключей это дополнительная фича.
Ну там проверка на дубли в случае внутренних ключей и ускорение (индексы автоматом создаются для ключа простого/составного).
Или цепные действия и т.д. в случае внешних ключей.

Вспомните теорию СУБД и нормальные формы. Введение уникального идентификатора строки хоть в виде УИДа, хоть в виде автоинкремента, вместо нормализации базы - это по сути читерство, облегчающее разработку, но делающее базу неоптимальной с точки зрения выборки данных. А 1с вся на этом и держится, по сути. В теории реляционных баз данных нет никаких "ссылок", это ересь.

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