×Закрыть

Бази даних — декілька запитань

Дякую за відповіді !

Виникло ще одне запитання
Ситуація наступна,
написав html-сторінку,простеньку, і прописав там форму і метод POST, який передає дані на сторінку action.php, але вона не може нормально завантажиться, відображається лише код.
Я використовую Денвер, і щоб запускати php скрипти, потрібно самостійно прописувати код, але як зробити щоб браузер міг самостійно відкрити ці файли ?
Дякую

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Здравствуйте!

Як зберегти файл у базу даних ? Чи можна його взагалі зберігати ?
В зависимости от БД, применяются разные подходы. В одних СУБД сохранение такого типа информации ОБЯЗАТЕЛЬНО должно идти отдельной инструкцией, в других — нет. Подозреваю, есть СУБД, которые не позволяют хранить такой тип данных. Без детализации используемой СУБД ответить точно и правильно невозможно...
Який тип таблиць потрібний ?
В большинстве случаев, необходимо определить тип КОЛОНКИ таблицы как 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 в этом случае.
Я бы сказал, одинакова. Есть причины думать иначе?
Вы по всей видимости не поняли. Мы говорим про две опции.
1. файл + entity в базе
2. файл на диске + entity в базе.
Речь вообще-то шла именно про раздачу статики. Чем «инфраструктурным задачам по обслуживанию» помешает хранение файла в FS?
Интересно почему вы так решили. Вы риплайнули тред где явно упоминаеться запись и хранение данных :
хранения и раздачи static files из файловой системы веб сервер
Сравниваю. С файловой системой большинство пунктов решаются проще и лучше :) А зачем Вы дважды назвали репликацию? С этим какая-то проблема?

простите пока мысли читать не умею. Правда интересно почитать как для вас болезненно было поднять standby с актуальной бд на соседнем сервере, когда у вас падает основной по сранвнению с простыми решениями на основе fs хранилищ.
при том что мы говорим про чтении с диска или из базы а не из мемкеша, когда говорим про неблокирующее 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) для загрузки картинки. при выборе картинки в файловой системе выбери один из 2-ух вариантов:
1) Используя Ajax сохраняешь картинку на сервере а в редактор просто постиш img c ссылкой которую тебе вернёт сервак.
2) Переводи картинки в base64 JS-ом (благо все нормальные браузеры уже это умеют). в тексте у тебя img с src="base64_shit" Перед сохранением текста в БД — надо будет распарсить base64 блоки, сохранить как картинки, и заменить их ссылками.

Оба варианта с своими недостатками:
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/...ad-code-shows-on-the-page

Подписаться на комментарии