Дякую за відповіді !
Виникло ще одне запитання
Ситуація наступна,
написав html-сторінку,простеньку, і прописав там форму і метод POST, який передає дані на сторінку action.php, але вона не може нормально завантажиться, відображається лише код.
Я використовую Денвер, і щоб запускати php скрипти, потрібно самостійно прописувати код, але як зробити щоб браузер міг самостійно відкрити ці файли ?
Дякую
Здравствуйте!
Як зберегти файл у базу даних ? Чи можна його взагалі зберігати ?В зависимости от БД, применяются разные подходы. В одних СУБД сохранение такого типа информации ОБЯЗАТЕЛЬНО должно идти отдельной инструкцией, в других — нет. Подозреваю, есть СУБД, которые не позволяют хранить такой тип данных. Без детализации используемой СУБД ответить точно и правильно невозможно...
Який тип таблиць потрібний ?В большинстве случаев, необходимо определить тип КОЛОНКИ таблицы как BLOB. Если храните картинки на сервере СУБД — то возможно применение типов а-ля FILE и им подобных...
Но мое ИМХО: хранить информацию подобного рода на сервере БД \ в таблицах БД не то что запрещено, но неверно с архитектурной точки зрения. Почему? Спросите у администраторов БД, они доходчиво, понятливо и в красках расскажут детали... :-)
Виникло ще одне запитання
Ситуація наступна,
написав html-сторінку,простеньку, і прописав там форму і метод POST, який передає дані на сторінку action.php, але вона не може нормально завантажиться, відображається лише код.
Я використовую Денвер, і щоб запускати php скрипти, потрібно самостійно прописувати код, але як зробити щоб браузер міг самостійно відкрити ці файли ?
Дякую
К сожалению, тут не подскажу. Я специализируюсь на Базах Данных, а в ПХП разбираюсь чуть лучше, чем свинья в апельсинах :-)
те вы ожидаете что просто можно положить на диск пхп файл, открыть его в броузере и увидеть результат работы скрипта?
Не думал что сейчас столько сторонников хранения и раздачи static files из файловой системы веб сервера. Печаль.
Вы рекомендуете хранить эту файлы в базе данных?
Вы так говорите, будто в этом есть что-то плохое.
БД предоставят не меньше, если не больше удобных готовых решений по сравнению с серверами для раздачи static files с диска в комбинации с Бд, что часто предполагает реализацию велосипедным образом вещей, которые из коробки имеют теже СУБД. Ради чего в описанном случае?
БД предоставят не меньше, если не больше удобных готовых решений по сравнению с серверами для раздачи static files с диска в комбинации с Бд,
EPARSE.
Ради чего в описанном случае?
Резкое снижение нагрузки (отдача файла в сеть в нормальных ОС это очень хорошо вылизанный вариант вообще без прохода через user land), упрощение логики работы (=> сопровождаемость решения).
Это наверное болезненная тема для php девелоперу где нету из коробки неблокирующего io. А пример выше это же бизнесс данные давайте вернемся к записи и хранению. Целостность данных сравните при одном и втором подходе. Далее, сопровождаемость , не заканчивается обеспечением быстрой раздачей файлов в сеть через nginx минимальными ресурсами сервера, это инфраструктурные задачи в первую очередь по обслуживанию. Отказоустойчивость, репликация, бекапирование, горизонтальная масштабируемость репликация сравните при одном и втором подходе.
Это наверное болезненная тема для php девелоперу где нету из коробки неблокирующего io.
Не знаю. Спросите PHP девелопера. А при чём тут неблокирование к сравнению затрат на передачу некоторого набора байт через sendfile() в ядре или через два (минимум) userland и канал между ними? Эти затраты будут одинаковы независимо от блокирования.
Целостность данных сравните при одном и втором подходе.
Я бы сказал, одинакова. Есть причины думать иначе?
Далее, сопровождаемость , не заканчивается обеспечением быстрой раздачей файлов в сеть через nginx минимальными ресурсами сервера, это инфраструктурные задачи в первую очередь по обслуживанию.
Речь вообще-то шла именно про раздачу статики. Чем «инфраструктурным задачам по обслуживанию» помешает хранение файла в FS?
Отказоустойчивость, репликация, бекапирование, горизонтальная масштабируемость репликация сравните при одном и втором подходе.
Сравниваю. С файловой системой большинство пунктов решаются проще и лучше :) А зачем Вы дважды назвали репликацию? С этим какая-то проблема?
А при чём тут неблокирование к сравнению затрат на передачу некоторого набора байт через sendfile()при том что мы говорим про чтении с диска или из базы а не из мемкеша, когда говорим про неблокирующее i\o в этом случае.
Я бы сказал, одинакова. Есть причины думать иначе?Вы по всей видимости не поняли. Мы говорим про две опции.
Речь вообще-то шла именно про раздачу статики. Чем «инфраструктурным задачам по обслуживанию» помешает хранение файла в FS?Интересно почему вы так решили. Вы риплайнули тред где явно упоминаеться запись и хранение данных :
хранения и раздачи static files из файловой системы веб сервер
Сравниваю. С файловой системой большинство пунктов решаются проще и лучше :) А зачем Вы дважды назвали репликацию? С этим какая-то проблема?
при том что мы говорим про чтении с диска или из базы а не из мемкеша, когда говорим про неблокирующее i\o в этом случае.
Я говорю о нём же (с диска, не из memcache). Поэтому повторяю вопрос.
Вы по всей видимости не поняли. Мы говорим про две опции. 1. файл + entity в базе
2. файл на диске + entity в базе.
Во-первых, «мы говорим» просто ложь. Вы этот формат тезиса выдвинули только сейчас. Изначальное Ваше сообщение было:
>>
Не думал что сейчас столько сторонников хранения и раздачи static files из файловой системы веб сервера. Печаль.
Можете перечитать и убедиться, что там ни слова про «entity в базе». И дальше это никак не было названо.
Во-вторых, пусть даже мы добавим какой-то «entity в базе». Зачем при этом форсировать чтение файла из базы? Хочется погреть вселенную?
где подразумевалось другое
/dev/telepathy: file not found. Я не могу понять, что Вы там подразумевали, ни словом ни написав, ни намекнув на это.
Правда интересно почитать как для вас болезненно было поднять standby с актуальной бд на соседнем сервере, когда у вас падает основной по сранвнению с простыми решениями на основе fs хранилищ.
Я где-то хоть словом сказал, что в решении с дублированием FS не будет дублироваться DB? Откуда такие странные домыслы?
Во-первых, «мы говорим» просто ложь. Вы этот формат тезиса выдвинули только сейчас. Изначальное Ваше сообщение было:Это было названо, просто вы невнимательно читаете что вам пишут, еще и в припадках навешиваете мне ярлыки.Вот мой пост вчерашний, можете найти его выше по тексту:
Можете перечитать и убедиться, что там ни слова про «entity в базе». И дальше это никак не было названо.
БД предоставят не меньше, если не больше удобных готовых решений по сравнению с серверами для раздачи static files с диска в комбинации с Бд
Во-вторых, пусть даже мы добавим какой-то «entity в базе». Зачем при этом форсировать чтение файла из базы? Хочется погреть вселенную?Да оверхд будет. Это ощутимо для нагруженных систем, в остальных случаях достоинства БД для хранения очевидны. Я бы волновался куда больше тем как мне управлять этими файлами вне базы и транзакционностью целостностью, чем тем что больше загрузит CPU сервера неблокирующий драйвер чтения базы или FS.
Я где-то хоть словом сказал, что в решении с дублированием FS не будет дублироваться DB? Откуда такие странные домыслы?Я не совсем понимаю о чем тогда спор если мы все равно пришли к тому что данные на диске будут иметь бекап в базе, если я вас правильно понял.
Мне очень интересно как вы без использования entity в базе будете эффективно решать задачу с richtexteditor поставленную в сабже, обходясь одной FS.
еще и в припадках навешиваете мне ярлыки
Припадки тут начались явно не у меня.
просто вы невнимательно читаете что вам пишут
Если Вы про ту фразу, то я её не смог разобрать на части, о чём открытым текстом сообщил. Вы же вместо того, чтобы привести её в читаемый вид, начали фантазировать про PHP девелоперов. Так кто тут собственно не читает, а вместо этого вываливает поток своего сознания, смешанного не с домыслами про собеседника, не то намёками в сторону какой-то неизвестной мне третьей стороны?
Я не совсем понимаю о чем тогда спор если мы все равно пришли к тому что данные на диске будут иметь бекап в базе, если я вас правильно понял.
Неправильно. Данные на диске будут иметь бэкап на другом диске.
Мне очень интересно как вы без использования entity в базе будете эффективно решать задачу с richtexteditor поставленную в сабже, обходясь одним fs.
В текущей версии начального сообщения ни слова про rich text editor. Поэтому никакой задачи там не поставлено. Если вопрос в этом, то претензии к топикстартеру и администрации DOU за возможность редактирования исходного сообщения без сохранения истории.
Воспроизведите его исходное содержание, и тогда посмотрим, так ли уж там нужна БД.
php умеет работать с файловой системой. В ней и хранятся файлы. В БД можно хранить относительный путь, если есть такая необходимость
в своем
rich text editorнаверняка есть кнопка(input type file) для загрузки картинки. при выборе картинки в файловой системе выбери один из
Оба варианта с своими недостатками:
1) Потом у тебя засорится директория с картинками т.к. кто-то использя CMS загружает 100500 картинок пока выберет нужную. Значит надо будет описывать логику временных картинок и следить что бы они не накапливались.
2) Браузеры старые как говно мамонта такое делать не умеют. Base64 увеличивает физический размер картинки примерно на 30% при передаче ну и + regex в придачу
но никогда не сохраняйте файлы в бд.
Схоже, що вам CMS дуже рано писати. Почніть з основ HTML 5, CSS 3.
Хранить картинки в базе данных наверно не самая хорошая идея, но вы все-равно можете попробовать поискать в интернете по ключевым словам sql binary и что-то еще. Наверняка найдете на stackoverflow подходящее решение, либо ответ, почему так делать не очень правильно.
Я бы хранил не саму картинку, а путь к картинке, либо ее уникальное название, чтоб потом подтягивать по необходимости из нужного места.
якщо зберігати посилання на картинку, тоді саму картинку де зберігати ? потрібно буде платить за платні хостинги за розміщення малюнків
Зачем? Заведите себе на сервере где-то директорию с картинками, туда и кладите.
Нормальная идея. Кешируем по мере необходимости. Имеем целостный бэкап и легкую переноcимость
Виникло ще одне запитання
Ситуація наступна,
написав html-сторінку,простеньку, і прописав там форму і метод POST, який передає дані на сторінку action.php, але вона не може нормально завантажиться, відображається лише код.
Я використовую Денвер, і щоб запускати php скрипти, потрібно самостійно прописувати код, але як зробити щоб браузер міг самостійно відкрити ці файли ?
Дякую
Як Ви відкриваєте html-сторінку в браузері? Сподіваюсь, не дабл-кліком на html-файлі?
Перевірте, чи браузер отримує сторінки з веб-вервера, а не безпосередньо з файлової системи (тобто протокол в адресному рядку має бути «http://» чи «https://», а не «file://»).
action.phpНаверное выбран не тот открывающий тег для PHP-кода внутри PHP-файла. Если такая беда под Linux, то там ещё надо ставить флаг выполняемости на PHP-скриптах. Это я всё по памяти, лет 7 тому назад таким занимался.
Ладно, загуглил, там больше причин: stackoverflow.com/...
Vadym Liapin
Vadym Liapin
Нестор Иванович
Дмитро
Отважный Заяц
Valentin Nechayev
Дмитро
anonymous
Gluttton
Gennady Dogaev
Виталий Мартыненко
Костя Третяк
Mikhail Boiko
Mikhail Boiko
Roman Olkhovsky
Oleksandr Demyanenko
Егор
28 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів