MySQL에 이미지를 저장할 PHP인가요, 아닌가요?

MySQL에 이미지를 저장할 PHP인가요, 아닌가요?

사용자가 먼저 로그인해야 하는 PHP에 작은 웹 애플리케이션을 만들었습니다.로그인이 완료되면 작은 썸네일을 "프로필"의 일부로 보여드릴 생각입니다.

공간을 절약하기 위해 이미지가 특정 크기 이하인지 확인하거나 특정 해상도인지 확인하거나 이미지 매직 같은 것을 사용하여 축소해야 합니다.
그것을 위한 최선의 방법이 무엇인지 아직 확실하지 않습니다. 어떤 아이디어라도 환영합니다.

이미지를 users의 MySQL을 blob하거나,다.images 이미지 한 id블,합니다 id지에 만 하면 됩니다.users만 하면를 통해서도)블,고도)다로 할 수 있습니다.theUsersUniqueUsername.jpg 최선의 선택?

여기에서 이미지를 mysql에 저장하는 방법에 대한 튜토리얼을 찾았습니다. http://www.phpriot.com/articles/images-in-mysql

저는 단지 취미 프로그래머일 뿐이고, 이런 일을 해본 적이 없기 때문에, 예를 들어, 그리고/또는 많은 세부 사항에 대해 매우 감사드립니다.

은 파일 를 합니다라는 /content/user/{user_id}.jpg가능한 한 데이터베이스를 방해하지 않도록 노력해야 합니다.

이미지를 파일로 저장한 후 URI 파일을 데이터베이스에 저장하는 것을 추천합니다.모든 이미지를 데이터베이스에 저장할 경우 나중에 크기 조정에 문제가 생길 수 있습니다.

이 답변도 확인해보세요.

SQL Server에 대한 Microsoft의 조언은 속도와 크기에 대해 이미지를 파일 시스템에 저장하고 데이터베이스에 링크를 저장하는 것이었습니다.선호도가 다소 낮아졌다고 생각하지만, 데이터베이스에 공간을 차지하지 않기 때문에 크기에 대해서는 여전히 더 나은 아이디어라고 생각합니다.

BLOB를 사용하는 오버헤드는 대부분의 사람들이 믿게 하는 것보다 훨씬 적습니다. 특히 올바르게 설정할 경우 더욱 그렇습니다.DB를 실행하는 별도의 서버를 사용하여 이진 파일을 저장하는 경우 사실상 파일 시스템을 전혀 사용하지 않고 파일 시스템의 오버헤드를 방지할 수 있습니다.

서버를 몇 대 보유하지 않는 한 가장 쉽고 좋은 방법은 파일 시스템에 저장하는 것입니다.

• 고유 한 두 만 저장하지 마십시오를 들어 URL DB 를 하십시오. 고유한 부분(그리고 한 개 또는 두 개의 폴더)만 저장할 수 있습니다.2009/uniqueImageName.jpg아니면 그냥uniqueImageName.jpg그런 를 맨 을 확보할 수 한두만 하면 됩니다 그런 다음 페이지에서 호스트와 다른 폴더를 앞에 추가하면 이미지 이동에 유연성을 확보할 수 있습니다. PHP/ASP에서 한 두 줄만 변경하면 됩니다.NET 페이지.

• 을 - - a.htaccessDENY FROM ALL이 포함된 파일도 동일하게 작동하며 보다 유연성을 제공합니다.

• 할 없이 '' 만 됩니다.getImage.php한 ,에 실제 하는 대신 URL에를제합니다.srcimage…합니다.getImage.php?file=uniqueImageName.jpg에 에.getImage.php파일은 사용자가 승인되었는지 확인하고 이미지를 잡을 수 있습니다(또는 그렇지 않음.

• 할 때 한 이름: 을 시스템은 대소문자를 구분하지 () 합니다. 일부 파일 시스템(즉, Windows)은 대소문자를 구분하지 않습니다.JoeBloggs.jpg그리고.joebloggs.jpg데이터베이스에는 고유하지만 파일 시스템에는 고유하지 않으므로 하나가 다른 하나를 덮어씁니다.

• 이미지에 별도의 테이블을 사용하고 이미지의 기본 키를 사용자 테이블에 저장합니다.더 많은 필드를 추가하거나 미래에 변화를 주고 싶다면 더 쉬워질 것입니다. 좋은 연습 방법이기도 합니다.

할 때 :alt).그).

