Как получить всю БД в виде csv?

Question

[Untiwe]

Есть какая то БД с набором таблиц, например:
id instrument
1 gitar
2 piano

id name instrument_id
1 Вася 1
2 Петя 1
3 Сережа 2

Мне надо сделать из нее csv файл, здесь он будет примерно такой

Name instrument
Вася,gitar
Петя,gitar
Сережа,piano

А а теперь интересное:
-СУБД несколько и они разных видов (oracl, mongo, mysql и т.д.)
-Я не знаю их архитектуру и название таблиц заранее
-Если есть связь Many to Many, значит будет несколько строк в scv с разницей в одном столбце

Надо изобрести/найти/купить универсальный инструмент, который бы мог превращать БД csv файл.
Если писать самому то на C# (или хотя бы python)

Answer 1

[Василий Банников]

С джоинами будет сложновато, но со всем остальным:
1. Определяешь тип БД (раз уже подключился - значит известен)
2. В большинстве СУБД можно динамически получить список всех таблиц/коллекций (эту информацию можно получить из служебных таблиц, имя и структура которых известна заранее)
3. По данным из п2 делаешь N запросов SELECT * from {tableName} (как в монге это сделать - не подскажу)
И через DataReader читаешь таблицу и пишешь в csv.

А ещё для некоторых субд могут быть уже готовые инструменты для экспорта данных.
Например mysqldump, pg_dump, mongodump итд, которые как раз и делают вышеописанное.

На счёт джоинов - никогда подобное не видел, и в общем случае такое сделать не получится.

Answer 2

[rPman]

Формат csv для данной задачи наиболее неподходящий, теряется информация о структуре, особенно когда на очередной строчке количество колонок меняется и еще страшнее - если не меняется, что там лежит, что в какой колонке - не известно, машина не прочтет а человек обматерит изобретателя этого бреда.

Вторая проблема - денормализация, вот это объединение записей. Причина простая - реляционные базы данных по определению не хранят достаточно информации для понимания, чем является данные. В некоторых случаях можно что то вытащить из типа индексов (fk и pk) и ограничений constraints но в общем нет. Как понимать связь М-1-М? какую таблицу брать за базовую а какую второстепенной, т.е. что выбирать left join, right join или inner join? Да, для простых справочников, когда таблица является лепестком в графе связей 1-М можно 'смело' связывать такую таблицу, дублируя данные справочника по foreign key индексам, но опять - зачем? ведь при чтении уже не будет видно что использовался справочник.

p.s. Я могу предположить что конечная цель у автора - работа со случайными данными (много мелких проектов, написанных разными людьми с сильно оотличающимися подходами к разработке и способам хранения данных) и извлечение из них осмысленных, к примеру в заранее определенном формате
Когда то давно у меня в дипломной или рядом была проект, в котором в качестве доп инструмента была простая самописная утилита, ее натравливаешь на очередную базу с неизвестной структурой, она проводила простенький анализ структуры и выдавала в интерфейсе таблицы поля и показывала короткий брифинг по каждому выбранному полю (тип связи и пример данных там хранящихся), цель утилиты - указать таблицы и поля, из которых дальше будет извлекаться данные (т.е. дать интерпретацию этим данным). Без этой утилиты работа по определению какое поле чем является достаточно муторная, в имеющихся приложениях по работе с бд нужно много кликать, запускать хоть и заранее написанные запросы и т.п. Может вам лучше это состряпать? Я искал и не нашел, готовые универсальные решения слишком сложны (а смысл в простоте интерфейса).

в c# есть унифицированный инструмент по подключению к базам данных - ado.net (вся возня - в построителе connection string, плюс таскать с собой по больше драйверов от разных бд), плюс есть системный odbc (уже устарел но для старых баз данных это иногда единственный способ подключения) для которого есть поддержка ado.net

Comments

[Untiwe]

Спасибо большое за развернутый ответ. Да, у меня тоже есть мысль собирать структуру при помощи INFORMATION_SCHEMA и ado, искренне надеюсь, что к odbc мне прибегать не придется.
Надо будет еще раз обсудить с заказчиком объём работы и целесообразность такого задания.

Answer 3

[Akina]

Задача недоопределена.

Например, под термином CSV можно понимать как файл единой структуры (причём как plain-структуры, так и с сериализованными данными), так и несколько конкатенированных (как в процессе вывода, так и явно по окончании вывода) файлов, каждый из которых имеет свою структуру (да ещё и дополнительная информация там может храниться, вроде имён таблиц и имён/типов полей).

Каждый из вариантов предполагает свой код для решения задачи (это если не обращать внимания на такую мелочь, что сама по себе запись в CSV в каждой СУБД делается тоже ну очень по-своему).

А так - вот не вижу ну никакой проблемы. Лишь бы на той стороне обработки этого CSV был код, который правильно интерпретирует данные и корректно разложит их обратно по таблицам. Причём если идёт речь о создании универсального инструмента, то только в этом самом последнем моменте (вывод результата запроса в CSV) могут возникнуть хоть какие-то сложности. Остальное просто и плоско, как блин.

Я не знаю их архитектуру и название таблиц заранее

Хотя вот ещё одна точка, где могут возникнуть сложности. Теоретически все СУБД должны бы поддерживать INFORMATION_SCHEMA, всё же стандарт как бы описывает - и всё равно не всё там просто и очевидно.

Comments

[Untiwe]

Спасибо большое за развернутый ответ. К сожалению, для чего CSV будет использоваться в будущем мне не известно.
Благодаря INFORMATION_SCHEMA я уже могу посмотреть все таблицы в БД, но вот до выявления связей между ними пока не дошел

[Akina]

Untiwe,

Благодаря INFORMATION_SCHEMA я уже могу посмотреть все таблицы в БД, но вот до выявления связей между ними пока не дошел

INFORMATION_SCHEMA содержит всю необходимую информацию. Не поленитесь изучить, какие именно представления в ней определены, и что можно извлечь из них.

Например, тут: SQL-1992, страница 535 и далее.

Answer 4

[alekseyHunter]

Таблиц несколько и они разных видов (oracl, mongo, mysql и т.д.)

Что? Это не таблицы, а СУБД. У вас таблицы БД хранятся в разных СУБД?

Я не знаю их архитектуру и название таблиц заранее

Это уже напоминает взлом.

Если есть связь Many to Many, значит будет несколько строк в scv с разницей в одном столбце

Смотря сколько join'ов вы намерены сделать.

Надо изобрести/найти/купить универсальный инструмент

Как говорится - Welcome. Изобретайте.

Comments

[Untiwe]

Что? Это не таблицы, а СУБД. У вас таблицы БД хранятся в разных СУБД?

да, имеется ввиду СУБД, я не так выразился

Это уже напоминает взлом

в будущем, приложение будет интегрироваться с CRM разных размеров

Смотря сколько join'ов вы намерены сделать

столько сколько, надо для получения всех данных

Как говорится - Welcome. Изобретайте.

Если готовых решений нет, придется. Может подскажите как можно пройтись по таблицам БД не зная ее архитектуру?

[alekseyHunter]

Может подскажите как можно пройтись по таблицам БД не зная ее архитектуру?

Untiwe, попробуй этот запрос, получишь список всех таблиц в БД.

SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES t Where t.table_schema = "имя_бд"

А дальше Select * From table_name и разбираешь архитектуру.