Upload файлов на сервер - DB vs HDD

[[VS]]

Автор оригинала: aloner
> Сделать INSERT/DELETE/UPDATE проще, чем копировать/удалять файлы.
> чем?

Имеется в виду копирование/удаление/изменение файлов с параллельным обновлением информации о них в базе данных.

Ок, согласен, хотя разница минимальна.

> FTP клиент который конектица "напрямую к файловой системе".

Покажите мне FTP-клиент, который умеет на ходу прописывать название/время/размер файла в базу - я на нем женюсь!

а что, есть готовый GUI который в базу картинку запихнет? его же придется почти под каждый проэкт модернизировать.

В конторе, где я тружусь, базу ведет менеджер, который не будет лазать по FTP - проще в GUI-клиенте нажать кнопку "добавить изображение".

Напиши за 20 минут скрипт который будет брать изображение, писать в файл и ставить запись в базе.

 

[aloner]

> а что, есть готовый GUI который в базу картинку запихнет? его же придется почти под каждый проэкт модернизировать.

Для CMS-системы не придется. Вообще, мне не довелось видель ни одного Веб-интерфейса, работать в котором было бы удобнее чем в GUI-клиенте. (d)HTML просто не предназначен для таких задач.

> Напиши за 20 минут скрипт который будет брать изображение, писать в файл и ставить запись в базе.

За 10 минут можно управиться.


Куда ложить картинки - личное дело каждого программера.

IMHO, у хранения в базе больше преимуществ, чем у хранения на диске (при грамотном подходе разницы в скорости практически нет). Точка.

Повторюсь, при хранении картинок на диске - проблем больше, чем при хранении в базе. Это мое личное на 100% субъективное мнение.

 

[[VS]]

Я согласен, но есть "НО":
Для ускорения работы с базой придется делать файловый кэш, а это имхо сведеть на ноль удобство базы.

 

[redic]

согласен с aloner'om ибо иногда этому менеджеру надо мало того что просто залить картинку, так он может захотеть залить их сотни, а потом так же сотнями менять

 

[redic]

сорри конечно но я не вижу как файловый кеш может свести на ноль преимущества базы
я думаю что это случай когда от каждого взять по способности
от базы свое от фала свое
и при этом ни одно из этих свойств не ущемляет другое

 

[webdeveloper]

С интересом послушал всех. Пришел к выводу что база лучше. Как минимум проще на этапе разработки. С ней и будем работать.

Всем большой спасибо за советы. Действительно было очень интересно послушать.

 

[[VS]]

Автор оригинала: redic
сорри конечно но я не вижу как файловый кеш может свести на ноль преимущества базы
я думаю что это случай когда от каждого взять по способности
от базы свое от фала свое
и при этом ни одно из этих свойств не ущемляет другое

Единственное приемущество базы - это простота работы.
И это приемущество теряется, так как мы сильно усложняем работу кодом для файлового кэша.

 

[[VS]]

Автор оригинала: redic
согласен с aloner'om ибо иногда этому менеджеру надо мало того что просто залить картинку, так он может захотеть залить их сотни, а потом так же сотнями менять

Ну и что? Он будет их заливать все-равно через веб интерфейс, который будет абсолютно одинаковый, в случае работы с базой и с файлами.

 

[[VS]]

Автор оригинала: webdeveloper
С интересом послушал всех. Пришел к выводу что база лучше.

В твоем конкретном случае - возможно. Обобщать не вижу смысла, так как случаи бывают разные.

Как минимум проще на этапе разработки.

Сначала должен быть этап проэктирования, где и будет определяться - где хранить картинки, а потом менять возможно будет уже проблематично.

Сначала же проэктируем а потом разрабатываем, а не наоборот

 

[.des.]

2VS ну наверное имелось ввиду что можно отделить эту часть от остальной.. то есть обращаться к картинкам через некий интерфейс... а как он там внутри реализован должно быть все равно остальным частям.
и вначале можно даже и без кэша обойтись.. а потом дописать критичные участки. не в этом ли суть модульности?

 

[webdeveloper]

Автор оригинала: [VS]

Сначала же проэктируем а потом разрабатываем, а не наоборот

Там вообще целая история с этим связана. Я сначала сделал аплоад на диск. Потом мне показалось интересным и я сдела аплоад в базу. просто для интереса, т.к. не знал как это на РНР делать. После этого мне показалось что аплоад в базу лучше. Решил так оставить. Теперь вот сижу и пишу третью версию и там снова встал этот вопрос. Один знакомый меня даже почти убедил хранить все на диске

 

[.des.]

вот что значит сначала продумать потом написать... если предусмотреть это раньше, то можно было бы обойтись переписыванием только этого модуля... а так как я понимаю, ты и в остальные части проекта вносишь изменения.. что не есть гуд!

 

[webdeveloper]

Автор оригинала: .des.
вот что значит сначала продумать потом написать... если предусмотреть это раньше, то можно было бы обойтись переписыванием только этого модуля... а так как я понимаю, ты и в остальные части проекта вносишь изменения.. что не есть гуд!

Не там практически ничего не изменилось. Только модуль загрузки картинок. Все остальное от этого не зависит.


Если есть желание то можно на это погладеть здесь - http://vsm31.garbuz.com/
http://vsm31.garbuz.com/siteadmin/

но там еще не все готово.

 

[aloner]

Автор оригинала: [VS]
Я согласен, но есть "НО":
Для ускорения работы с базой придется делать файловый кэш, а это имхо сведеть на ноль удобство базы.

