Существуют ли серьезные различия в производительности между использованием pickleType и отношениями?

Скажем, есть таблица людей. и пусть говорят, что 1000+ в системе. Каждый элемент People имеет следующие поля: имя, адрес электронной почты, род занятий и т.д.

И мы хотим разрешить элементу People иметь список имен (псевдонимов и т.д.), Где никакие другие данные не связаны с именем - это просто строка.

Это именно то, для чего нужен pickleType? какие преимущества в производительности существуют между использованием типа рассола и созданием таблицы имен, чтобы областью имен людей было отношение "один-ко-многим"?

1 ответ

Да, это один из хороших вариантов использования поля PickleType, который здесь очень хорошо документирован. Для этого есть очевидные преимущества в производительности.

Используя ваш пример, предположим, что у вас есть элемент " People который использует внешний вид одной базы данных. Для этого требуется, чтобы база данных выполняла JOIN для сбора подэлементов; в этом случае прозвища Person's, если таковые имеются. Тем не менее, у вас есть преимущество наличия собственных объектов, готовых к использованию в вашем коде python, без затрат на десериализацию соленья.

Для сравнения, список строк можно мариновать и хранить в виде PickleType в базе данных, которые внутренне хранятся как LargeBinary. Запрос для Person потребует, чтобы база данных попала в одну таблицу без JOIN что приведет к чрезвычайно быстрому возврату данных. Однако теперь вы берете на себя "стоимость" де-травления каждого элемента обратно на объект python, что может быть значительным, если вы не храните собственные типы данных; например, строка, int, list, dict.

Кроме того, сохраняя соленые огурцы в базе данных, вы также теряете способность базовой базы данных фильтровать результаты, учитывая условие WHERE; особенно с целыми числами и объектами datetime. Собственный вызов базы данных может возвращать значения в заданном числовом или датном диапазоне, но не будет иметь понятия о том, что действительно представляет собой строка, представляющая эти элементы.

Наконец, простое изменение одного рассола может привести к произвольному выполнению кода в вашем приложении. Это маловероятно, но нужно заявить.

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

licensed under cc by-sa 3.0 with attribution.