Я переделываю приложение для ASP.NET CMS, которое мне действительно не нравится. Я сделал несколько улучшений в производительности только для того, чтобы обнаружить, что не только эта CMS использует MS SQL, но и некоторые пользователи «просто» используют базу данных MS Access.
Проблема в том, что у меня есть несколько таблиц, которые я соединяю внутри, которые с версией MS Access находятся в двух разных файлах. Мне не разрешено просто перемещать таблицы в другой файл mdb.
Я сейчас пытаюсь найти хороший способ «внутреннего соединения» для файлов БД с множественным доступом?
Было бы очень жаль, если бы я получил все данные и сделал это программно!
Спасибо





Если у вас есть доступ к MDB и вы можете их изменять, вы можете рассмотреть возможность использования связанных таблиц. Access предоставляет возможность связываться с внешними данными (в других MDB, в файлах Excel, даже в SQL Server или Oracle), а затем вы можете выполнять соединения по ссылкам.
Я настоятельно рекомендую протестировать производительность такого варианта. Если возможно перенести пользователей баз данных Access в другую систему (даже SQL Express), это также было бы предпочтительнее - последнее, что я проверил, больше нет 64-битных драйверов JET для ODBC, поэтому, если приложение когда-либо размещается в в 64-битной среде эти пользователи будут закрыты.
Да, вплоть до версий Windows 3.1 в Access разрешены произвольные отношения между связанными таблицами. Однако он часто извлекает всю таблицу на лету, что может быть проблемой для больших таблиц.
Внутри одной БД доступа вы можете создавать «связанные таблицы», указывающие на другую БД. Вы должны (я думаю) иметь возможность запрашивать таблицы, как если бы они обе существовали в одной БД.
Это означает, что вам нужно изменить одну из БД для создания виртуальной таблицы, но, по крайней мере, вы на самом деле не перемещаете данные, а просто указываете на них
В Access вы можете добавлять удаленные таблицы с помощью «Менеджера связанных таблиц». Вы можете добавить ссылки на один или другой файл Access или создать новый файл Access, который ссылается на таблицы в обоих файлах. После этого запросы внутреннего соединения ничем не отличаются от их выполнения в одной базе данных.
Вам вообще не нужны связанные таблицы. Есть два подхода к использованию данных из разных MDB, которые можно использовать без связанной таблицы. Первый - использовать IN 'c: \ MyDBs \ Access.mdb' в предложении FROM вашего SQL. Один из ваших сохраненных запросов будет выглядеть так:
SELECT MyTable.*
FROM MyTable IN 'c:\MyDBs\Access.mdb'
а другой сохраненный запрос будет:
SELECT OtherTable.*
FROM OtherTable IN 'c:\MyDBs\Other.mdb'
Затем вы можете сохранить эти запросы, а затем использовать сохраненные запросы для объединения двух таблиц.
В качестве альтернативы вы можете управлять всем этим в одном операторе SQL, указав путь к исходному MDB для каждой таблицы в предложении FROM, таким образом:
SELECT MyTable.ID, OtherTable.OtherField
FROM [c:\MyDBs\Access.mdb].MyTable
INNER JOIN [c:\MyDBs\Other.mdb].OtherTable ON MyTable.ID = OtherTable.ID
Однако имейте в виду одну вещь:
Оптимизатор запросов Jet не обязательно сможет использовать индексы из этих таблиц для соединения (другой вопрос, будет ли он использовать их для критериев в отдельных полях), поэтому это может быть очень медленным (в моих тестах это не так, но я не использую большие наборы данных для тестирования). Но эта проблема с производительностью относится и к связанным таблицам.
Вау. Как часто вы говорите, что узнали что-то новое о Access сегодня? Я не использовал Access много лет, но мне больно осознавать, сколько времени мне бы сэкономили эти простые знания.
Жалко, что ядро базы данных Jet приобрело такую запятнанную репутацию, поскольку это действительно замечательный движок. Его способность подключаться к такому количеству различных типов данных (одновременно) и принимать разумные решения по оптимизации извлечения данных не имеет себе равных ни на одной другой платформе.
Вы уверены, что отношения могут быть реализованы с таблицами из разных баз данных? Я не уверен, что инструкция INNER JOIN будет успешной в такой ситуации (на самом деле я уверен, что вы получите ошибку!)