MrShin....Маленькая хитрость - DAO не поддерживает DDL с каскадными связями, только ADO.
в PowerDesigner, например, пришлось подкручивать конфигурационные файлы, чтобы начал генерировать каскадные связи для акса.А так
?

ROIДа действительно они вредны.
Это есть у Гетца.ROI,
Вы не могли бы дать ссылку или хотя бы цитату привести?
А то я поискала в "Сборник рецептов для профессионалов", правда, на английском ("Acces Cookbook")
и в "Разработка настольных приложений в Access".
Но такого не нашла.
Подскажите, куда смотреть, пожалуйста.

Predeclared__Michelle... Влияет ли, и если влияет, то как, наличие связей на скорость обработки?...
Влияет.
Как?
Однозначного ответа в такой постановке вопроса не может быть априори.

Рассмотрим, например, лишь один момент.
При добавлении связи в таблицу с FK добавляется индекс, если он не был добавлен до этого вручную.
Как наличие индекса влияет на "скорость обработки"?
По-разному на разных операциях.С влиянием существующих индексов более-менее ясно.
Но вот сейчас провела эксперимент.
Убрала связь, убрала индекс, соответствовавший FK, снова создала ту же связь.
Индекс - не появился.
Что бы это значило???

Predeclared__Michelle...Вот, например, есть основная таблица и ряд справочников,
связанных с основной отношением 1 (справочник - счетчик) : М (осн.табл. - дл.целое).
При этом задавать обеспечение целостности данных смысла нет ... для удаления (невозможность удаления из справочника используемого значения обеспечивается программно в другом месте)...
Неужели вы всерьез рассчитываете, что ваше vba-решение будет работать надежнее
проверенного десятилетиями механизма Jet?Нет. Я, видимо, плохо объяснила. Попробую на примере.
Допустим, есть табличка-справочник фамилий с двумя полями.
И есть большая таблица с множеством полей, в том числе и поле с ключом из справочника фамилий.
То есть, в справочнике PK, в большой таблице FK (1:M).
Но разве можно ставить в зависимость от удаления записи из справочника удаление записи из большой таблицы?
Поэтому и не выставляется флаг каскадного удаления.
При этом в специальной форме работы со справочником дозволяется удаление только "свободных" значений.
Вот и вопрос. Надо ли прорисовывать такую связь? Чего больше, пользы или вреда?

Predeclared__MichelleИли вот. Основная таблица и ряд детализирующих таблиц...
...Но каскадное обновление смысла, очевидно, не имеет. Однако, по ошибке или по инерции задано.
Влияет ли наличие этого ненужного каскадного обновления на скорость обработки?
Нужно ли его вычистить или все равно?
Не проверял, но вычистить нужно!
:)Спасибо. Тоже так думаю.)))

vmag,

А я решила, что из подобных справочников удаляются только неиспользуемые значения.
В форме работы со справочником для каждого значения показано, где, в каком журнале
применено и в каком количестве. Заодно и частотность видна.
Плюс есть возможность редактирования.

Predeclared,

Проверяла не программно.
Глазами. В конструкторе таблицы вызвала окно индексов.
А где закопано?)))

Predeclared__Michelle,

Так надежней:

Применила.
Вылез только один индекс, основной, по счетчику.
А по полю, которое FK, индекса нету.
Тот же результат, что и глазами.

vmag__MichelleА я решила, что из подобных справочников удаляются только неиспользуемые значения.

практика показывает, что постановка задачи немного другая - юзеры хотят видеть только используемые значения, причем только те, которые актуальны на сей момент, вот и приходится давать им право принятия решения на сносУ меня другое мнение. Менять не собираюсь.
Решение об удалении принимает и удаляет, само собой, пользователь.
Но в заданных условиях, исключающих возникновение "мусора", как Вы выражаетесь.)))

Predeclared__Michelle...
Тот же результат, что и глазами.
Пример прицепите.Уже не надо.))) Эксперимент продолжился.
После задания обеспечения целостности (при этом ни каскадного обновления, ни каскадного удаления не задается)
индекс "глазами" не появляется, но программно выскакивает.
После снятия галки индекс исчез отовсюду.

Можно ли как-то сделать, чтобы окно индексов показывало правду?

vmagВообще то наши мнения совпадают...Вот и хорошо!)))

Predeclared......В этом примере речь о каскадном удалении.
Здесь оно, конечно, ни к чему.

По первому вашему примере речь об обеспечение целостности данных.
Я из цитаты вашего текста намеряно "вырезал" троеточием кусок о каскадном удалении,
что бы не мешать все в кучу.Этот пример был, чтобы спросить, нужны ли такие "пустые" связи в схеме?
Как иллюстрация, наверное, да.
Но приносят ли они какие-то обременения? Наверное, нет, или совсем незначительные?