Эмулируемая PHP файловая система SQL? Что теперь сказать?

http://www.phpclasses.org/package/9...storing-files-in-SQL-database.html#view_files

Итак, это «примечательный» PHP-пакет, предназначенный для эмуляции файловой системы в SQL — и мне просто интересно… почему?

Информация по ссылке не слишком хороша, поэтому мне было интересно, может ли кто-нибудь пролить свет на этот вопрос - не будет ли «файловая система», эмулируемая в SQL, хуже, чем просто манипулирование реальными файлами на жестком диске? Особенно, если рассматриваемый жесткий диск является SSD-накопителем?





Каковы будут преимущества этого (кроме, возможно, безопасности за счет правильно сформированных PDO-запросов и, конечно, если у вас ограниченный объем фактического файлового пространства, но нет ограничений на размер SQL) - но для хранения большого количества файлов , причем большие файлы при этом в SQL?

Конечно, я на самом деле не смотрел сам класс, просто читал информационную страницу и все такое, но... почему?

вам могут понадобиться отношения, и у вас не может быть подходящего сервера базы данных.

есть хостинговые компании, которые ничего не разрешают.

даже не SQlite.

Так что это способ использовать отношения.

Тем не менее, это из головы.

сам урок не видел.

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

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

Хотя я понимаю, что отношения могут быть необходимы, я все еще не понимаю необходимости хранения реальных файлов в базе данных. Это кажется ОГРОМНЫМИ накладными расходами. Когда вы могли бы с таким же успехом хранить их в файловой системе и просто сохранять ссылку в базе данных?

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

и он связан с чем-то, с чем я играл. Некоторые хосты блокируют readfile, fread, fopen, get_file_contents и т. д. по соображениям безопасности — это блокирует возможность PHP выполнять такие действия, как чтение содержимого файла, связанного с безопасностью, и его вывод.

Если вам нужно поведение типа файловой системы, и эти команды файловой системы заблокированы.

Нередко можно встретить общие хосты, где в php.ini есть что-то подобное.

отключить_функции = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,fopen,readfile,file_get_contents,file_put_contents,file

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

Хотя в тот момент я бы посоветовал просто найти лучшего хостера...



Несмотря на то, что я все еще говорю, что 99% такой чепухи не были бы нужны, если бы они просто сделали это так, что include и require не могут открывать файлы, которые не имеют расширения .php, а fopen, readfile и т. д. были заблокированы для открытия файлов, заканчивающихся в .php - представляете ли вы, сколько простых и распространенных PHP-эксплойтов потерпят неудачу, если это будет сделано?





Это то, с чем я сейчас играю — поскольку у меня есть «один индекс, чтобы управлять ими всеми», белый список .htaccess (все, что не является статическим файлом, например jpg, gif, css и т. д., отправляется в индекс .php) В самом начале я добавляю код, который выполняет rename_function с использованием случайного хеша - указанный хеш хранится в статическом частном свойстве синглтона файловой системы - который затем использует этот синглтон в качестве оболочки для ограничения доступа к типу файла.



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

Да, PHP настолько «небезопасен по своей конструкции», что временами это смешно.

Ну... "подробнее" - это неправильное употребление.

Я не вижу выгоды.

Нет никакой реальной информации о том, ПОЧЕМУ это следует использовать.

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

Моя точка зрения остается неизменной: почему бы просто не использовать файловую систему? Зачем вводить еще одну точку отказа при доступе к файлам?

Я предполагаю, глядя на задействованную кодовую базу и методологию? Это какая-то толстая, раздутая, тупая, тупая задница, дышащая ртом, которую сплел какой-то пускающий слюни придурок, у которого нет кода для написания деловых писем.



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

Но, честно говоря, я говорю то же самое о Bootstrap и jQuery, поэтому YMMV...

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

Если вы не запускаете свой сервер на заброшенном старом сервере с ограниченной шиной, скажем, SCSI первого поколения или на старых дисках IDE 4200 об/мин без кэша, тогда возможно это будет быстрее (учитывая, что вы используете свой db-сервер конечно, от чего-то другого) - но сегодня, с SSD-накопителями, современными файловыми системами и общей структурой доступа в большинстве приличных ОС... да.

Мэйби, этот проект запущен, чтобы показать, что PHP может делать такие вещи, и, может быть, в определенных настройках это можно использовать... я понятия не имею, что это за настройки... Моей первой мыслью было... "Просто потому, что оно может..."

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

При чем тут база данных на отдельной машине? База данных может быть расположена на космической станции, что меня волнует - вы просто ссылаетесь на файл на любом сервере/системе, на котором файл на самом деле находится? У вас может быть отдельный веб-сервер, база данных и файловый сервер, мне все равно.



И если у вас по какой-то причине нет возможности обмениваться файлами напрямую из файловой системы, вам необходимо а) получить новый сервер, б) правильно настроить сервер и в) оба предыдущих варианта. Я вообще не вижу в этом НИКАКОГО применения.

И то, что это «избранный» класс на сайте, на который я ссылаюсь, просто показывает, что они обычно понятия не имеют, что они там делают...