Автор Тема: Слияние двух файлов при совпадении в строке  (Прочитано 22301 раз)

Оффлайн Александр Ерещенко

  • Завсегдатай
  • *
  • Сообщений: 1 153
Код: [Выделить]
SELECT table1.id, table1.name, table1.address, table2.nick, table2.group FROM table1 INNER JOIN table2 ON table1.id = table2.id ;
Судя по памяти и данной документации: линк
Используя INNER join мы можем потерять данные из первой таблицы.
Т.е. склеиваем две таблицы на основании первой. Если нет пересекающихся ID то данные из первой будут утеряны. А это плохо. Можно просто их пустыми оставлять и всё. Т.е. не заполнять данные в ячейке ( типа null или как то так).

Судя по всему надо использовать FULL Join. Что вы думаете?
Как я понял условие задачи, слияние нужно только для одинаковых ID в обеих таблицах. Т.е.  именно INNER JOIN -  ID, что присутствуют только в одной или только в другой (но не в обеих), в результирующую таблицу не попадут. Если использовать FULL, LEFT или RIGHT JOIN, то в результирующей таблице в ряде записей получатся пустые поля. Но тут уж что именно нужно получить автору.

Оффлайн stranger573

  • Мастер
  • ***
  • Сообщений: 1 434
    • Email
Мне надо это в один сводный файл обьединить.
Самый простой и правильный способ — выгрузить из исходной БД нужные поля в одну таблицу. И ничего объединять не придётся. У вас же там две связанные по id таблицы.

Нюанс: Размеры данных файлов очень большие. Примерно по 400-500Мб, по 2 млн.строк.
LibreOffice Calc и сводная таблица - подвисает и не может провернуть 2 файла.
LibreOffice Calc может обрабатывать 1048576 строк, 1024 столбцов. Для него надо делать выборку не более 1млн. строк. И он не подвисает. Я потрошу в нём БД по миллиону строк. Такой файл только открываться будет более получаса, обрабатываться может и два часа.

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

А для чего вам подобная процедура? Это такая выборка или вы хотите себе БД сделать?

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 549
Судя по всему надо использовать FULL Join. Что вы думаете?
full join - в результат попадут все записи из обоих соединяемых таблиц
left outer join - в результат попадут все записи из первой таблицы, и те записи из второй, для которых есть соответствие в первой.
inner join (или просто join) - в результат попадут те записи, которые есть в обоих таблицах

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
В общем, хорош атомными бомбами кидаться по воробьям.

#!/bin/bash4

declare -A lines
regex="([^;]+);(.*)"

for STR in `cat file1.csv file2.csv`; do
    if [[ $STR =~ $regex ]]; then
        echo ${BASH_REMATCH[1]} ${BASH_REMATCH[2]}
        key=${BASH_REMATCH[1]}
        value=${BASH_REMATCH[2]}
        lines[$key]=${lines[$key]}$value
    fi
done

echo

for KEY in ${!lines[@]}; do
    echo $KEY";"${lines[$key]}
done

Где дописать " >> file3.csv", думаю, понятно.

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 549
Если известно, что файлы отсортированы по id (или если их возможно предварительно отсортировать по id), то можно "сливать" в один проход, не использую БД и хэши, читая оба (или более) файла построчно и сразу формируя файл-результат (выкидывая "лишние" строки или формируя результат с "пустыми" полями в зависимости от потребностей) .

При выборе метода реализации - через БД, скрипт на bash, и т.д, я бы смотрел в первую очередь на навыки исполнителя - какое средство разработки более знакомо, то и использовать.

А как скрипт на bash поведет себя с большими файлами? Что-то меня смущают упоминаемые выше по теме GB-ты данных и миллионы записей...
Есть у меня интуитивное  подозрение, что на миллионах строк хэши будут не самым лучшим в вариантом реализации... Да и памяти они сожрут немерено.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
А как скрипт на bash поведет себя с большими файлами? Что-то меня смущают упоминаемые выше по теме GB-ты данных и миллионы записей...
Во времена 64-разрядных систем и гигабайт памяти? Ну в своп уедет.
Есть у меня интуитивное  подозрение, что на миллионах строк хэши будут не самым лучшим в вариантом реализации...
Разве что хэши в bash. А так вполне себе решение.

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 549
Разве что хэши в bash. А так вполне себе решение.
Спорить не буду, поскольку навскидку не скажу на каком объеме производительность здесь уйдет за рамки приемлемой... Поскольку будет сильно зависеть от реализации самого используемого хэша.

