Привет!
Интерфейс интересная штука...
В Access можно накарябать прогу так что пользователь и не узнает что запустил MS Access, а благодаря ActiveX прогу можно сделать с любым интерфейсом.
Основываясь на личном опыте для редактирования и ввода новых данных в таблицы всем советую использовать временные таблички, это несколько сложнее но намного надежнее. Если конечно не только Вы планируете работать с этой программой.

Можно и формы использовать. Даже нужно (зачем плодить лишние таблицы?), но это решение подходит только когда нужно добавить запись лишь в одну таблицу. Если же при вводе новой записи заполняются подчиненные таблички то тут уже не обойтись без "временных таблиц".

Да какой же перебор )
Тривиальный пример: есть таблица Сотрудники, есть таблица связанная с ней по ключу (например [Опыт работы] где и по какое время работал этот сотрудник). Теперь допустим нужно добавить нового Сотрудника и завести для него его Опыт работы. Что бы ты не говорил, а для данных [Опыт работы] необходима временная таблица. Можно конечно в два приема, т.е пользователь вначале добавит Сотрудника (ему присвоится ID), а затем будет уже вводить данные о его Опыте работы. Но это не красивое решение.
Таблицы для хранения временных данных хороши тем что даже если вырубится свет или еще какой сбой, то гарантировано что данные в основных таблицах будут всегда корректными. Потому как пишутся они туда только по кнопке "Ввод", да еще и транцакцию включить можно.

P.S. Схема данных тут вообще не относится к делу так-же как и многозвенные системы - это просто вопрос надежности программы.

2 SysOp
Ну что же будем отстаивать )
Замечание: говоря о надежности программы я имел ввиду запись данных во временные таблицы, а не многозвенные системы. Вы просто меня неправильно поняли. Про продумманность схемы данных, тут и обсуждать нечего - это есть постулат при проектировании любой БД. Причем тут 1С я так и не понял.
Пример с БД о сотрудниках может и не самый лучший. Вот другой пример:
есть табл. Order (Заказы) с полями:
ID - идент. заказа
EntDate - Дата ввода заказа
TotalSum - стоимость всеко заказа
PaySum - сумма оплаты заказа

есть таблица OrderDetails (позиции заказа) c полями:
ID - идент. записи
OrderID - идент. заказа
PositionName - название услуги
Amount - количество
Price - цена

С БД работают несколько человек (5-8 чел). По Вашей схеме при падении клиета во время ввода ЗАКАЗА, он все равно будет хоть частично да введен, что не верно потому как эта информация может быть актулальна только целиком (т.е. заказ со всем его содержимым). Что если другой отдел (допустим отдел поставки) основываясь на введенных данных делает какие-то действия (поставку)? В Вашем случае Заказчик получит только часть своего заказа. В моём гарантировано что все введенные заказы правильные. Не говоря уже о проблемах типа блокировки записей и одновременного доступа несколькими клиентами к одному заказу.
Кстати не факт что после того как включат свет (это может быть и через сутки) сотрудник вводивший Заказ, вспомнит что он оказывается не все ввел перед сбоем.
Вот теперь попробуйте опишите как Вы бы сделали это.

Вы наверное скажете "а такие ситемы не подходят для архитектуры файл-сервер", ан нет, я потроил несколько таких систем и они успешно работают на протяжении нескольктих лет.

P.S.
И поверьте у меня не менее скромные достоинства )

2mahoune
2SysOp

Да с галочками это в некоторой степени выход. Но все равно надежнее и проще писать во временную таблицу и переность из неё с включенной транзакцией когда настало время.
Что проще сделать?: один раз перенести из врем. таблицы и знать что что все ОК, нежели делить потом введенную информацию на ошибочную и неошибочную? Тем паче пользователь вначале может поставить галочку что все "ок" а затем занятся редактированием заказа и тут хлоп сбой.

Еще плюс временных таблиц в том что без проблем делаешь кнопку "отмена" , просто не переносишь в БД и все. Кстати я не уверен, что будет работать откат транзакции если данные из формы напрямую вносятся в таблицы. Надо будет попробывать. Вообще включенные транзакции хавают много ресурсов, (созд. врем. файл на диске) и на долго их лучше не включать.

Запоминать же идентефикационные сведенья пользователей в системах где высок уровень ответсвенности за введенную инфу ето необходимо.

Работать с врем. табл. я сам долго не хотел, но воспользовавшись этим решением освободился от многих гемороев.

2SysOp
А хранить сумму заказа в моем случае необходимо было по многим причинам (многовалютность системы и прочее). Одна из них скорость выборки, если бы я каждый раз считал её по всем позициям, все бы работало в несколько раз медленнее. Реляционность реляционностью, но это недолжно быть панацеей. Так что мой ответ потому что так проще и быстрее )
Про забывчивость сотрудников: он конечно может забыть, но только в моем случае этих данных не будет в общей системе и это будет проблема сотрудника.

2SysOp
Ну почему же нельзя? Если это будет требоватся по условию задачи то сделать это не составит труда. А вот в вашем случае никогда не разберешь кто закончил ввод, а кто нет, и сформирован ли заказ.

Не удачное замечание, применительно к БД Заказы. Однако если и возникнет такая ситуация то лучше записывать информацию верными пакетами от каждого сотрудника обрабатывающего заказ.

SysOp
Я всегда аргументирую свое мнение потому как понимаю что хочу сказать, правда может пишу не совсем доходчиво. Под понятием "верного пакета" я подразумевел набор позиций, ввод которых был поручен отдельному сотруднику (Вы кстати все поняли правильно). Что касается парирования, мне даже смешно стало. Жаль что немогу обратится по имени.
Какая готовая задача? Мы взяли абстрактную задачу и рассматривали варианты её решения.
Я думаю мы исчерпали все вопросы и я привел достаточно аргументов так что нет смысла продолжать дальнейшую дискусию на эту тему.

С уважением Сергей ;)
P.S.
Чего то злобность какая то читается в Вашем последнем ответе. Не связано ли это с Вашим авторитетом на этом сайте?