Всем привет!
В этой статье я вам расскажу, как я переносил данные из MC Access в SQLite не используя дополнительных утилит или программ, только пакет MS Office и SQLite DB browser.
Немного предыстории
У меня была необходимость экспортировать базу данных из Access (а если точнее из формата .mdb) в SQLite. Совместимых форматов у этих СУБД нету (как оказалось) и мне пришлось придумывать как это можно сделать. И вот что я придумал:
Собственно гайд
Итак, у нас есть .mdb или .accdb (или любой другой формат, который поддерживает Access) и нам нужно получить что то вроде .db или .sqlite. Скажу сразу разнообразные онлайн-сервисы (даже если они есть) я рассматривать не хотел, так как о безопасности и скорости там речи не идёт, поэтому пришлось что то придумывать самому.
Сложность была так же в том, что моя подопытная БД была с Окном и это затрудняло возможность экспорта в некоторые форматы.
Перед тем как мы продолжим, я познакомлю вас с нашей подопытной БД:
Автор этой БД: Улыбышева Ирина Михайловна. Вы можете скачать оригинал здесь.
Моя же версия этой БД, переведённая на английский язык и экспортированная во множество форматов лежит на GitHub.
Ок, мы знакомы о подопытным, теперь можно приступать. Я скажу сразу, этот способ может показаться немного костыльным, но однако он работает. Если у вас есть другие предложения, по тому, как это можно сделать - пишите в комментарии к статье или в мне в телеграмм (ссылка будет в конце статьи).
Шаг 1. Открываем необходимую БД в Access, переходим во вкладку External Data (Внешние данные) нажимаем Export to Excel. После этого откроется диалоговое окно, в котором необходимо выбрать директорию в которую сохраним файл и формат, в котором сохраним.
Шаг 2. Открываем полученный файл в Excel (надеюсь не надо рассказывать как). И теперь мы можем произвести все необходимые манипуляции с таблицей, например перевести её другой язык и т.п. Когда закончили, нажимаем File > Export > Change File Type и выбираем CSV.
После этого жмём Save As, выбираем путь и сохраняем.
Шаг 3 - Финал. Открываем SQLite DB browser. Создаём новую БД, в меню File выбираем Import и выбираем подпункт Table from CVS. Выбираем интересующую нас таблицу, настраиваем и жмём ОК.
И теперь, можете делать с новой БД всё, что хотите. На этом гайд подошёл к концу. Если есть какие-то замечания - пишите.
От автора
Спасибо, что дочитали статью до конца, надуюсь она была вам полезна и сэкономила вам время. Если хотите повлиять на выход дальнейших статей, то можете подписаться на мой telegram-канал, там в том числе будут опросы касаемо выходов новых статей. Если хотите со мной связаться или предложить тему для статьи - мои контакты есть на сайте.
Ещё раз спасибо, что дочитали до сюда!
Удачи!
Комментарии (16)
Akina
10.09.2023 18:32+11Совместимых форматов у этих СУБД нету (как оказалось)
Обе СУБД прекрасно общаются с CSV - Access по щелчку пальцев экспортирует:
SQLite точно так же без проблем импортирует (эта часть, слава богу, описана).
Кстати, ничто не мешает прямо из Access подключиться к SQLite по ODBC (соответствующий пункт на скриншоте - имеется) и вообще перегнать данные напрямую, в принципе избегая промежуточного хранилища.
И теперь мы можем произвести все необходимые манипуляции с таблицей, например перевести её другой язык и т.п.
Эхх.. и передача данных - через третьи руки, и их редактирование - опять через третьи руки..
Больше всего похоже, что автор взялся за то, чем вообще никогда не занимался, но вместо серьёзного исследования и изучения сляпал абы как, лишь бы получилось.. а потом, вместо того, чтобы сдать работу и помалкивать о том, через какое место она делалась, ещё и выволок всё своё незнание на всеобщее обозрение. И даже гордится им..
Вы бы, друг мой, не позорились, а?
k-semenenkov
10.09.2023 18:32Я на всякий случай оставлю это здесь (сорри, я автор) -
https://ksdbmerge.tools/cross-dbms-diff-merge-overview.html
Открываем в одной панельке файл аксес, в другом - файл с SQLite базой
В бесплатной версии нужно будет пройтись по очереди по табличкам, для каждой нажать "выделить все записи" и "мерж". В платной можно это сделать сразу для всех таблиц.
Из минусов, по крайней мере по сравнению с подходом из статьи - таблички в SQLite базе должны быть созданы заранее, с таким же набором колонок и первичным ключом (есть планы на будущее по импорту схемы, но пока сильно далекие).
Еще наверно стоит отметить что в аксесе есть multivalue типы данных которые вряд ли могут быть нормально перелиты предложенными способами.Akina
10.09.2023 18:32в аксесе есть multivalue типы данных которые вряд ли могут быть нормально перелиты предложенными способами
Хорошо бы понять, о чём именно Вы ведёте речь... в любом случае всё нормально перельётся (правда, не в случае, когда приёмником выступает SQLite - уж больно бедненько там с типами), дав на выходе либо ENUM, либо SET. В последнем случае можно также воспользоваться JSON-массивом.
Можно также подумать об автоматическом создании таблицы-словаря и внешнего ключа в неё.
Ну и универсальный вариант - использование на приёмнике TEXT/BLOB поля,- может быть использован вообще практически в любом случае.
k-semenenkov
10.09.2023 18:32Я веду речь о https://support.microsoft.com/en-us/office/create-or-delete-a-multivalued-field-7c2fd644-3771-48e4-b6dc-6de9bebbec31. В значении поля такого типа будет лежать список, к мультивелью относятся в том числе и аттачмент поля.
>> Можно также подумать об автоматическом создании таблицы-словаря и внешнего ключа в неё.
Чтобы сохранить структуру, тут на каждое такое поле нужно создавать отдельную таблицу с отношением многие-к-одному на основной набор данных. В каких-то случаях и дополнительная таблица-словарь может быть полезна. В общем, потребует какого-то кастомного решения.Akina
10.09.2023 18:32Ааа... ну это типичнейший SET. Сами данные - это маска битовых флагов, а в метаданных таблицы хранятся текстовые описания этих флагов. Очень хорошо такой тип данных, включая и начинку под капотом, описан, например, в Reference Manual у MySQL.
Просто M$ не может же использовать стандартные именования, несолидно, им надо непременно что-то своё оригинальное выдумать... мир, правда, не прогибается, но надежда умирает последней.
Чтобы сохранить структуру, тут на каждое такое поле нужно создавать отдельную таблицу с отношением многие-к-одному на основной набор данных
Ну в принципе это куда как более правильное решение, чем использование SET. Костыль - он и есть костыль. Где-то упрощает, где-то усложняет. Но в простейших случаях как раз ему самое место.
k-semenenkov
10.09.2023 18:32Я знаком с SET в MySQL, на первый взгляд да, может быть похоже, но в общем случае - нет. Набор значений может задаваться внешней таблицей или запросом (аналог внешнего ключа). Даже если это фиксированный список как в SET - можно удалить значение из списка в "схеме" и при этом оставить уже выбранные значения в данных. В случае аттачментов это вообще произвольный список пар блоб плюс имя файла.
Не уверен что плод больной фантазии MS, это вполне могло быть содрано из какого-нибудь файлмейкера - еще один популярный на западе инструмент для создания баз данных вместе с интерфейсом, наподобие аксесса.Akina
10.09.2023 18:32Набор значений может задаваться внешней таблицей или запросом (аналог внешнего ключа).
В любом из этих случаев мы имеем скрытую статическую таблицу либо запрос, причём работает оно на уровне интерфейса, а не на уровне самой БД. А само поле остаётся текстовым (или что там выбрано) - если изменить список, то ранее введённые значения, даже в новой версии списка отсутствующие, никакого отторжения у БД не вызывают. И флаг "ограничиться только значениями из списка" для уже существующих данных не помогает, хотя злостно нарушает целостность. То есть подсистема контроля непротиворечивости данных просто спит.
edo1h
10.09.2023 18:32Сложность была так же в том, что моя подопытная БД была с Окном
что бы это значило?
Akina
10.09.2023 18:32Вероятно, речь идёт о том, что Аксессова БД содержала не только данные, но и интерфейс к ним - скажем, форму ввода и редактирования данных. Что, само собой, в SQLite ну никак не перетащить.
Demiourgos
10.09.2023 18:32+1Кажется я созрел для написания статей на Хабр.
Если уж такое тут можно, то мне есть чего припомнить!
Didntread
10.09.2023 18:32+1прямо вот так открывать и пересохранять экселем данные для миграции - такое себе, он может поменять их как ему вздумается, а что именно он поправил не напишет. Даже если вам сделали и прислали эксельку, нужно убедиться, что локаль в системе у вас и у создателя файла совпадает. Как указано выше, лучше использовать csv, и если и трогать их экселем, то импортировать через Data->Import Text File, аккуратно расставив типы данных в колонках.
maledog
10.09.2023 18:32Вспомнилось как во времена ковида англицкий минздрав потерял часть данных при экспорте через Excel. Не учел лимиты на количество столбцов. В вашем случае вы можете так же потерять строки сверх лимита Excel. А еще можно неслабо так споткнуться если при импорте из csv неправильно определится тип столбца, или данные не будут соответствовать полям таблицы. Так что, быстро? — да, надежно? — нет.
cartonworld
Проще, кажется, использовать, например, DBeaver и Import MS Access DB into MySQL DB
falmer
Тогда статья получится значительно короче или не получится вовсе.