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

Попробую объяснить к какой архитектуре построения БД я пришел пока. Занесение данных у меня строится на 3 уровнях. 1-ый уровень "Слова". Создается вспомогательная таблица для обозначения групп слов например "Имя"-код 2, "Фамилия"-код 3. Затем создается таблица на слова или группу слов-например название организации. В таблицу добавляется "Код группы". Данные заносятся через основную форму группы в подчиненную группу слова, где код группы вносится автоматически. Т.е заходя в форму вы видите надпись "Введите новое имя". В ячейку "Код группы" автоматически вносится 2. При внесении данных могут возникнуть повторы слов, их надо убирать. Через перекрестный запрос через сумму "Код Слова" + "Код Группы" определяем Код первого внесенного слова из возможных повторов. Затем через связь таблицы и перекрестного запроса через Слово определяем уникальный код для слова. Например внесено имя "Иван" с кодом 2 и 5. Через запрос уникальный код для обоих записей будет 2.

Второй уровень. Самодостаточный набор данных из слов определяющий определенную группу данных. Например Личность составляет неизменяемый набор данных - Фамилия, Имя , Отчество, дата рождения. Можно сказать набор этих данных составит на 99% уникальность личности и составит Уникальный код данной записи. В форме при занесении записи в поле вносится Код слова через подстановку с ограничением по соответствующей группе. Дальше в запросе через связь один-к-одному соответствующих запросов вносимых данных Код Слова заменяется на уникальный Код слова. Уникальный код записи выводится в виде кода репликации всех уникальных Кодов Слова. Затем также через перекрестный запрос находим повторяющиеся записи и выведение уникального кода. Кстати первая запись в Словах всегда Null, а в таблицах второго уровня в первой записи данные = 1. Ну бывает нет отчества, тогда уникальный ключ = 1.

Все бы хорошо. Законченный набор данных ни к чему не привязанный, который можешь использовать в дальнейшем, а можешь и нет. Но, за счет вычислений на первом и втором уровне, связи с запросами начинает падать скорость открытия окон на следующем этапе. Единственный путь , который я нашел, это создание дополнительной таблицы, в которую вносятся окончательные вычисленные данные, а также Слова. Создаются запросы на добавление, изменение, удаления записей между двумя таблицами. Но так, как операции осуществляются в пределах этих данных и только при входе для изменения данных, торможение терпимо. Отдельно для некоторой категории данных можно внести переименование.

А теперь попытаюсь объяснить, почему сторонник интерфейса ввода малого количества информации в одном окне и с последующим переходом. Возьмем к примеру набор законченных данных на Изделие-Материал-Товар. Названия разные, но суть составляющих данных примерно одна. Итак примерные данные Товар: 1) Название, 2) Тип, 3) Вид, 4) Бренд, 5) Страна изготовления 6) Серия, 7) Номер, 8) Дата выпуска, 9) Материал изготовления, 10) Цвет. Если я внесу все данные в одну таблицу, то в последующем запросе, при таком количестве связей последует сообщение о большом количестве связанных таблиц в запросе. Примерно проверил в запросе не более 5 связанных таблиц. Наверное можно было бы обойти это, но я пошел по другому пути, разбил эти данные на группы, что привело к поэтапному заполнению данных. Критерием в данном случае послужило то, что разбивка нужна, но с наименьшим количеством. Во первых определил данные без которых записи не будет - это 1) Название. Для всех остальных данных Код может =1, т.е. не обязательно вносить значения. Дальше определил данные, которые будут основными к оставшимся: 2) Тип, 3) Вид. В итоге получил 1 таблицу для которой проводятся все действия на повтор, вычисления уникального кода. Вторая таблица а) Код первой таблицы, 4) Бренд, 5) Страна изготовитель. Третья таблица б) Код второй таблицы, 6) Серия, 7) Номер, 8) Дата выпуска. Четвертая таблица в) Код третьей таблицы, 9) Материал изготовления, 10) Цвет. Везде данные Товар будут представляться через уникальный код Четвертой таблицы. Но и тут все не в порядке. Например при изменении орфографической ошибки в Слове (например сений на синий) необходимо чтобы автоматически прошел процесс обновления во всех данных, где задействовано слово. На третьем этапе идет сборка данных под конкретный заказ. Ну вот и все к чему пока я пришел.

Индексированное поле поставило ограничение мне не только как пользователю, но и сборке программы. Правда где не вспомню. Но после пару случаев, я полностью от него отказался. При построении я всегда исходил, что пользователь может натворить все, что угодно. Все могут совершать орфографические ошибки при внесении данных. Грубо внесли название товара "Стокан", а в следующий раз внесли "Стакан". Оба значения уже увязаны с данными. Увидели ошибку начинаем исправлять "Стокан" на "Стакан" и получаем сообщение о невозможности внесения данных из-за повторяющихся значений. Приходится во всех задействованных данных заменять вручную данные, или создавать дополнительно запрос на обновление где начинаешь вручную вносить найди "Стокан" и замени на "Стакан". Я же говорю о том, что при одинаковых значениях идет автоматическое обновление и замена и от тебя не требуется дополнительно выполнить операцию, заменил букву и все. А теперь в таблице 3 значения. Ставим индексирование на Товар и не сможем внести а) 1) Стакан 2) Граненный; б) 1) Стакан 2) Пивной. Я подразумеваю разбивку внесения данных но не по одному значению. В таблицу вносятся группа данных где значения могут повторятся. В последующих таблицах вносятся группа данных, как бы расшифровкой, дополнением предыдущих таблиц данных. Ну и главное я считаю не требуется вносить данные везде. Например только Название товара (можно ставить на обязательное заполнение, а можно и не ставить. Достаточно условия если не заполнено Название товара удалить всю запись). А дальше созрел внесешь данные, не созрел ну и ладно.

Итак в таблице появилось два одинаковых орфографических названия группы после исправления ошибки но с разными кодами. Стакан - код 2 и Стакан - код 5. Если осуществляем связь по кодам, это два различных данных, а по сути одно и то же. Для того, чтобы вывести их как одно, необходимо будет осуществлять связь по словам. Тогда зачем код. Насчет осуществления связи. Я от нее практически отказался. Самое тяжелое психологически было отказаться от столбца подстановок в таблице. Связь между таблицами делаю в запросе в отношении данных задействованных в основной таблице. В формах, отчетах ставлю соответствующий источник данных.