???

Почитай мои сообщения выше...пожалуйста.

 

[tony2001]

>IMHO, у хранения в базе больше преимуществ, чем у хранения на
>диске (при грамотном подходе разницы в скорости практически нет).
>Точка.
такие заявления надо подтверждать аргументами.

>Повторюсь, при хранении картинок на диске - проблем больше, чем при
>хранении в базе. Это мое личное на 100% субъективное мнение.
твое личное субъективное мнение может быть неверным.

>согласен с aloner'om ибо иногда этому менеджеру надо мало того
>что просто залить картинку, так он может захотеть залить их сотни,
>а потом так же сотнями менять
и что ?
для этого пишется еще два скрипта, которые автоматизируют подъем картинок из указанных директорий.
по ФТП картинки залил, скриптом поднял, скриптом потом же и удалил.
дешево и сердито.

 

[aloner]

> такие заявления надо подтверждать аргументами

Могу дать список сайтов, которые делал и где хранение картинок реализовано тем или иным образом.
В базе было легче поддерживать.

> твое личное субъективное мнение может быть неверным
Оно и не претендует на верность.

> по ФТП картинки залил, скриптом поднял, скриптом потом же и удалил

Девочка-менеджер, которая может обновлять базу, FTP не знает. Вообще я всегда думал, что софт делать нужно, ориентируясь на среднестатистического ламера, который знает только Word/Excel и как включить компьютер.

Иногда по работе бывает нужно вручную поменять файлы в оракловой базе и прописать им доп. инфу. Это занимает примерно раза в полтора меньше времени на файл, чем с ФТП-вариантом.

 

[tony2001]

>Могу дать список сайтов, которые делал и где хранение картинок
>реализовано тем или иным образом.
>В базе было легче поддерживать.
извини, для кого легче ?
МНЕ - легче так, как мне легче.,

>Девочка-менеджер, которая может обновлять базу, FTP не знает.
>Вообще я всегда думал, что софт делать нужно, ориентируясь на
>среднестатистического ламера, который знает только Word/Excel и
>как включить компьютер.
специально для девочки - менеджера сделан народ.ру, на котором можно грузить сразу по N файлов.

>Иногда по работе бывает нужно вручную поменять файлы в
>оракловой базе и прописать им доп. инфу. Это занимает примерно
>раза в полтора меньше времени на файл, чем с ФТП-вариантом.
скажи, что ты пошутил.
по-моему, ты вообще не понял о чем речь.
"прописать им доп. инфу" - это работа с базой, а не с ФТП, ибо инфа о файле в базе храниться.
ФТП - это НЕ обязательно, ФТП - это как плюс в случае хранения файлов там, где им положено быть - в файловой системе.
с таким же успехом можно заливать их и через веб, но в базе при этом не хранить.

 

[RomikChef]

Как же я не люблю, когда передергиавают.
.

Сделать INSERT/DELETE/UPDATE проще, чем копировать/удалять файлы.

при создании кэша ВСЕ РАВНО придется копировать-удалять. только плюс добавятся еще операции с базой.

4. В случае повреждения ФС - риск потери файлов - нужен дополнительный скрипт, который будет искать битые.

База, видимо, при повреждении своих файлов, останется стоять, как стояла.

 

[webdeveloper]

2 aloner, VS, .des.

Мужики, кто нибудь может сказать при каком колличестве обращений к базе за картинками она начнет загибатся?
Допустим наш сайт имеет тысячу посещений в день. Эти посещения, как правило, происходят в пределах 8 часового рабочего дня. То есть 125 посетителей в час. Допустим в час пик это будет на 125 а 300. Получается вроде вполне приемлемо, а? Что думает почтенная публика по этому поводу?

 

[RomikChef]

девелопер.
я уже много раз писал.
Этот форум про то, как лучше писать программы, а не как лучше загрузить свой сервер бесполезной работой.
Это безотносительно твоего последнего вопроса.
Это относительно твоего первого.

Меня умиляют люди, которые хранят картинки в базе данных.
им так проще.
ага. и аутпут буфферинг - тоже проще. хотим из программы сделать винегрет. Нам так удобнее.
В результате получаем, что обычная картинка в 80 кил уже отжирает у нас 250. простенькая страничка галереи в 10 картинок - 2,5 мега. На ПУСТОМ МЕСТЕ.

Меня умиляют люди, которые призывают делать кэш. мол, с с базой удобнее.
Ага. при наличии кэша надо все равно проверять - есть ли такая картинка в кэше, и поменять на новую, если есть.
получается, что ВСЕ РАВНО при аплоаде загружать на диск.
Но при этом мы имеем кучу дополнительного кода с помещением в базу данных, с доставанием из базы данных, с проверкой - есть ли картинка в кэше, с проверкой актуальности кэша, с чисткой кэша от старых картинок.

Меня умилают люди, которые пишут целый агрегат вместо
<img src="<?=$row['pic']?>"> и говорят, что им это ПРОЩЕ!

А потом начинают спрашивать

"Я сделал, как МНЕ проще! а теперь хочу спросить - а сколько посетителей сможет ходить на мой сайт? "

"Я храню картинки в базе, почему-то клиенту они приходят битые!!! Памагииитя!!!!"

"Вот код, который показывает картинки из базы. ГДЕ ошибка?
10 килобайт кода удалено модератором"

Нет, этот цирк никогда не кончится.