|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Доброго дня, Хочу услышать мнение по поводу хранения фотографий (штук 300-600, каждая по 2 мега) в БД Firebird 2.5. Знаю что можно реализовать хранение в виде файлов в какой ни будь шаре и ссылке на ней. Но так же хотелось бы мнение по поводу быстродействия БД если она будет в себе держать такие данные в отдельной таблице. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2020, 22:32 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
FIL23 штук 300-600, каждая по 2 мега ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2020, 23:47 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
FIL23, 57 тыщ картинок в базе, 15 гигов файл - полет нормальный ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 00:00 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
FIL23, у нас продукт в продаже есть, массово хранит документы примерно такого объема, в т.ч. и картинки. FB 2.0, до сих пор не апгрейдили. На быстродействие сервера не жалуемся, тормоза случаются на клиенте - после загрузки, документ иногда обрабатывается сложным образом. Про хранение в "шаре" думали, но делать не стали - и так завелось, чего ещё мудрить. Fib+. До 300 пользователей (в самом тяжелом случае). ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 00:21 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
GrigoriyFomin FIL23, 57 тыщ картинок в базе, 15 гигов файл - полет нормальный Я вас понял. Значит мне беспокоиться не о чем. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 01:44 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Сейчас храню картинки в самбовой шаре. Примерно 500тысяч файлов, примерно 15Гигов. Структура так устроена что картинки хранятся всего в трех папках. Это создает некоторые проблемы. Например скопировать такое хранилище обычными инструментами - капец как долго. Приходится извращаться. Ну и выполнить синхронизацию в филиалы - тоже не очень удобно. Сейчас делаю это через FreeFileSync. Задумываюсь над переносом картинок внутрь базы. Скорее всего это будет отдельная, не там где документы и все прочее. У меня уже есть отдельная база, для выгрузки длинных логов. Часть в рабочей базе, примерно год, а более старые выгружаю в отдельную. В основной базе в таблице хранятся параметры - строка коннекта к базе логов. Т.е. при настройке клинта достаточно указать строку коннекта к основной базе, остальное он посмотрит уже в ней. Сейчас таким образом клиент узнает путь к самбовой шаре с картинками, ну а будет узнавать строку коннекта и логин/пароль к базе с картинками. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 10:02 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
fraks Это создает некоторые проблемы. Например скопировать такое хранилище обычными инструментами - капец как долго. Приходится извращаться. Ну и выполнить синхронизацию в филиалы - тоже не очень удобно. Сейчас делаю это через FreeFileSync. . попробуйте rsync ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 10:47 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
FIL23 Значит мне беспокоиться не о чем. У нас база с картинками под 250 гиг, не знаю сколько там сканкопий, лень считать. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 11:02 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
По теме, но не про Firebird можно почитать статью (2006 год) на MS Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2020, 22:30 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
FIL23 fraks Это создает некоторые проблемы. Например скопировать такое хранилище обычными инструментами - капец как долго. Приходится извращаться. Ну и выполнить синхронизацию в филиалы - тоже не очень удобно. Сейчас делаю это через FreeFileSync. . попробуйте rsync Если с линуха на линух - то rsync работает хорошо. Однако, под винду реализацию rsync я нашел только одну, а у нее при большом количестве файлов через несколько сотен файлов возникают какие-то зависания на минуты. Потом проходят, и потом опять по тому же циклу. В итоге общая скорость синхронизации падает до совершенно неприемлемых значений. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2020, 21:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
FIL23 Знаю что можно реализовать хранение в виде файлов в какой ни будь шаре и ссылке на ней. Можно использовать UDF/UDR для подтягивания в СУБД файлов с файловой системы в виде BLOb по реферальной таблице "идентификатор<=>путь_ФС". ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 09:17 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
rdb_dev FIL23 Знаю что можно реализовать хранение в виде файлов в какой ни будь шаре и ссылке на ней. Можно использовать UDF/UDR для подтягивания в СУБД файлов с файловой системы в виде BLOb по реферальной таблице "идентификатор<=>путь_ФС". А в чем тогда профит "внешнего" хранения? В "шаре" картинки напрямую прикладным приложением открывать можно, а тут - для чего? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 16:10 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, Например быстрее и значительно меньше бекап? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 21:42 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Шавлюк Евгений ъъъъъ, Например быстрее и значительно меньше бекап? Огромный массив картинок - отдельно, маленький файл базы - отдельно? Наверное, очень удобно бэкап огромного массива делать, предварительно выгнав юзеров. Хотя, можно забить на консистентность и не выгонять. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 21:57 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, если идентификатор картинки, это UUID, то с консистентностью, обычно, проблем не возникает. Можно даже реализовать дедупликацию картинок, если хранить в этой же таблице значение хэш-функции от картинки и при совпадении значения хэш-функции загружаемой картинки делать побайтное сравнение. Нормальный подход, широко применяемый в big data. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:11 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
rdb_dev обычно ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:13 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, ну, если не напортачишь и если БД на том же носителе, что и картинки, а не где-то в сети на периодически недоступном ресурсе, типа сильно территориально удалённого тома iSCSI. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:20 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
rdb_dev если не напортачишь Тогда да. ... Или просто хранишь в блобах и не паришься о глупостях. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:22 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, в основном критерии по хранению файлов в файлах или блобах такие - накладные расходы на вытаскивание файла из блоба или из файла файловой системы - транзакционность блобов в отличие от файлов по второму пункту есть миф о том, что при модификации части блоба модифицируется только изменяемая часть. Но увы, это не так - в Firebird модифицируется весь блоб целиком (даже если мы говорим про array, который тоже blob). Потому что версионность, и надо держать старую версию блоба и новую. А если для версий записей есть дельты, то для блобов дельт нет. Хоть байт изменился - будет записан весь блоб по новой (и будет храниться до определенного времени старый блоб со старой версией записи). как-то так. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 00:23 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
kdv, я храню файлы в блобах, и ни о каких модификациях по частям я ни разу не задумывался: не было надобности. Возможно, "внешнее" хранение дает какие-то преимущества - я не знаю, пытаюсь понять, что это даёт, кроме очевидного гемора. Все, что предлагается - требует каких-то телодвижений, это уже гемор, и часто - небезопасный. Выше написано, что бэкап будет "компактнее" или быстрее. Почему компактнее - неясно, те же картинки обычно уже хорошо упакованы, то есть практически несжимаемы. Некоторые типы файлов хорошо сжимаются - в базе такие блобы помечаются флагом IS_COMPRESSED, клиент их на лету сжимает/распаковывает. То есть, насчет "компактности" файлов вопрос открыт. Можно придумать какие-то схемы инкрементальных бэкапов, но, повторюсь, все они требуют дополнительных телодвижений с неизбежными глюками, а я использую готовые, давно отлаженные, "встроенные" средства Firebird. У клиентов тупо каждые несколько часов запускается процедура формирования бэкапа, без прерывания работы, в фоне. Вместо использования отлаженного разработчиками FireBird механизма, потратить сколько-то ресурсов для создания велосипеда, из-за которого запросто можно потерять данные, из-за которого придется создавать неудобства в работе клиентов? ..."общая шара" мне категорически не нравится по причинам, завязанным конкретно на мои задачи, хотя возможный профит я назвал. ..."использовать UDF/UDR" для трансляции клиентам "внешнего" файла - это что даст, в каком месте и за счет чего улучшение будет? Кроме гипотетически "удобного, быстрого и компактного" бэкапа, ничего не названо. Все ещё интересно "соотношение накладных расходов по вытаскиванию файлов vs вытаскивание блоба". Каково это соотношение? Ну вот, у меня на клиенте - редактор MSWord, я даже не знаю, сколько времени файл вытягивается из блоба, MSWord точно дольше запускается. Если блоб станет загружаться в два раза быстрее - что изменится? Может быть, плюсы "внешнего" хранения станут заметны в каких-то особых случаях? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 01:10 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, я бы сказал, что "внешнее" хранение файлов в базе облегчилось бы, если бы в ФБ ввели tablespaces (как в IB 2020). Тогда, как минимум, можно было бы бэкапить отдельно tablespace основной базы и блобов. Вообще, для меня хранение файлов в базе или вовне определяется связанностью информации в этих самых файлах с данными в БД. Если это фото пользователей, договоры, документы, их сканы, автобиографии и проч, то хотелось бы иметь это в базе (хотя и в отдельном tablespace). Если же просто задача некий набор картинок "организовать", тогда нунах, файлы отдельно, а в базе - ссылки на эти файлы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 01:19 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
kdv, ну, мы просто попробовали хранить документы базе, все сразу и "взлетело", и всё, с тех пор мы в птичку всякий хлам пихаем. Ещё с беты 2.0. Альтернатива, наверное, была, мы что-то даже обсуждали, но, раз все сразу завелось "и так" - так нафига себе лишние проблемы придумывать? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 02:12 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ rdb_dev пропущено... Зачем ссылки? Можно использовать UDF/UDR для подтягивания в СУБД файлов с файловой системы в виде BLOb по реферальной таблице "идентификатор<=>путь_ФС". А в чем тогда профит "внешнего" хранения? В "шаре" картинки напрямую прикладным приложением открывать можно, а тут - для чего? На сервере не нужно делать иной доступ к файлам на шаре, типа самба не нужна. Достаточно только коннекта к базе. Соответственно не нужно администрировать этот иной доступ. Руление правами через базу а не в самбе. Уменьшение размера бэкапа, соответственно и времени бэкапа и рестора. Например у меня база 16Гигов, и картинок снаружи примерно так же. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 03:38 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
fraks Уменьшение размера бэкапа За счет чего? Бэкапим только файл базы, без картинок? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 04:43 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ fraks Уменьшение размера бэкапа За счет чего? Бэкапим только файл базы, без картинок? Естественно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 10:24 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
fraks, Ну и какой смысл в таком бэкапе? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:29 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, вообще-то смысл есть. Файлы то можно не все копировать, а только новые. С базой данных такое проблематично ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:33 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов ДенисС базой данных такое проблематично Инкрементальный бэкап существует. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:35 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, инкрементальный бекап надо периодически накатывать на полный, и делать полный тоже. Иначе когда пипец придёт будешь восстанавливаться очень долго. А база состоящая чуть менее чем полностью из блобов очень большая. Это тебе не инкрементальный бекап на основе гуида в 4.0 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:52 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денисинкрементальный бекап надо периодически накатывать на полный Никаких отличий от копирования новых файлов, их тоже надо накатывать на полную копию. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:55 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денис ъъъъъ, вообще-то смысл есть. Файлы то можно не все копировать, а только новые. С базой данных такое проблематично Если не знать о наличии готового инструмента "инкрементальный бэкап" - тогда да. Ну, ОК, причины решения типа "внешние файлы" примерно понятны. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:02 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, об инструменте то известно. Но подумай вот о чём. Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук. Тут падает база данных сколько ты будешь её восстанавливать по времени? Это тебе не 4.0, где ты можешь иметь полуготовую БД и накатывать на неё только последний инкремент. С отдельным файлами ты копируешь только новые файлы. Старые у тебя всегда на готове. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денис Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук. Тут падает база данных сколько ты будешь её восстанавливать по времени? ОК, 1Тб - небыстро. А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов? Пусть будет слегка расхристанное состояние консистентности, зато восстановление быстрое? Или к файлам применяем некую чудесную операцию, восстанавливающую их к состоянию на момент бэкапа файла базы? Даже если "внешние" файлы все, полностью бэкапились в момент бэкапа файла базы - как ты обеспечишь консистентность "файл базы <-> внешние файлы" в таком бэкапе? Выгонишь всех юзеров на время бэкапа или переведешь их в режим ридонли? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:42 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:51 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денис С отдельным файлами ты копируешь только новые файлы. Старые у тебя всегда на готове. Просто нужно хорошо понимать как им пользоваться :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:51 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Если взять за правило никогда не изменять внешние файлы после первоначального создания Не меняем, не удаляем, храним все версии - отлично, партизаны всё толще. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:59 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ Не меняем, не удаляем, храним все версии - отлично, партизаны всё толще. Хранятся уникальные экземпляры файлов - запрет на изменение после создание позволяет связывать с одним экземпляром хоть миллион имён. Сборка мусора - фоновая (не приоритетная) задача. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 15:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ Симонов Денис Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук. Тут падает база данных сколько ты будешь её восстанавливать по времени? ОК, 1Тб - небыстро. А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов? Пусть будет слегка расхристанное состояние консистентности, зато восстановление быстрое? Или к файлам применяем некую чудесную операцию, восстанавливающую их к состоянию на момент бэкапа файла базы? Даже если "внешние" файлы все, полностью бэкапились в момент бэкапа файла базы - как ты обеспечишь консистентность "файл базы <-> внешние файлы" в таком бэкапе? Выгонишь всех юзеров на время бэкапа или переведешь их в режим ридонли? Я наверное глупый и не понимаю смысла жизни, но мне почему-то кажется, что при хранении ссылки на файл, живущий в ФС внутри БД, последняя версия 100 раз обновлённого файла по той же ссылке путь-имя - это именно то, что доктор прописал после восстановления повреждённой базы со ссылками. Остаются вопросы по удалённым и добавленным с момента создания бакапа файлам. Решается, в общем-то, тривиально при применении драйвера hands.sys. Оно, конечно, ломотно - шевелить мозгами-руками раз в год по обещанию вместо того, чтобы часов по 8 получать ежедневный бакап и 80 подождать окончания рестора при аврале. Опять же, это время можно потратить на удовольствие от курения бумбука и принятия элитного алкоголя, кстати, секретаршам и бухгалтершам в это время совершенно нехрен делать, а на работе быть надо и, чем чёрт не шутит, может и перепасть... Впрочем, я, как всегда, ни на чём не настаиваю, конкретные ситуации они и есть конкретные. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 21:48 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка при хранении ссылки на файл, живущий в ФС внутри БД, последняя версия 100 раз обновлённого файла по той же ссылке путь-имя - это именно то, что доктор прописал после восстановления повреждённой базы со ссылками. Остаются вопросы по удалённым и добавленным с момента создания бакапа файлам. Решается, в общем-то, тривиально при применении драйвера hands.sys. Это не мои базы, это не моя война, я - чЮдо-программист, а не админ и не эксплуатационник. Программный продукт "в коробке", нафига мне им рассказывать о внутренней кухне, чтобы они там внутри копались? Да и, клиент дай бог вообще хоть какой бэкап настроит, а чтобы он что-то там начал выборочно внутри копаться - это вообще фантастика. Надежность обеспечивается исправным оборудованием вкупе с надежным энергоснабжением и регулярным резервным копированием в соответствии с рекомендациями, а восстанавливать данные по файликам - это кто будет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 22:15 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ fraks, Ну и какой смысл в таком бэкапе? Смысл в том что такой бэкап компактнее и делается быстрее, в обе стороны. Естественно, допустимость такого очень зависит от того что там за картинки. Если это документы которые существенно обесценивают данные при их отсутствии, то у меня например это картинки к товарам, и это не является критичным. Я даже не делаю специальных бэкапов этой папки с картинками. Если вдруг с ней что-то случается - сделаю обратную синхронизацию из какого-нибудь филиала, ибо в ту сторону синхронизация происходит как минимум ежедневно. Для меня критично снижение нагрузки на сервер при бэкапах во время работы. Ну и время рестора, если вдруг такое понадобится. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 03:51 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
fraks например это картинки к товарам, и это не является критичным Понятный пример, спасибо. У меня - наоборот, база существует ради этих "картинок". В общем, все как всегда: "детали важны". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 05:08 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Можно свои 3 копейки внесу? Вариантов хранения пользовательских файлов не 2, а 3 как минимум. Вот ИМХО их достоинства и недостатки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
"Думайте сами, решайте сами - иметь или не иметь". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 15:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
shalamyansky, Способ №3 имеет мало преимуществ по сравнению с №2. Сейчас все же ломают копья сторонники №1 и №2. Из плюсов 2 и 3 - возможность дедупликации. Хотя наверное и в №1 это можно устроить ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 15:23 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Шавлюк ЕвгенийСпособ №3 имеет мало преимуществ по сравнению с №2. ну это смотря где используешь. Представь себе какой-нибудь веб-сайт. В простейшем случае картинка это просто файл до которого есть доступ у веб сервера, и он отдаёт его простой веб-ссылкой. А если это запихнули в блоб, то файлик из блоба ещё надо прочитать, а потом отдать его с нужными заголовками. Если содержимое файла защищено, то это конечно оправдано, а если оно не нуждается в каких-то там привилегиях, то имеем не хилый оверхед. Каждый случай имеет право на существование. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 15:34 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Насчёт "оверхеда" при хранении в блобах. Я так понимаю, что ни у кого именно с "оверхедом" именно из-за неправильно выбранной архитектуры хранения файлов проблем не было. Никто из-за него не переделывал систему со схемы "файлы в блобах" на "файлы снаружи" (или наоборот)? Предполагаю, что нет. :) Мне нравится схема, когда изображения товаров хранятся "снаружи", а сам файл базы остаётся крошечным, и при этом не сильно страшно сломать связи с несколькими картинками. Я бы в клиента кнопку возле картинки добавил - "Сообщить об отсутствии изображения или об ошибке"... :) ... Но вот у меня "картинками" являются, например, разные документы по расчёту стоимости, и, если пролюбить утвержденный план замены бордюрного камня в СВАО Москвы, то, мне кажется... ыыы ... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:39 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денисимеем не хилый оверхед. Современные уэб-программисты не заботятся о таких мелочах. Они и кэширование-то картинок всегда запрещают, не то что там установить LastModified заголовок. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:04 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, разве вебпрограммисты используют Firebird? У них что-то волшебное, которое само собой объекты в базу сохраняет, и наоборот, из базы объекты восстановливает, с дикой скоростью. Так пишут. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:11 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1560348]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
127ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 261ms |
0 / 0 |