Вот не могу сообразить, как лучше сделать

← →
vasIZmax © (2007-10-16 19:49) [0]

В общем ситуация такая.
Исходные данные:
БД с полями
ID_file (номер файла): инкремент
CRC32 (контрольная сумма файла): вариант
Expan_file (расширение файла): стринг
Status (значение 0 - удален, 1-сохранен, 2-на тестировании): integer;
папка_1, в которую поступают постоянно файлы;
папка_2, проверенные файлы.
Так вот, как лучше реализовать следующее:
из папки_1 берется файл, вычисляется CRC32, затем если сходство найдено с какой-либо записью в БД, то файл удаляется, иначе файл перемещается в папку_2.
За 20 мин надумал несколько вариантов:
1) просто напрямую сделать SELECT CRC32 FROM BD_Fish WHERE CRC32=CRC32tESTFILE (т.е. получили crc обрабатываемого файла, и сразу же по этому числу делаем запрос);
2) выбрать все файлы с нужным расширением(т.е. с таким же с каким у проверяемого файла), а затем уже на основании полученного сравнивать CRC;
3) (мудренный:)) разбить основную таблицу на несколько более мелких(т.е. в БД_1 отображются все файлы с crc до 10000, в БД_2 - от 10001 до 100000 и т.д.) и потом уже работать с более мелкими.

Какой вариант выбрать?

ЗЫ. И в догонку вопросик мелкий: как обнулить autoincrement поле?
просто сейчас пока тестирую счетчик в поле ID_file дошел уже до 100, а хотца после всех тестирований начать с заново, не пересоздавать же заново БД?!

← →
Eraser © (2007-10-16 20:04) [1]

> И в догонку вопросик мелкий: как обнулить autoincrement
> поле?

от БД зависит.

← →
vasIZmax © (2007-10-16 20:08) [2]

> Eraser © (16.10.07 20:04) [1]

самое простое - Paradox.
большее пока не требуется, да и смысла нет.
хотя в БД несилен, поэтому спрошу за одно и совета: под такую "задумку" (т.е. все выше описанное основные функции программы, для чего она собственно и будет писаться) какую БД выбрать?

← →
turbouser © (2007-10-16 20:11) [3]

CRC не уникальное значение.
Без имени файла задача не решаема, если CRC и расширение
файла гарантировано не составляют уникальное значение.

← →
turbouser © (2007-10-16 20:13) [4]

CRC не уникальное значение.
Без имени файла задача не решаема, если CRC и расширение
файла гарантировано не составляют уникальное значение.
> [2] vasIZmax © (16.10.07 20:08)

Если парадокс, то вариант 1) подойдет с оглядкой на [3]

← →
vasIZmax © (2007-10-16 20:19) [5]

> turbouser © (16.10.07 20:13) [4]

имя файла влияет на CRC?

← →
turbouser © (2007-10-16 20:26) [6]

> [5] vasIZmax © (16.10.07 20:19)

Имя файла + CRC = уникальное значение.

← →
turbouser © (2007-10-16 20:31) [7]

> [5] vasIZmax © (16.10.07 20:19)

> [6] turbouser © (16.10.07 20:26)

:-) То есть имя файла не влияет на его содержимое,
но контрольная сумма содержимого + имя файла могут
являться уникальными.

← →
vasIZmax © (2007-10-16 20:35) [8]

> turbouser © (16.10.07 20:26) [6]

поступающие файлы, т.е. те которые нужно обрабатывать, (установлено точно за последние 900000 файлов) ни разу не были схожи в имени, т.е. имя поступающего файла само по себе уникально.
но тем не менее, такие файлы с разными именами абсолютно одинаковые. поэтому, имхо, не вижу целесообразности использования каким-либо образом имя файла.
Если не уловил какого-то нюанса, прошу объяснить.

← →
vasIZmax © (2007-10-16 20:40) [9]

> turbouser © (16.10.07 20:31) [7]

Насколько я знаю вероятность совпадения файлов по CRC крайне мала, настолько что ей можно пренебречь.
Но исходя из твоих (Ваших) постов, следует как раз обратное. Правильно?

← →
turbouser © (2007-10-16 20:43) [10]

> vasIZmax © (16.10.07 20:35) [8]

А, так еще и имя файла уникально... Тогда лучше отказаться от CRC и
использовать хеш, MD5 например. Я сначала подумал, что реализуется
что-то на подобие поиска дубликатов в фс.

← →
vasIZmax © (2007-10-16 20:52) [11]

> turbouser © (16.10.07 20:43) [10]

ну, так и получается это ж и есть поиск дубликатов?
Берем файл, считаем его CRC, затем полученное значение ищем в БД, не найдено -> значит подобного файла не было ранее получено, а если найдена подобная запись, то файл уже попадался, и его удаляем.

