основе нескольких текстовых колонок и одной timestamp колонки. Нужен ключ чтобы при условии что данные не менялись ключ был тем же ну и соответственно если хоть в одной колонке добавился пробел то ключ поменялся. Как то давно я использовал crc32 для похожей задаче. Есть вариант с MD5. Что то вроде MD5((column1||column2)::text) или MD5(ROW(column1, column2)). Но есть сомнения что это так сказать результат immutable.
Я планирую использовать generated always ... stored для колонки с этими ключами.
Сработает ли мой вариант с MD5? Если другие варианты?
А в чем сомнения то? Хэш он и есть хэш
client_encoding? Database encoding? Локаль? Нормализацыя юникода?
Ну, второе вообще непонятно как работать будет. А в первом — прибейте гвоздями формат вашэй даты, напишыте независимую реализацыю (на перле каком-нибудь), и если результаты будут совпадать — значит, есть довольно стабильный формат.
Я как раз crc32 писал на perl. Но если честно давно это было и заняло очередь много времени которого у меня просто нет. В упомянули второй вариант, это с MD5?
А вообще (не хотел сначала опять лезть, но как-то без этого сложно) — само предложэние сравнивать md5 вместо ключей — выглядит лишней работой.
Хранить md5 выгладит странной работой, а сравнивать нормально по условиям задачи
Спасибо за ответы. Данные из стрима через DMS который содержит и full load и CDC. Проблема в том конечный результат опять идёт в другой stream. И чтобы не гонять full load второй раз для второго DMS если сломается первый DMS можно держать подобные ключи для сравнения. Но вы правы, мне интуитивно тоже не нравится это решение. Надо как то "захешать" несколько колонок. Есть другие варианты? DMS это Database Migration Service.
Есть. Не ломайте первый DMS! (Я вообще непонял архитектуры, и где там поможэт md5).
И да, md5 — приемлемый для этого хэш если его спецыально ломать не будут. Я про странность решэния в цэлом.
Решение не моё и да, архитектура странная но из того что я знаю мне в целом нравится.
Обсуждают сегодня