Pull to refresh

Comments 18

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

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

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

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


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

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

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

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

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

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

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

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

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

Ещё как может. Мне приходилось перегонять данные из Clarion в PostgreSQL, а эта СУБД померла ещё до 2000х, хотя для бизнеса работала до 2007го, при том задачи выполняла.
Понятно, некромантию никто не отменял ))
Ну да, есть задача, а ты решай как хочешь :)
Собственно, если забить на свой перфекционизм (или вообще засунуть его куда подальше), получается, что за это деньги и платят.
Access'97, да с таблицами на кирилице, «как я Вас понимаю»(с)
Да жесть была. 5 Гб текстовиков (благо кларион их умел выгружать) Лазарус — в то время был копией Delphi-7, 70 таблиц и неделя времени :) Ну ничего, распарсил, перегнал, заработало всё.

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

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

Sign up to leave a comment.

Articles