Я как-то спрашивал в "Начинающих" о сравнении файлов, первоначально решил по-байтово их сравнивать, что в принципе и осуществляю на первом этапе программы. Но мне посоветовали реализацию БД+CRC, что позволит еще раз проверить на дубликаты.

ЗЫ. с хеш, MD5 работать не приходилось, но видимо неминуемо знакомство с сим...

← →
turbouser © (2007-10-16 21:22) [12]

> vasIZmax © (16.10.07 20:52) [11]
> ну, так и получается это ж и есть поиск дубликатов?

Да, поиск дубликатов, но немного не так получается :)
Если учесть количество файлов (> за последние 900000)
то с учетом 4-х миллиардного CRC ошибка подкрадется незаметно :)
В случае с 128 битным MD5 это плачевное событие можно немного отсрочить.

← →
vasIZmax © (2007-10-16 21:36) [13]

> turbouser © (16.10.07 21:22) [12]

Но если использовать расширение+CRC, то следовательно ошибка при имеющемся количестве N различных расширений отодвинится на N*4 млрд. В принципе неплохо, но для большего (даже если юзать MD5 с отсрочкой) все ж надо поразмыслить... ошибки крайне не желательны... необходимо "что-то+расширение+CRC".

ЗЫ. на вскидку представил такую связь "что-то+расширение+CRC+MD5"... тогда уже вероятно прийдется задуматься и другой БД?!

← →
turbouser © (2007-10-16 22:06) [14]

> vasIZmax © (16.10.07 21:36) [13]

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

← →
DVM © (2007-10-16 22:12) [15]

CRC32 + MD5 = уникальное значение. Можно до кучи(или всесто) добавить CRC64. Вероятность совпадения ничтожна, и можно считать, что ее нет.

Вот GUID он тоже не 100% уникален и ничего, все работает. Повторений вроде еще не случалось.

← →
Petr V. Abramov © (2007-10-17 02:24) [16]

> (установлено точно за последние 900000 файлов) ни разу не были схожи в имени,
законы Мэрфи имеют приоритет над законами больших чисел.
А хуже всего то, что, что из этого следует, что в программе заложен глюк, проявляющийся по оперделенным пятницам после полнолуния

> Petr V. Abramov © (17.10.07 02:24) [16]
> законы Мэрфи имеют приоритет над законами больших чисел.
electronically tested, как пишут на некоторых изделиях

> Petr V. Abramov ©

Гы, как говорят некоторые люди из моего icq контакт листа :)
Мерфи со своими законами тут не при делах - чистая математика.
Человеческий фактор всегда есть, но к Мерфи это не относится :)

> DVM © (16.10.07 22:12) [15]

хорошо, вот получили мы уникальное значение для файла путем crc32+md5.

А теперь все-таки что лучше использовать из [0] (какой вариант) в совокупности с какой БД (Paradox "отпадает" получается) будет максимально быстро работать?

>> с какой БД (Paradox "отпадает" получается) будет максимально быстро работать?

Локально - с аксессом при использовании нативного драйвера.

> А теперь все-таки что лучше использовать из [0] (какой вариант)
> в совокупности с какой БД (Paradox "отпадает" получается)
> будет максимально быстро работать?

SQlite - самая шустрая БД.

> [21] tesseract © (19.10.07 12:28)
>
>
> SQlite  самая шустрая БД.

Вот на http://www.codenet.ru/db/other/sqlite/ почитал о SQlite.
Че-то не могу понять кой-чего:
Поддерживает базы данных размером до 2-х терабайт (241 байт)(эту приписку с 241 байтом тож не пойму)
и
Наиболее вероятным использование программы представляется в следующих областях:прикладные программы с небольшими базами данных&#133
Вроде 2 терабайта это достаточно много(?), или это все-таки относится к небольшим БД?
Или просто там описка?
Для моей задачи подойдет вполне будет хватать? Как думаете? (с БД вообщем мало знаком)

Да&#133 И относительно того по каким критериям будет сравнение файлов  размер+расширение+CRC32+MD5.
Сначала выборка_1 по всем схожим размерам файла, затем выборка_2 из выборки_1 по расширениям, а затем уже окончательный «диагноз» поставит (CRC32+MD5).
Что скажете? Не сильно на мудренно?

> Для моей задачи подойдет вполне будет хватать? Как думаете?
> (с БД вообщем мало знаком)

Это DLL!!! просто понимает sql - соотвественно она самый шустрый, ты бы лучше SQL для нее просмотрел :-)

Вот не могу сообразить, как лучше сделать Найти похожие ветки