Сообщение Re[9]: Способ хранения файлов от 04.03.2023 16:50
Изменено 04.03.2023 16:54 Baiker
Re[9]: Способ хранения файлов
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 4058, Вы писали:
4>>·>Чем абстрактный блоб принципиально от файла отличается?
4>>Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Ещё раз для тех, кто только похмелился и не полностью въехал в тему (или проигнорировал её самую интересную часть):
КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
Соответственно, всё, что требуется от такого хранилища — иметь надёжный бэкап. Более того — иногда можно даже допустить его потерю (те же ушлёпские ролики тиктока).
Отсюда и мой совет выше: НЕ ХРАНИТЬ ФАЙЛЫ В БАЗЕ! Это глупое решение, плачевные последствия которого приходят слишком поздно, чтобы что-то менять.
·>Здравствуйте, 4058, Вы писали:
4>>·>Чем абстрактный блоб принципиально от файла отличается?
4>>Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
Автор: 4058
Дата: 21.02.23
случай, сДата: 21.02.23
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Ещё раз для тех, кто только похмелился и не полностью въехал в тему (или проигнорировал её самую интересную часть):
КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
Соответственно, всё, что требуется от такого хранилища — иметь надёжный бэкап. Более того — иногда можно даже допустить его потерю (те же ушлёпские ролики тиктока).
Отсюда и мой совет выше: НЕ ХРАНИТЬ ФАЙЛЫ В БАЗЕ! Это глупое решение, плачевные последствия которого приходят слишком поздно, чтобы что-то менять.
Re[9]: Способ хранения файлов
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 4058, Вы писали:
4>>·>Чем абстрактный блоб принципиально от файла отличается?
4>>Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Ещё раз для тех, кто только похмелился и не полностью въехал в тему (или проигнорировал её самую интересную часть):
КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
Соответственно, всё, что требуется от такого хранилища — иметь надёжный бэкап. Более того — иногда можно даже допустить его потерю (те же ушлёпские ролики тиктока).
Отсюда и мой совет выше: НЕ ХРАНИТЬ ФАЙЛЫ В БАЗЕ! Это (хранение в базе) — глупое решение, плачевные последствия которого приходят слишком поздно, чтобы что-то менять.
·>Здравствуйте, 4058, Вы писали:
4>>·>Чем абстрактный блоб принципиально от файла отличается?
4>>Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
Автор: 4058
Дата: 21.02.23
случай, сДата: 21.02.23
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Ещё раз для тех, кто только похмелился и не полностью въехал в тему (или проигнорировал её самую интересную часть):
КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
Соответственно, всё, что требуется от такого хранилища — иметь надёжный бэкап. Более того — иногда можно даже допустить его потерю (те же ушлёпские ролики тиктока).
Отсюда и мой совет выше: НЕ ХРАНИТЬ ФАЙЛЫ В БАЗЕ! Это (хранение в базе) — глупое решение, плачевные последствия которого приходят слишком поздно, чтобы что-то менять.