전통적인 지혜에 도전!

물론 상황에 따라 다르지만 MySQL 데이터베이스에 BLOBS로 저장된 수천 개의 이미지와 문서가 포함된 매우 큰 애플리케이션이 있습니다(평균 크기=2).MB)와 애플리케이션은 256MB의 메모리가 있는 서버에서 정상적으로 실행됩니다.비결은 올바른 데이터베이스 구조입니다.항상 두 개의 테이블을 보관해야 합니다. 그 중 하나는 파일에 대한 기본 정보를 저장하고, 다른 하나의 테이블은 blob과 액세스를 위한 기본 키만 포함해야 합니다.모든 기본 쿼리는 세부 정보 테이블에 대해 실행되며, 다른 테이블은 파일이 실제로 필요할 때만 액세스할 수 있으며 색인화된 키를 사용하여 액세스하므로 성능이 매우 우수합니다.

데이터베이스에 파일을 저장할 때의 이점은 여러 가지입니다.

1. 파일 시스템을 백업할 필요가 없기 때문에 훨씬 더 쉬운 백업 시스템이 필요합니다.
2. 파일 보안을 제어하는 것은 바이너리를 릴리스하기 전에 검증할 수 있으므로 훨씬 쉬워집니다(예, 파일을 공개되지 않은 디렉토리에 저장하고 스크립트를 읽고 파일을 다시 재생할 수 있지만 성능이 눈에 띄게 빨라지지는 않습니다).
3. (#1과 유사) "사용자 컨텐츠"와 "시스템 컨텐츠"를 깨끗하게 분리하여 마이그레이션 및 클로닝을 보다 쉽게 할 수 있습니다.
4. 버전 제어를 추가하는 데 필요한 스크립트 수정 수가 적어 파일 관리, 버전 변경 추적/저장 등이 용이합니다.

성능이 큰 문제이고 보안 및 백업이 그렇지 않은 경우(또는 우수한 FS 백업 시스템이 있는 경우)에는 FS에 저장할 수 있지만, 이미지의 경우에도 종종 DB에 파일을 저장하고 처음 사용한 후에 이미지를 캐시 폴더에 쓰는 캐싱 스크립트를 구축합니다(예, HD 공간을 더 많이 사용합니다).그러나 그것은 거의 결코 제한 요소가 아닙니다.

어쨌든 FS는 많은 경우에 잘 작동하지만, 개인적으로는 DB 관리가 훨씬 쉽고 유연하며, 잘 작성하면 성능 저하가 극히 적다고 생각합니다.

이미지를 DB에 저장하는 샵을 만들었습니다.개발 중에는 효과가 좋았지만, 일단 프로덕션 서버에서 테스트해보니 페이지 로드 시간이 너무 많이 소요되어 DB 서버에 불필요한 로드가 추가되었습니다.

바이너리 파일을 DB에 저장하는 것이 매력적으로 보이지만, 파일을 가져와 조작하는 것은 파일 시스템에 파일을 보관하고 경로/메타데이터를 DB에 저장하는 것만으로 방지할 수 있는 추가적인 복잡성을 더합니다.

이것은 양측의 훌륭한 논쟁 중 하나이며 영원한 논쟁 중 하나입니다. 하지만 저는 제 돈으로 DB에서 이미지를 멀리할 것입니다.

저는 최근에 이 팁의 목록을 보았습니다: http://www.ajaxline.com/32-tips-to-speed-up-your-mysql-queries

팁 17: 웹 응용 프로그램의 경우 이미지와 기타 바이너리 자산은 일반적으로 파일로 저장해야 합니다.즉, 데이터베이스에 파일 자체보다는 파일에 대한 참조만 저장합니다.

그러니 이미지에 파일 경로만 저장해주세요 :)

저는 이전 프로젝트에서 두 가지 솔루션(파일 시스템 및 데이터베이스 유지 이미지)을 모두 구현한 경험이 있습니다.제 생각에는 이미지를 데이터베이스에 저장해야 할 것 같습니다.그 이유는 다음과 같습니다.

