Дублирование записи в БД

@KaaPython · Регистрация: 22.03.2017

Студворк — интернет-сервис помощи студентам

Коллеги, доброго дня!
есть скрипт, который выдирает исторические данные котировок и предварительно сохраняет в файл data.txt:

Python
1
2
3
4
5
6
7
8
    while True:
        url = 'http://export.finam.ru/data.txt?market=520&em=484429&code=data&apply=0' \
              '&df=2&mf=3&yf=2018&p=5&f=data' \
              '&e=.txt&cn=data&dtf=2&tmf=2&MSOR=1&mstimever=0&sep=3&sep2=1&datf=5&at=0'
        f = urllib.request.urlopen(url)
        data = f.read()
        with open('data.txt', 'w') as file:
            file.write(str(data, encoding = 'utf-8'))

затем второй скрипт, обрабатывает полученные данные и записывает в БД:

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
def extract_date():
    with open('data.txt', 'r') as file:
        s = (file.read().split())
        for i in range(len(s)):
            ex = (s[i]).split(';')
            d = {
                'DATE': ex[0],
                'TIME': ex[1],
                'OPEN': ex[2],
                'HIGH': ex[3],
                'LOW': ex[4],
                'CLOSE': ex[5],
                'VOL': ex[6]
            }
            text = [(d['DATE'], d['TIME'], d['OPEN'], d['HIGH'], d['LOW'], d['VOL'])]
            cursor.executemany("INSERT INTO BTC_USD VALUES(?,?,?,?,?,?)", text)
            conn.commit()

второй скрипт после каждого запуска, дублирует все записи файла data.txt в БД, но это и логично, так как в файл data.txt, записываются данные за период.
задача, чтобы данные котировок из ресурса записывались в БД за определенный timeframe и не дублировались.
помогите, как это забороть?
может я что-то по-намудрил в скриптах.
принимаю любые улучшения и доработки

Рыжий Лис · 04.04.2018, 13:09

Может сделать пару полей в таблице (DATE, TIME) уникальными? Тогда СУБД не даст добавить дубль и всё будет хорошо.

Добавлено через 3 минуты
Как-то так:

SQL
1
CREATE UNIQUE INDEX unique_name ON BTC_USD(DATE, TIME);

Не по теме:

удивлён, что sqlite3 умеет делать составной индекс

@KaaPython · 05.04.2018, 04:57 **[ТС]**

Сообщение от Рыжий Лис

Может сделать пару полей в таблице (DATE, TIME) уникальными

Ок, спасибо за мысль. Буду пробовать

Добавлено через 41 минуту

Сообщение от Рыжий Лис

Может сделать пару полей в таблице (DATE, TIME) уникальными?

Не проходит такой маневр

Дата у всего дня одна и та же
тоже самое и со временем

@blz · 05.04.2018, 06:36

чтобы исключить дублирование данных, мы сначала должны иметь определение дублирующихся данных. у Вас есть DATE, TIME, OPEN, HIGH, LOW, VOL. вероятно, если хоть одно поле отличается, то данные не дублируются?

тогда видится 2 варианта – либо уникальный индекс по всем значимым (в контексте дублирования) полям (что, конечно, не есть гуд), либо мы сами вычисляем хэш записи (по значимым полям) и пишем его в поле БД с уникальным индексом.

Добавлено через 3 минуты
и еще один момент – похоже, все поля у Вас строки? думаю стоит их перед тем, как совать в таблицу, преобразовать в соответствующие типы данных. так будет и правильнее и попутно исключатся дальнейшие проблемы с тем, что '12.12.2012' != ' 12.12.2012'

@KaaPython · 05.04.2018, 10:30 **[ТС]**

Сообщение от blz

у Вас есть DATE, TIME, OPEN, HIGH, LOW, VOL. вероятно, если хоть одно поле отличается, то данные не дублируются?

