Спор между фрилансером и заказчиком, рассудите!

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

Так никто не делает. Либо вы ставите условие: делаем так-то. Либо, если такого жесткого условия не было, он делает по-своему. По факту он сделал по своему.
С вашей стороны нужно было чётко оговорить в ТЗ как и что делать. Кто здесь прав/виноват - не знаю, но я бы судил так: поскольку он сделал по-своему, то, видимо, в какой-то момент вы согласились на его доводы. В любом случае, всегда стоит чётко и конкретно говорить, что вы хотите. Не предлагать, а утверждать. (Здесь правда есть обратная сторона медали - не всегда ваш вариант может быть лучше.)

upd: виноваты оба в общем-то
Попробуйте найти компромиссное решение какое-то. Что-то я бы переделал на месте исполнителя, за что-то нужно будет доплатить...

Цитата:

2AlekartRu, я ему говорил о том, что хранить картинки в базе mysql не резонно и предлогал свой варинат, но он меня переубеждал. Вот пожалуйста факт на лицо. Тем более вы видимо не читаете, что я пишу.

Мне он говорил о конференции, но я ее не смотрел по одной просто причине: я о ней услышал когда сайт был готов на 95%, а не во время разработки нашего ТЗ. А переделка под эту конференцию сулило полной переделкой проекта.

В начале проекта заказчик ничего не говорил про хранения на жестком диске. Я посчитал, что база данных будет оптимальный вариант для данного сервиса! Можно долго спорить, что оптимальнее жесткий диск или база данных, но этот спор подобен спору двух программистов: что лучше PHP или Perl.

Цитата:

Загрузите картинку 1,5 мегабайта и вы увидете, что она вовсе не загружаеться.

PHP не отвечает за стабильность загрузки через HTTP форму, за это отвечает сервер, здесь мы бессильны!

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

K-a-j - а что тут не дружественно, ты не указал путь к файлу, в добавок после вывода ошибки форма не сбилась, все осталось так как ты настраивал, так что будь добр убери лишнию загрузку и нажми отправить!

Насчет ошибки в браузере, спрашиваю уже у 4 человека, ни у кого нет такой ошибки, очень странно!

И теперь вопрос на миллион: Почему хранить в базе картинки не резонно, аргументируйте?

Вот хорошая статья по закачки больших файлов на сервер:
ссылка

Я к сожалению ею воспользоваться не мог, т.к. она не реализуема для виртуальных хостингов, у Михаила же физический как я понимаю!
Для этого нужно открыть php.ini и установить все параметры что указаны в этой статье, к сожалению через htaccess подобное не провернешь!

Доброго Всем Дня!

Неправы обе стороны. В большей мере - Заказчик.

Исполнитель (по ходу обсуждения) -
0) Дизайн стоит долларов 10, но это дело вкуса и минимализма - тут спорить можно до Вечности.
1) Хранение картинок в MySQL это... мягко говоря... не есть хорошо... 1 - по причине скорости, 2 - по причине неудобства работы с этими самыми картинками сторонними средствами.
2) "Юзабил" страшненький - чего стоит вход в "два клика" ("забыли пароль" без формы ввода этого самого пароля смотрится потешно), "добавить один файл" в безокартиночном варианте просмотра смотрится как "До", кнопки "обзор" и "загрузка" выполнены совершенно в разных стилях.
3)... дальше не копался

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

С уважением, Пётр Эшед, DH-Group.

Reverent1985.

Объясни почему на Ты?
Заранее объясни каждому пользователю, что можно, а что нельзя, иначе криво будет работать.


Тебе не нравятся мои слова, оставь как было, пусть юзеры спотыкаются.
Мне твоя работа фиолетово.

Цитата:

Дизайн стоит долларов 10, но это дело вкуса и минимализма - тут спорить можно до Вечности.

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

Цитата:

Хранение картинок в MySQL это... мягко говоря... не есть хорошо... 1 - по причине скорости, 2 - по причине неудобства работы с этими самыми картинками сторонними средствами.

В чем плохо обращения к базе данных даже сторонними средствами не пойму, не раскрыли проблему совершенно. Скорость, могу привести пример: в компании НАСА (это компания в Америке что занимается изучением космоса) свои фотографии космоса с хорошим разрешением хранят в базе данных MySQL проблем у них с этим не возникало!