1. 파일 시스템 스토리지는 앱 서버가 클러스터되면 더욱 복잡해집니다.공유 스토리지가 있어야 합니다.현재 환경이 클러스터화되어 있지 않더라도 필요할 때 확장하기가 더욱 어렵습니다.
2. 어차피 정적인 콘텐츠에 CDN을 사용해야 하고, 앱을 원본으로 설정해야 합니다.이는 앱이 특정 이미지에 대해 한 번만 히트를 친 다음 CDN에 캐시된다는 것을 의미합니다. CloudFront는 값이 싸고 설정이 간단합니다.사용하지 않을 이유가 없습니다.동적 컨텐츠를 위해 대역폭을 절약합니다.
3. 데이터베이스 지속 이미지를 개발하는 것이 훨씬 빠르며(따라서) 비용도 저렴합니다.
4. 데이터베이스 지속 영상에 대한 참조 무결성을 얻을 수 있습니다.파일 시스템에 이미지를 저장하는 경우 일치하는 데이터베이스 레코드가 없는 고아 파일이 발생하거나 파일 연결이 끊어진 데이터베이스 레코드가 발생할 수 있습니다.이런 일은... 시간문제일 뿐입니다이것들을 치우기 위해 무언가를 써야 할 것입니다.

어쨌든, 나의 2센트.

1. 파일 저장용이 아니라면 대체 무엇을 위한 blobdat 타입은 무엇입니까?
2. 응용 프로그램에서 파일에 액세스하기 전에 권한을 부여하는 경우 변경 사항은 a) DOCOMENT_ROOT 외부에 파일을 저장(직접 액세스할 수 없도록)하는 것입니다. 그리고 b) 응용 프로그램을 통해 파일의 전체 내용을 전송하는 것입니다(물론,아마도 당신은 일종의 일시적인 해시(hash) 방식으로 이동하지만 publicly 접근이 가능한 filename 방식의 일을 하고 있을 것입니다.따라서 메모리 오버헤드는 어쨌든 거기에 있고 데이터베이스에서 데이터를 가져오는 것이 좋습니다.
3. 파일 시스템에 파일을 저장해야 하는 경우 위에서 Andreas가 제안한 대로 수행하고 이미 알고 있는 것(예: 관련 테이블의 기본 키)을 사용하여 파일 이름을 지정합니다.

대부분의 데이터베이스 엔진은 이미 매우 발전되어 있기 때문에 BLOB의 데이터를 저장하는 것이 어떠한 단점도 발생시키지 않는다고 생각합니다(booled db 등).한 가지 장점은 이미지가 이미 데이터베이스에 있을 때 끊어진 링크가 없다는 것입니다.그렇기는 하지만, 저는 항상 파일을 디스크에 저장하고 URI를 데이터베이스에 제공하기 위해 제 자신을 해왔습니다.용도에 따라 다릅니다.페이지가 매우 동적이고 네임스페이스가 없는 상태에서 자주 변경되는 경우 img-in-db를 처리하는 것이 더 쉬울 수 있습니다.결국은 당신이 원하는 것으로 끝난다고 말해야겠습니다.

이미지를 db에 저장하지 말 것을 제안합니다.대신 모든 사용자가 DB에 자신의 프로필과 연관된 고유 ID를 갖게 되므로, 이 ID를 사용하여 이미지를 물리적으로 서버에 저장합니다.

예를 들어 사용자가 ID 23을 가지고 있다면 www.yourname.com/users/profile_images/23.jpg 에 이미지를 저장할 수 있습니다.그런 다음 이미지가 존재하는지 확인하고 그에 따라 표시하면 일반 아이콘이 표시됩니다.

다른 사람들이 제안한 대로:

• 파일 시스템에 이미지 저장
• 파일 이름을 저장할 필요 없이 사용자 ID(또는 "이미 알고 있는" 다른 것)만 사용하십시오.
• 정적 데이터를 다른 서버에 저장합니다('static'만 사용하더라도).yourdomain.com "을(를) 일반 서버의 별칭으로 지정)

왜요?

데이터베이스가 커질수록 데이터베이스 속도가 느려집니다.이미지를 데이터베이스에 저장하면 데이터베이스 크기가 커집니다.파일 이름을 저장하면 데이터베이스 크기가 늘어납니다.

정적 데이터를 다른 서버(에일리어스)에 배치:

• 스케일업이 훨씬 쉬워짐
• 대부분의 브라우저는 로드 속도를 높이는 "초" 서버에 정적 데이터를 올려 동일한 서버에 두 개 이상의 요청을 보내지 않습니다.

며칠 동안 연구한 끝에 데이터베이스에 이미지와 바이너리를 저장하는 시스템을 만들었습니다.

너무 좋았어요.액세스 제어, 이미지 크기 조정(물론 이미지를 동적으로 확장하지는 않습니다), 통계, 백업 및 유지보수와 같은 파일을 100% 제어할 수 있게 되었습니다.

제 속도 테스트에서, 그 시스템은 지금 10배나 느려졌습니다.하지만 아직 운영 중이 아니며 시스템 캐시 및 기타 최적화를 구현할 예정입니다.

MVC: http://www.gt8.com.br/salaodocalcado/calcados/meia-pata/ 를 사용하여 SHARED 호스트에서 아직 개발 중인 실제 예제를 확인합니다.

이 예제에서는 사용자가 로그에 기록되어 있으면 다른 이미지를 볼 수 있습니다.모든 제품 이미지 및 기타 바이너리는 캐시되지 않고 FS가 아닌 DB에 있습니다.

전용 서버에서 몇 가지 테스트를 해봤는데 예상을 훨씬 뛰어넘는 결과가 나왔습니다.

따라서, 제 개인적인 생각으로는, 그것을 달성하기 위해서는 큰 노력이 필요하지만, DB에 이미지를 저장하는 것은 가치가 있고, 이점은 훨씬 더 많은 단점을 가질 수 있습니다.

다른 사람들이 말했듯이, 이미지를 데이터베이스에 저장하지 마십시오.파일 시스템은 파일을 저장하는데 사용됩니다 -> 이미지는 파일입니다 -> 파일 시스템에 저장합니다 :-)

방금 내 img를 blob으로 테스트했어, 그래서.이 솔루션은 서버의 파일 이미지보다 느리게 작동합니다.로딩 시간은 DB 또는 http의 이미지와 동일해야 하지만 그렇지 않습니다. 왜죠?확실히, 이미지가 서버에 있는 파일일 때 브라우저는 한 번만 캐싱하고 로드할 수 있습니다.DB에서 이미지를 전송하면 매번 다시 로드됩니다.저의 의견입니다.브라우저 캐싱은 잘못했지만 작동 속도가 느릴 수 있습니다(블롭.미안해 내 영어 뭐든 ;P

두 솔루션의 장점은 다음과 같습니다.

BLOBS에서:

1) 장점 : 서버 간 파일 동기화와 같은 까다로운 점을 처리할 필요가 없으므로 클러스터를 관리하기 쉽습니다.

2) DB 백업 역시 방대합니다.

파일로

1) 네이티브 캐싱을 쉽게 수행할 수 있습니다. 이는 DB에서 새로 고침 및 헤더를 다시 설계할 필요가 없는 이전 의견의 누락점입니다(DB는 기본적으로 마지막 수정 시간을 처리하지 않습니다).

2) 나중에 크기 조정이 용이함

3) 조정의 용이성(모든 것이 올바른지 확인하기 위해 폴더를 뒤지기만 하면 됨)

이 모든 이유로 그리고 데이터베이스의 두 장점이 파일 시스템에 복제하기 쉽기 때문에 저는 강력하게 파일을 추천합니다!

저 같은 경우는 파일 시스템에 파일을 저장합니다.내 이미지 폴더에서 항목 ID(db의 행)를 기준으로 이름이 지정된 각 항목에 대한 새 폴더를 만듭니다.그리고 0부터 시작하는 순서대로 이미지 이름을 지정합니다.그러면 다음과 같은 항목이라는 이름의 테이블이 있으면 다음과 같습니다.

       Items      
|-----|------|-----|
| ID  | Name | Date|
|-----|------|-----|
| 29  | Test1| 2014|
|-----|------|-----|
| 30  | Test2| 2015|
|-----|------|-----|
| 31  | Test3| 2016|
|-----|------|-----|

내 이미지 디렉토리는 다음과 같습니다.

images/
      29/
      30/
      31/


images/29/0.png
images/29/1.jpeg
images/29/2.gif

기타.

언급URL : https://stackoverflow.com/questions/527801/php-to-store-images-in-mysql-or-not