информация в data.txt вот такого содержания:
180405;0015;6791.6800000;6798.5300000;67 66.0000000;6781.9900000;121
180405;0030;6782.0000000;6810.0000000;67 81.9900000;6810.0000000;113
180405;0045;6810.0000000;6815.0000000;67 50.0000000;6754.0100000;195
т.е. первое, это формат даты, далее время и так далее.
если сделать уникальным дату, тогда следующий таймфрейм не запишется, так как дата повторяется.
если сделать уникальным время, тогда весь день запишется в базу без проблем и без дублей,
но по наступлению даты 180406 выдаст ошибку, так как 0015 уже есть в базе.
поля в БД имеют следующий тип данных: DATE-text, TIME-text, OPEN-real, HIGH-real, LOW-real, VOL-real
проблем с преобразованием в дальнейшем не будет, помогут datetime и time.
вот с вычислением хеша мысль хорошая. можно подумать.

Добавлено через 7 минут

Сообщение от blz

либо мы сами вычисляем хэш записи (по значимым полям) и пишем его в поле БД с уникальным индексом.

а с хешированием подскажите с чего начать?
я так понимаю, хеш нужно вычислять до записи в БД?
не делал такого еще...

Добавлено через 2 часа 32 минуты

Сообщение от blz

вычисляем хэш записи

Все разобрался!
Спасибо за мысль!
С хешами заработало!

@blz · 05.04.2018, 11:10

Сообщение от KaaPython

с хешированием подскажите с чего начать?

сначала преобразовать данные в «правильные» типы, потом hash(list[field1, field2 … ]) или же, правильнее, hash(tuple([list]))

Добавлено через 5 минут
или даже примерно так:

Code
1
2
3
record = …
unique_fld_set = ['fld1', 'fld2',  …]
hash(tuple([ record[f] for f in unique_fld_set ]))

@KaaPython · 05.04.2018, 11:38 **[ТС]**

Сообщение от blz

вычисляем хэш записи

в общем с хешами тоже беда.
с историческими данными все ровно, записываются и не дублируются без проблем,
но когда подходит время реального времени, скрипт работает в online
за время работы скрипта за определенный timeframe (15 минут), изменяются значения HIGH, LOW, VOL.
вот и новый хеш

и пошли новые записи с одним и тем же DATA и TIME только с разными либо HIGH/LOW/VOL.

@blz · 05.04.2018, 11:58

Сообщение от KaaPython

в общем с хешами тоже беда.

ну мы вернулись к тому, с чего я начал –

Сообщение от blz

мы сначала должны иметь определение дублирующихся данных

мы не знаем, что за данные, какой они имеют смысл итд. я, допустим, не рискну дать определение дубликата. это нужно сделать Вам.

@KaaPython · 05.04.2018, 12:27 **[ТС]**

