Loriowar Sep 8 2016 at 11:13

Как работать с MS Access в Linux

12 min

42K

Microsoft Access*PostgreSQL*Ruby*Ruby on Rails*Development for Linux*

Translation

+14

Comments 18

RPG18 Sep 8 2016 at 11:30

Вижу перегонять данные из MS Access в PostgreSQL средствами ETL было скучно неинтересно.

Loriowar Sep 8 2016 at 11:46

На сколько я себе это представляю, ETL, в данном случае, будет работать через тот же csv, потому что других вариантов вытащить и преобразовать нет. Ни о каком риалтайме тут речи не идёт. Или что вы имеете в виду под средствами ETL?

RPG18 Sep 8 2016 at 12:05

ETL популярная штука сдери энтерпрайза. Если брать готовое open source решение Pentaho Data Integration, Jaspersoft ETL то они написаны на Java, из-за чего поддерживают куча источников. Некоторые позволяют создавать Job и запускать из скриптов по крону.

Loriowar Sep 8 2016 at 12:26

С pentaho немного общался, когда думал как бы с MySQL на PostgreSQL переехать, он он мне уж слишком монструозным показался. Плюс, если верить быстрому гуглению, у него те же проблемы с доступом к MS Access, что у всех остальных: нужен либо системный ODBC со всеми вытекающими (тобишь с отсутствием нормального драйвера), либо использовать Java в виде MS Access JDBC Driver, и не известно как там себя Java поведёт.

В общем, мне был ближе Postgres. Потому что новых сущностей/сервисов плодить не надо, потому что можно поднапрячься и поулчить реалтайм, можно полностью скрыть реализацию от веб-приложения и оно даже не узнает откуда данные берутся. Хотя, поразбираться с ETL было бы полезно. Спасибо за наводку.

RPG18 Sep 8 2016 at 12:42

А тут не очень понятно как Access поведет при множественном доступе. Да и запросы будут побыстрее, если PostgreSQL не будет ходить в Access. Так же можем навешивать дополнительные индексы исходя из запросов.

Loriowar Sep 8 2016 at 13:24

Это неплохо решается через materialied views, которые строятся на основании данных из FDW. На них и индексы можно навесить и всё что угодно. Конечно получаем лаг в обновлении данных, но он очень небольшой.

Rifal Sep 8 2016 at 11:46

Объясните мне, зачем это может понадобиться?

Loriowar Sep 8 2016 at 11:54

Тут недавно была статья про легаси, из которой можно заключить, что мир сотоит не только из чистых стартатов, но и из долгоживущих компаний, которые, подчас, работают вдали от переднего края современных технологий. Так вот, у некоторых до сих пор аксес и прочий зоопарк в продакшене и с этим нужно как-то жить и что-то делать. Так что зачем это нужно? Чтобы удовлетворять побребности бизнеса, поддерживать его жизнеспособность, продолжать производить товары и/или оказывать услуги и получать за это деньги.

Rifal Sep 8 2016 at 12:16

Да это понятно, не надо автоматом видеть в собеседниках полных идиотов. У меня у самого есть несколько самописных баз на Аксесе, работа с которыми ведётся через Sharepoint прямо с web. Просто в наш век проще построить прокладку через web или действительно перегнать данные в удобочитаемый формат для Linux (как в комментарии выше). Я имел ввиду мне не приходят на ум конкретные задачи, которые можно решить таким способом. Хотя по закону Энтропии и бесконечной вселенной они наверняка должны быть… :)

Loriowar Sep 8 2016 at 12:34

Ну одна из задач: есть база (а точнее несколько баз аксеса), суммарным весом под гигабайт, если не больше, и там в абсолютно денормализованном виде лежат данные. Эти данные в течение дня изменяются сотрудниками. Нужно в рандомные моменты времени сделать выборку по текущим данным, перенести их в соседнюю систему и там, на их основе, создать некое подобие документа, с которым человек продолжит работать, дополнять его, изменять и тд. Это если абстрактно без конкретики о предметной области.

ildarz Sep 8 2016 at 18:54

Если надо на регулярной основе получать доступ к рабочей базе Access, я бы пошел по пути цепляния к хосту с базой через powershell и работы с ней напрямую в нативной среде. Это гарантирует отсутствие проблем, связанных с кривыми драйверами, старыми неподдерживаемыми пакетами, и т.п. Всё, чем надо озаботиться — найти рабочую реализацию WinRM под Linux, вроде они в природе есть. Ну и плюс недавно MS выкатила powershell в открытый доступ, может теперь всё вообще просто?

Loriowar Sep 8 2016 at 19:14

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

ploop Sep 8 2016 at 12:16

Ещё как может. Мне приходилось перегонять данные из Clarion в PostgreSQL, а эта СУБД померла ещё до 2000х, хотя для бизнеса работала до 2007го, при том задачи выполняла.

Rifal Sep 8 2016 at 12:19

Понятно, некромантию никто не отменял ))

ploop Sep 8 2016 at 12:28

Ну да, есть задача, а ты решай как хочешь :)
Собственно, если забить на свой перфекционизм (или вообще засунуть его куда подальше), получается, что за это деньги и платят.

utor Sep 8 2016 at 21:22

Access'97, да с таблицами на кирилице, «как я Вас понимаю»(с)

ploop Sep 8 2016 at 22:28

Да жесть была. 5 Гб текстовиков (благо кларион их умел выгружать) Лазарус — в то время был копией Delphi-7, 70 таблиц и неделя времени :) Ну ничего, распарсил, перегнал, заработало всё.

На Access приложение было уже продвинутое, связь с MS-SQL-сервером была, т.е. на нём бизнес-логика работала. Там проблем нет.

RPG18 Sep 8 2016 at 12:24

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