Джанго BinaryField - Обоснование заявления в документации

В 1.10 документации Django для BinaryField field type, они дают предупреждение о его использовании:Джанго BinaryField - Обоснование заявления в документации

Злоупотребление BinaryField

Хотя вы могли бы подумать о хранении файлов в в базе данных, считают, что это плохой дизайн в 99% случаев. Это поле не заменяет правильную обработку static files.

Он не содержит никаких оснований для этого иска. Существуют ли какие-либо обобщенные показатели того, что входит в 99% -ный «плохой дизайн» или 1% «плохой дизайн»? Это кольцо особенно верно для Django, потому что оно поддерживает большие статические файлы?

источник

2017-01-30 Julien

Возможный дубликат [Медленность, найденная при выборе и кодировании изображения базы 64) (http://stackoverflow.com/questions/41228496/slowness-found-when-base-64-image-select-and-encode- from-database) – e4c5

Модели Django являются абстракцией для реляционной базы данных. Они преуспевают в хранении небольшого количества данных с четко определенным форматом и соотношением. Они оптимизированы для фиксированной длины строки и низкой памяти.

Является ли ваша фиксированная длина данных меньше 4 КБ и не предназначена для обслуживания веб-сервером? Вероятно, вы в 1%.

источник

2017-02-23 11:19:22 gkr

Откуда вы получаете цифру 4Kb? Вы подразумеваете, что JSONFields, ArrayFields, TextFields и другие поля нефиксированной длины также не подходят для использования? Можете ли вы предоставить источник или ресурс, поддерживающий это, или, по крайней мере, что-то для дальнейшего чтения? – Julien

4Kb произвольно, взято из демонстрационной сцены. Текстовое поле, которое долгое время было бы короткой записью в блоге, для сравнения. И, извините, у меня нет источника на этот, только не очень хорошая память из моего учебного года по информатике. В большинстве современных баз данных есть инструменты для поиска TextField и возврата взвешенного результата, поэтому я предполагаю, что это нормально. Мне еще не было достаточно любопытно проверить, как они обрабатываются, но я не удивлюсь, если строка сохранит указатель на фактические данные. – gkr

Я прошу конкретно обосновать этот вопрос, а не только понаслышке (это примерно столько, что дает документация). Кроме того, если можно предположить, что в этих строках хранятся только указатели, не исключено ли, что это верно и для данных BinaryField? – Julien

Я считаю это преждевременной оптимизацией в лучшем случае и культовым программированием в худшем случае.

Хотя верно, что системы реляционных баз данных не оптимизированы для хранения больших полей (будь то двоичные или текстовые), а некоторые из них относятся к ним специально или, по крайней мере, имеют некоторые ограничения на их использование, большинство из них обрабатывают хотя бы умеренно (скажем, до нескольких сотен мегабайт). Хранение изображений или файлов PDF в базе данных будет менее эффективным, чем хранение их в файловой системе, но для 99% всех приложений он будет достаточно эффективным.

С другой стороны, если вы храните эти файлы в файловой системе, вы теряете несколько преимуществ:

Обновление будет вне транзакций, так что вы не можете быть уверены в том, что обновление файла (в файловой системе), а метаданные (в базе данных) будут атомарными.
Вы теряете ссылочную целостность: ваша база данных может ссылаться на файлы, которые были удалены или переименованы.
У вас есть два разных места, где вы храните свои данные. Это затрудняет доступ, резервное копирование и т. Д.

Я бы попытался сохранить все данные вместе, которые принадлежат логически вместе. Обычно это означает сохранение всего в базе данных. Если это технически невозможно (например, потому что ваши файлы слишком большие - большинство RDBMS имеют ограничение по размеру на blobs), или потому, что тесты показывают, что они слишком медленны или в противном случае неудобны, вы всегда можете оптимизировать их позже.

источник

2017-11-03 12:24:55

Джанго BinaryField - Обоснование заявления в документации

ответ

Смежные вопросы