Единственное решение, которое мне видится в данном случае, это поиграться со временем запуска функции записи в БД, по заданному timefram`у

Добавлено через 9 минут

Сообщение от blz

мы сначала должны иметь определение дублирующихся данных

вот записи из БД:
"127" "88bb76f0862bfabd3e3920ce17d9214aaf48ee1 e" "180405" "0745" "6792.21" "6819.0" "6787.98" "16.0"
"128" "e3aedeeee92fd0b003e6a2935091c167bbe8766 7" "180405" "0800" "6798.0" "6810.0" "6798.0" "18.0"
"129" "f92f8be36644baf6e2f78c9452b722c9c8222a1 a" "180405" "0800" "6798.0" "6810.0" "6798.0" "18.0"
"130" "a367464ddaa2f2ceb974a9f2647fd6a73ae9563 c" "180405" "0800" "6798.0" "6816.08" "6798.0" "19.0"
"131" "4edff9ba7d68fad82ea8c5f4323d340385dc689 f" "180405" "0800" "6798.0" "6816.08" "6798.0" "23.0"
"132" "0621c5e1f7c919bfbf5f409d2cc3e179d797d5c e" "180405" "0800" "6798.0" "6816.08" "6786.01" "30.0"
"133" "0ba4e23f0ca96d7c1ba68797a6ec52064a16049 4" "180405" "0800" "6798.0" "6816.08" "6786.01" "30.0"
"134" "7dae605e699da7859c93adbfbe77a0042cabc81 3" "180405" "0800" "6798.0" "6816.08" "6775.45" "38.0"
"135" "4aa205f553ebc8036750cc05b2b52e8c1657334 2" "180405" "0815" "6786.0" "6802.99" "6786.0" "1.0"
"136" "b88abae3278466269e8f4a366b6a86b6de8fba5 b" "180405" "0815" "6786.0" "6802.99" "6786.0" "2.0"
"137" "e9d3e8ee968989ee14b85c9f1fd5ef89e1b09e3 1" "180405" "0815" "6786.0" "6802.99" "6786.0" "2.0"
"138" "5cc5004514a89e644d8e45ea43f3ff95f66efba 3" "180405" "0815" "6786.0" "6802.99" "6786.0" "2.0"
записи 128-134 это дубли, так как поле TIME (0800) за один timeframe.
далее записи 135-138 тоже дубли за следующий timeframe.
если их оставить в БД, анализ цен будет не верным.

@blz · 05.04.2018, 12:38

логику я так и не понял – почему с другим временем считается дублем, но пофиг.
так вот – почему бы не делать хэш только по значимым (в контексте дублирования) полям? например, если время у нас вообще ничего не значит, его исключить из хэша. выше я приводил скелет кода.

@KaaPython · 06.04.2018, 09:06 **[ТС]**

Сообщение от blz

логику я так и не понял – почему с другим временем считается дублем,

строка 127 это не дубль, а вот строки 128-134 это дубли, так как у них одно и то же время - 0800.
должна быть одна строка с одним временем.
так же и со стр. 135-138 - на всех время 0815
должно быть вот так:
"1" "ab863906399a9613487c1ff5b170a7bd3f0d2dd 2" "180404" "0015" "7424.91" "7424.91" "7390.0" "118.0"
"2" "72b503e6ee24ff028a278ae408c9fd004a7bc2d 2" "180404" "0030" "7405.91" "7418.17" "7395.0" "80.0"
"3" "58407fe0214fab40830182e1731105ea4c95634 b" "180404" "0045" "7395.0" "7420.0" "7392.56" "63.0"
"4" "efcdf196c5d32ab5c759c7aaab76d4f1710b634 d" "180404" "0100" "7419.99" "7419.99" "7399.99" "81.0"
"5" "19ac725930de7037f715d5a2e68df65161931ae 7" "180404" "0115" "7407.79" "7415.0" "7400.01" "68.0"
"6" "613edb586383cab220d78b24436c4481f2006aa c" "180404" "0130" "7400.02" "7406.0" "7302.01" "347.0"
и так далее.
время важно, так как от него будет считаться необходимый timeframe.
так как скрипт отрабатывает online, будут такие записи, где и данные по HIGH, LOW, CLOSE будут разные и они тоже запишутся в БД, так как хеш у них будет разный.

@blz · 06.04.2018, 11:58

если я вас правильно понял – делайте хэш только по дате и времени

@KaaPython · 06.04.2018, 12:42 **[ТС]**

Сообщение от blz

делайте хэш только по дате и времени

надо попробовать.
спасибо за мысль!

@blz · 06.04.2018, 12:55

Сообщение от KaaPython

надо попробовать.

«хэш» в данном случае достаточно вычислять так: date*10000+time. тогда по этому полю можно и сортировать эффективно

vic5710 · 06.04.2018, 16:46

я

Сообщение от KaaPython

информация в data.txt вот такого содержания:
180405;0015;6791.6800000;6798.5300000;67 66.0000000;6781.9900000;121
180405;0030;6782.0000000;6810.0000000;67 81.9900000;6810.0000000;113
180405;0045;6810.0000000;6815.0000000;67 50.0000000;6754.0100000;195

измени структуру БД - создай поле datetime типа 1804050015 и оно будет уникальным
по нему можешь удалить дубли
Сравнить несколько csv файлов и удалить в них дубли

@KaaPython · 10.04.2018, 05:54 **[ТС]**

Всем спасибо огромное за оказанную помощь!
все получилось.
изменил хеш.
задействовал только date + time и дубли ушли.

Новые блоги и статьи Все статьи Все блоги /
Программный контроль заполнения реквизита табличной части документа Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать контроль заполнения реквизита "ПричинаСписания". . .	wmic не является внутренней или внешней командой Maks 02.04.2026 Решение: DISM / Online / Add-Capability / CapabilityName:WMIC~~~~ Отсюда: https:/ / winitpro. ru/ index. php/ 2025/ 02/ 14/ komanda-wmic-ne-naydena/	Программная установка даты и запрет ее изменения Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: при создании документов установить период списания автоматически. . .	Вывод данных в справочнике через динамический список Maks 01.04.2026 Реализация из решения ниже выполнена на примере нетипового справочника "Спецтехника" разработанного в конфигурации КА2. Задача: вывести данные из ТЧ нетипового документа. . .
Программное заполнения текстового поля в реквизите формы документа Maks 01.04.2026 Алгоритм из решения ниже реализован на нетиповом документе "ВыдачаОборудованияНаСпецтехнику" разработанного в конфигурации КА2, в дополнении к предыдущему решению. На форме документа создается. . .	К слову об оптимизации kumehtar 01.04.2026 Вспоминаю начало 2000-х, университет, когда я писал на Delphi. Тогда среди программистов на форумах активно обсуждали аккуратную работу с памятью: нужно было следить за переменными, вовремя. . .	Идея фильтра интернета (сервер = слой+фильтр). Hrethgir 31.03.2026 Суть идеи заключается в том, чтобы запустить свой сервер, о чём я если честно мечтал давно и давно приобрёл книгу как это сделать. Но не было причин его запускать. Очумелые учёные напечатали на. . .	Модель здравосоХранения 6. ESG-повестка и устойчивое развитие; углублённый анализ кадрового бренда anaschu 31.03.2026 В прикрепленном документе раздумья о том, как можно поменять модель в будущем

@blz 151 / 102 / 33 Регистрация: 11.08.2016 Сообщений: 574
	05.04.2018, 06:36
	Сообщение было отмечено KaaPython как решение Решение чтобы исключить дублирование данных, мы сначала должны иметь определение дублирующихся данных. у Вас есть DATE, TIME, OPEN, HIGH, LOW, VOL. вероятно, если хоть одно поле отличается, то данные не дублируются? тогда видится 2 варианта – либо уникальный индекс по всем значимым (в контексте дублирования) полям (что, конечно, не есть гуд), либо мы сами вычисляем хэш записи (по значимым полям) и пишем его в поле БД с уникальным индексом. Добавлено через 3 минуты и еще один момент – похоже, все поля у Вас строки? думаю стоит их перед тем, как совать в таблицу, преобразовать в соответствующие типы данных. так будет и правильнее и попутно исключатся дальнейшие проблемы с тем, что '12.12.2012' != ' 12.12.2012' 1

@blz 151 / 102 / 33 Регистрация: 11.08.2016 Сообщений: 574
	05.04.2018, 12:38
	логику я так и не понял – почему с другим временем считается дублем, но пофиг. так вот – почему бы не делать хэш только по значимым (в контексте дублирования) полям? например, если время у нас вообще ничего не значит, его исключить из хэша. выше я приводил скелет кода. 0

@blz 151 / 102 / 33 Регистрация: 11.08.2016 Сообщений: 574
	06.04.2018, 11:58
	если я вас правильно понял – делайте хэш только по дате и времени 1

@KaaPython 6 / 6 / 1 Регистрация: 22.03.2017 Сообщений: 100
	10.04.2018, 05:54 [ТС]
	Всем спасибо огромное за оказанную помощь! все получилось. изменил хеш. задействовал только date + time и дубли ушли. 0

Дублирование записи в БД

Решение