경로, 이름, 접미사를 별도로 유지하는 데 익숙하며 전체 URL, 즉 위의 모든 항목을 연결하는 필드가 있습니다.

귀하의 질문에 따르면, 처음부터 이미지의 상대 경로를 데이터베이스에 저장하는 것이 좋을 것 같습니다. 나중에 타사 이미지 서비스를 저장하려면 이를 타사 이미지 서비스로 대체하는 스크립트를 작성하면 됩니다. -파티 이미지 주소를 일괄적으로 처리하고 싶다면 이제 타사 이미지 서비스를 사용할 수 있습니다.

일반적으로 자체 데이터베이스에 이미지 경로를 저장합니다. 이미지가 너무 많으면 얼마나 많은 공간을 차지합니까? 실제 사진은 Qiniu 등과 같은 타사 플랫폼에 저장할 수 있습니다. 구현 아이디어는 먼저 Qiniu Cloud Server에 업로드하고 저장된 경로 강도를 얻은 다음 이를 자체 데이터베이스에 저장하는 것입니다.

현재 이미지를 저장하는 일반적인 방법은 이미지 리소스를 이미지 서버에 통일된 방식으로 업로드한 후 이미지 경로를 저장하는 것입니다. 데이터 양이 매우 많은 경우에는 별도의 테이블에 따라 저장할 수 있습니다. 해시 값. 프로젝트에서 사용되는 경우 모든 이미지는 Images.xxx.com/path.png를 사용하여 로드됩니다. 또한, 이미지 서버를 사용하지 않고 전용 도메인명을 사용하는 경우에는 웹사이트의 루트 디렉터리에 리소스 폴더를 생성하여 여기에 모두 경로가 사용되는 곳에 "/"를 사용하고, 마이그레이션을 용이하게 하려면 루트 디렉터리에서 시작하세요. 그러면 경로 문제가 발생하지 않습니다.

자신의 서버를 저장하면 데이터베이스의 상대경로! 도메인 이름을 마이그레이션하거나 변경해도 상관 없습니다. 도메인 이름만 변경하고 다른 것은 걱정하지 마세요. 전체 경로를 저장하고 도메인 이름 IP를 변경하면 비참해집니다!

제3자에게 저장하면 ID가 반환됩니다. 이 ID를 직접 저장하면 원하는 사진을 얻을 수 있습니다.

로컬 서버에 있는 이미지인 경우 프로젝트의 루트 디렉터리에 대한 상대 경로를 저장합니다(예: /upload/20170413/xxxx.png). 이는 두 가지 장점이 있습니다. 1. 직접 사용할 수 있습니다. 프런트 엔드에서 참조할 때. (전제는 nginx 등의 구성 루트가 프로젝트 경로라는 것입니다.) 2. 큰 문제 없이 프로젝트를 직접 마이그레이션할 수 있습니다.
제3자 주소인 경우 전체 주소를 직접 저장하세요(예: http://img.xxx.xx.qiniu.com/x...). 제3자인 귀하는 방해할 수 없습니다. 당신도 할 수 없습니다. 주소 이전에 대한 이야기가 있을 것입니다.