хотя с другой стороны php ведь тоже не низкоуровневый язык )) считай лара для си )) пройдет еще лет 20 и никто уже не вспомнит про php.net все будут сразу ходить на laravel.com ))
хотя с другой стороны php ведь тоже не низкоуровневый язык )) считай лара для си )) пройдет еще лет 20 и никто уже не вспомнит про php.net все будут сразу ходить на laravel.com ))
Верно, php высокоуровневый и лишь единицы интересуются что там под капотом. С другой стороны, оно и правильно. Нафиг тебе знать, что там под капотом, если ты не решаешь какой-то специфический кейс или не контрибьютишь в php?
Вот подкапотную логику СУБД, как оказалось, понимать нужно. Это позволяет эффективнее работать с СУБД. Но с php такой профит ведь вряд ли будет достигнут.
Вопрос:) Кто как хранит информацию об изображениях в бд? Я про имена. Можно хранить только имя, можно в одном поле сразу относительный путь от общего каталога загрузки, разделить это на 2 поля "путь" и "имя".
Вопрос:) Кто как хранит информацию об изображениях в бд? Я про имена. Можно хранить только имя, можно в одном поле сразу относительный путь от общего каталога загрузки, разделить это на 2 поля "путь" и "имя".
лучше отдельно хранить имя(для показа пользователю) и отдельно некий путь в системе хранения
Лучший (не всегда возможный) вариант хранить только физический путь. А для показа пользователю приложение (например, фронтенд) будет вычислять самостоятельно. Это может быть ссылка на cdn или просто внешний адрес, генерируемый по конкретному правилу. Если путь можно получить исходя из локального адреса, то нет смысла хранить его.
мы храним отдельно оригинальное имя какое было при загрузке и путь от каталога upload как он внутри хранится при скачивании можно переопределить имя для файла. а можно ничего не указать тогда файл вернется с оригинальным именем какой был