По различным причинам, связанным с пропускной способностью и производительностью сети, у нас есть приложение с большими строками Unicode, преобразованными в байтовые массивы, сжатые с помощью GZipStream . Net framework (.Net core 3.1
).
Мы хотим сохранить их в столбце SQL Server 2017 varbinary(max)
для последующего извлечения и распаковки - это прекрасно работает при использовании той же библиотеки GZipStream для распаковки.
Мы также хотел бы воспользоваться функцией T- SQL Decompress
, чтобы иметь возможность запрашивать данные на сервере БД (без необходимости возвращать их обратно в. Net и распаковывать их там)
Хотя Decompress
, кажется, работает (поскольку в нем не выдается ошибка, и он генерирует двоичный вывод, который может быть приведен к nvarchar(max))
, результирующий nvarchar полностью отличается от исходного источника - на самом деле происходит сбой SSMS при отображении!
Это не проблема, если мы передаем распакованную строку в SQL Server и сжимаем ее там, используя Compress
, но мы не хотим этого делать, поскольку для этого требуется дополнительный шаг распаковки и дополнительное потребление пропускной способности.
Я гарантировал, что мы находимся на CU20 сервера SQL 2017, так что я не думаю, что это проблема исправлений. Я пробовал использовать разные параметры степени сжатия в библиотеке. Net, но все они создают одну и ту же проблему.
Может показаться, что, несмотря на то, что оба сжатия GZip, T- SQL и. * Алгоритмы сжатия 1036 * несовместимы, но если кому-то удастся объединить их, я был бы рад услышать, как это сделать.