Оффлайн stranger573

  • Мастер
  • ***
  • Сообщений: 1 434
    • Email
то можно "сливать" в один проход
   Поскольку топикстартер выдавливает по крохе условий в неделю, приходится ванговать. Очень сильно сомневаюсь, что его конечной целью является смержить две таблицы в одну и радоваться что оно есть. Подозреваю, что потом он собирается запихнуть это в ехель и делать выборки/вычисления, причём не одноразово, а каждый раз с новыми данными. В этом случае ковырять текстовые файлы — это чесать левой пяткой правое ухо.
   Для чего вообще мержить два csv, если и к ехелю и к какой-нибудь базе данных можно подцепить два файла с двумя таблицами как источники внешних данных. Сведя все последующие операции к:
   - получить файлы с новыми данными;
   - положить их в определённое место;
   - открыть файл ехеля или БД и сразу начать делать выборки/вычисления в любом нужном виде

Причём первые две операции с большой долей вероятности можно вообще автоматизировать, и тогда останется только одна операция — открыть файл ехеля (подключиться к базе данных).
« Последнее редактирование: 14.02.2019 22:25:09 от stranger573 »

Оффлайн aliokero

  • Начинающий
  • *
  • Сообщений: 1
А для чего вам подобная процедура? Это такая выборка или вы хотите себе БД сделать?

Необходимо создать из Открытых Данных БД свою БД платёжеспособных Юридических Лиц. А это определяется параметрами: у кого сколько людей работает, какие системы налогообложения, сколько каких налогов отчисляют, какой доход, какой расход. Ну и собственно где находятся и как связаться. А то желания платить за открытые данные в Фокус Контур 30 т.р. нет никакого желания.


Оффлайн aliokero

  • Начинающий
  • *
  • Сообщений: 1
Поскольку топикстартер выдавливает по крохе условий в неделю, приходится ванговать.
Да, файлы большие. Но потом далее это использовать хочу вот как. По финансовым показателям и прочим буду делать выборку наиболее потенциальных клиентов и с ними контачить. Грубо говоря зачем обращаться в юр.лица у которых работает 1 человек и прибыли за год всего 10 т.р., а оборотка за год была всего 100 т.р. ? Будем искать у кого от 15 человек работает и годовой оборот хотя бы от 1 млн.р - значит у них есть компьютерный парк, возможно нужен сервер и всё это необходимо худо бедно обслуживать.

Для справки: всего на территории нашей области юридических лиц около 50 000, а под выше описанные критерии попадёт около 3 000.
А всё начинается с 2 000 000 записей, потому что налоговая больше никаких открытых данных не предоставляет.

Оффлайн stranger573

  • Мастер
  • ***
  • Сообщений: 1 434
    • Email
Ну так что мешает сделать свою БД с несколькими таблицами, как это нормально делается во избежание дублирования данных (что особенно критично с большими объёмами)? Where уже запретили? Запрос можно делать к нескольким таблицам, пример hsqldb с двумя таблицами во вложениях. Ну или сразу из исходной базы получить нужную таблицу.

Оффлайн stranger573

  • Мастер
  • ***
  • Сообщений: 1 434
    • Email
Необходимо создать из Открытых Данных БД свою БД
В каком виде эти "Открытые Данные БД" предоставляются исходно?

Оффлайн aliokero

  • Начинающий
  • *
  • Сообщений: 1
В каком виде эти "Открытые Данные БД" предоставляются исходно?
Те которые именно интересуют в .xml . Вот ссылка
Я их из xml в csv перегоняю сначало с помощью этого
Потом обрезаю лишнее с помощью cut и сортирую. И получаю более менее удобоваримый .csv

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Делаю я это всё под Windows используя штатный bat винды и в нём использую утилиты GnuWin32.
Так есть там bash версии 4?

Оффлайн stranger573

  • Мастер
  • ***
  • Сообщений: 1 434
    • Email
Я их из xml в csv перегоняю сначало с помощью этого
Хорошая софтина. Надо запомнить.

Те которые именно интересуют в .xml . Вот ссылка
Нет, ну я конечно ожидал там увидеть непотребный xml, но чтобы каждая таблица была настругана на десятки тысяч этих xml-файлов... Вот каких-то полезных умений за государством не замечал ни разу, но в одном ему точно не откажешь — в умении укомплектовать абсолютно каждый продукт своей жизнедеятельности фирменным геморроем.
Пока таблицы собираю.

Самому стало интересно: потянет ли, например, sqlite выборку одним запросом из таких таблиц, или надорвётся.