Цитата:

"Юзабил" страшненький - чего стоит вход в "два клика" ("забыли пароль" без формы ввода этого самого пароля смотрится потешно), "добавить один файл" в безокартиночном варианте просмотра смотрится как "До", кнопки "обзор" и "загрузка" выполнены совершенно в разных стилях.

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

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

K-a-j - извиняюсь за ты, если ВАС это задело, не хотел ВАС обидеть!

Улажено.

Из жизни
Reverent1985, я держу сервис у которого сейчас около 100 000 картинок, их количество быстро растет, это только 3 недели работы!, если бы я хранил их в БД, у меня бы она упала очень быстро, так я держу только названия, это метки U времени, все работает очень быстро - это факт.
Цитата:

Почему хранить в базе картинки не резонно, аргументируйте?

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

Заказчику
Не столь важно на чем реализовано, ipicture вообще написан на CodeIgniter, никакая там cms не используется и неважно на чем писали ребята, MVC действительно расширить позволит легче движок, так что насчет Smarty вообще аргумент _лишь бы для галочки_, с api тоже .. я думаю с нормальным IDE если они код комментировали разобраться не составит труда

Насчет НАСА, у них сомневаюсь что один сервер, всю БД держит )) Т.е. вы обрекаете сразу чтобы легкий сервис, делал высокие нагрузки, в последствии все равно придется либо сделать на файловой структуре либо тратить больше на сервера.

И насчет приема работы исполнитель прав. Нужно было оговаривать время тестирования отдельно к примеру месяц. А так это выглядит как "купил колбасу, вышел из магазина, надкусил, и увидел что там манна вместо мяса и назад в магазин побежал с претензиями, но что в ответ ответили, что вы ничего насчет мяса не говорили, а колбаса и вегетарианская бывает"

Цитата:

Из жизни
Reverent1985, я держу сервис у которого сейчас около 100 000 картинок, их количество быстро растет, это только 3 недели работы!, если бы я хранил их в БД, у меня бы она упала очень быстро, так я держу только названия, это метки U времени, все работает очень быстро - это факт.

Это ваше предположение, у вас же реально нет такого сайт который имел бы 100 000 картинок хранящихся в базе данных что упала, ИМХО в нете много споров по этому поводу и они мне напоминают спор двух прогеров: что лучше PHP или Perl!

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

Цитата:

я думаю с нормальным IDE если они код комментировали разобраться не составит труда

Когда я открыл код и увидел как смешались воедино PHP, HTML, CSS, JavaScript мне стало дурно, если уж признаться честно и лесть в подобную систему что-то было как то неохото! А уж делать ее расширяемой, ууууу.... это вообще ЖЕСТЬ!

Цитата:

Насчет НАСА, у них сомневаюсь что один сервер, всю БД держит ))

Хм, не знаю, но я об этом читал и еще много что читал связанное со спором: "что лучше хранить на жестком диске или в базе данных" и пришел к выводу ОДИНАКОВО приятно!

Reverent1985, а просветите меня, как ваша цмска отдает картинку пользователю? Ну ту, которая в блобе лежит

Цитата:

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

смешной у вас подход )) у вас есть кеш? вы его случайно не в БД храните? как вы думаете почему Smarty тот же файловую структуру использует, а не БД
Цитата:

пользователи не могли просматривать его без наличия пароля

а сессии уже в прошлом или как?)

насчет НАСА, тут долго можно спорить почему они именно БД начали использовать, вы не их админ и я тоже, но я как и многие знают кучу крупных сервисов где файловая структура, тот же photofile, у них вообще отдельные сервера на картинки.
посчитайте сколько операций делает скрипт перед тем чтобы выдать картинку, вместо того чтобы вообще скрипты не использовать, зачем нужны лишние потоки, коннекты к БД?! я вот вообще просто не могу вьехать

Цитата:

смешной у вас подход )) у вас есть кеш? вы его случайно не в БД храните?

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

Цитата:

а сессии уже в прошлом или как?)

Разверните подробнее свой ответ, намек не понятен, что такое сессии я знаю...