Это похоже на разумную практику, за возможным исключением № 3.Весь смысл разделения БД Access на front-end / back-end состоит в том, чтобы позволить вам снять front-end где-нибудь еще и поработать над ним, а затем заменить версию, к которой обращаются пользователи, без замены их данных.Все, что вы делаете, что не мешает этой «первичной директиве», должно быть прекрасно.Конечно, если вы хотите изменить внутреннюю схему, различие между внутренним и внешним интерфейсом вам не поможет, но это то, что вы получаете, когда имеете дело с Access, верно?
Возможная проблема с # 3 состоит в том, что вы фактически объединяете любые изменения, которые вам могут потребоваться, чтобы выполнить внутренние запросы с изменениями схемы.Другими словами, если вам нужно каким-либо образом изменить эти запросы, вам нужно перевести внутреннюю базу данных в автономный режим, как если бы вы меняли схему.Если вы уверены, что все в порядке, тогда это не проблема, но вы должны знать, что вы ограничиваете себя таким образом.Насколько это действительно ограничено, зависит от того, что входит в эти внутренние запросы.Если это то, что вам никогда не нужно менять, если базовая схема также не меняется, тогда все будет в порядке.Но если это то, что может потребоваться изменить, потому что пользователь изменил свое мнение о том, как он хочет, чтобы эти данные были представлены, тогда у вас будет немного больше проблем.