Как лучше всего уменьшить значение первичного ключа?

Question

Я разрабатываю приложение (.Net), которое поддерживает Oracle, Sql Server и Informix в качестве хранилищ данных. Проблема с Informix заключается в том, что одна таблица (это устаревшие компоненты) имеет первичный ключ из 2048 символов, и Informix не разрешит использование PK такой ширины. Поэтому мое первоначальное решение состоит в том, чтобы приложение получило значение MD5 из значения ключа и использовало его в качестве первичного ключа при вставке или поиске данных. Хорошо, это работает, но оставляет мне непосредственную проблему «обновления» данных в существующих базах данных, что по разным причинам должно быть выполнено с помощью сценария Sql. К сожалению, Informix не имеет встроенной функции MD5, поэтому мне будет сложно написать сценарий Sql для создания нового столбца PK и заполнения его из существующих данных.

Итак, мой вопрос: кто-нибудь может предложить лучший способ значительного сжатия длинного строкового значения, чтобы избежать этой проблемы?

Answer 1

Ваш подход имеет недостатки, так как PK должен быть определением уникальным, и MD5 может генерировать коллизии (дубликаты).

Вместо этого рассмотрите возможность использования суррогатного PK (например, идентификатор или GUID).

Кто-нибудь может предложить лучший способ значительного сжатия длинного строкового значения, что позволит избежать этой проблемы

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

В ответ на комментарии:

У меня также естьпроблема с суррогатными ключами, которые не имеют никакого отношения к сохраняемой дате - плохой дизайн базы данных

Я знаю, что суррогатные против естественных ключей - спорный вопрос, но, конечно, предлагаемый вами хэш MD5 по сути является суррогатным ключом?И в любом случае «весь дизайн - это компромисс», поэтому я бы не назвал дизайн базы данных «плохим» без некоторого контекста.ИМХО, если нет естественного ключа короче, чем 2048 символов, суррогатный ключ вполне может быть хорошим вариантом.

Есть также компромиссы производительности, которые следует учитывать: с суррогатным ПК MD5 или GUID у вас есть потенциал для страницыразделяется по мере того, как новые строки будут вставляться в середину таблицы против конца для идентификатора PK.

По какому определению?

Ключевое слово «произвольно»».Алгоритм сжатия без потерь, такой как ZIP, не гарантирует достижение заданной степени сжатия для всех входных данных - подумайте о попытке заархивировать ZIP-архив.

Answer 2

В Informix, если вы создаете пространство баз данных с большими размерами страниц (вам необходимо использовать страницы размером 12, 14 или 16 КиБ), вы можете создавать индексы для ключей размером до 3 КиБ в этом пространстве баз данных (эмпирическое правило, 5 ключевых значений должны помещаться на одной странице указателя).

Но ключ такой большой, вероятно, не очень эффективен, чтобы быть вежливым. Мне было бы любопытно увидеть разбивку столбцов в ПК и почему они должны быть такими большими, чтобы они добавляли до 2 КиБ. Разве вы не можете использовать какой-нибудь суррогат?

Answer 3

Я думаю, вы можете разделить ключ на две части и сохранить эти части в двух столбцах, что-то вроде «id1», «id2».И тогда вы можете создать составной первичный ключ.