1.1, Аноним (1), 14:42, 20/03/2009 [ответить]
| +/– |
Увы, нельзя утверждать. Коллизии никто не отменял.
| |
|
2.2, Aleksey (??), 14:47, 20/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Увы, нельзя утверждать. Коллизии никто не отменял.
Угу. Только в данном случае вероятностью коллизии можно пренебречь. Потому что вероятность получить один хеш для случайных данных почти нулевая. Другое дело, если подбирать данные целенаправленно.
| |
|
1.3, uldus (ok), 15:11, 20/03/2009 [ответить]
| +/– |
А если "B" текстовое поле и данных уйма, от такого PostgreSQL ресурсы не съест ?
Для текстовых данных лучше еще один вызов md5 добавить:
select md5(array_send(array(select md5(B) from A order by 1))) as md5;
| |
|
2.4, Aleksey (??), 18:29, 20/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
В реальности все намного хуже. Мы же не учитываем порядок и ключ у таблицы. На примере: в первой таблице у Васи 100 рублей, у Пети 200. Во второй - наоборот. Просчет md5 по рублям даст один и тот же результат для этих двух таблиц. Т.е. они типа равны :)
Поэтому в реальной ситуации надо использовать ключевые поля. Пусть в таблице A два поля - обычное B и ключевое K, тогда
select md5(array_send(array(select md5('' || K) || md5('' || B) from A order by K))) as md5;
| |
|
3.5, Александр Макаренко (?), 10:41, 22/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Это, наверное, выйдет за рамки задачи, которая стояла перед автором. :) Хотя довольно интересно. Если развивать Вашу идею далее, может выйти функция, обращающаяся к системным таблицам pg_*. :)
| |
|
|
1.6, Тормал (?), 19:07, 23/03/2009 [ответить]
| +/– |
Ну ни кто не запрещал добавлять дополнительные условия во WHERE. Я только предложил методику. Так как у меня порядка 30 миллионов записей в таблице. Мне нужно было сравнить наборы данных. И естественно я просматривал некоторые таблиц разбив на сегменты по дате например.
| |
|
2.7, konst (??), 18:15, 24/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
1. а что мешает делать вывод поля таблицы в файл (используя нужный order by x,y,z), а далее сравнивать по md5 сами файлы?
2. играясь опциями LIMIT/OFFSET можно вычислить "тонкое место" (где данные не совпадают), чтобы не таскать по сети большие объемы. а далее использовать diff...
3. Для этой цели можно написать скриптик, который сам все сделает:
Напр.:
1) с помощью limit/offset выгрузит поле в 100 (1000) файликов.
2) md3sum по ним с рез-тами в файл >> md5_1 (1-й сервер), md5_2 (2-й)
3) diff md5_1 md5_2
4) если найдены расхождения - diff по "несовпадающим" файлам...
| |
|
|
4.9, konst (??), 20:49, 24/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Собственно говоря а зачем файлы ?
2 причины:
1) меньше нагрузка на БД (?)
2) иногда может потребоваться не только констатировать факт различий, но и найти их...
| |
|
5.10, Тормал (?), 20:57, 24/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
LIMIT/OFFSET можно использовать на лету. Дальше поиск делением где различия. Нагрузка на БД как раз будет больше при создании файлов. Так как диск используется дважды. + Сортировка по полям съест тотже объем памяти что и при подсчете md5.
| |
|
|
|
|
|