DB에 이미지 저장 - 예 또는 아니오?

DB에 이미지 저장 - 예 또는 아니오?

잠겼습니다.이 질문과 그에 대한 답은.질문이 topic을 벗어났지만 역사적 의미가 있기 때문에 잠겼습니다.현재 새 답변이나 상호 작용을 수락하지 않고 있습니다.

그래서 DB에 이미지를 많이 저장하는 앱을 사용하고 있습니다.이것에 대한 전망은 어떻습니까?저는 위치를 DB에 직접 저장하기 보다는 파일 시스템에 저장하는 스타일입니다.

장단점은 무엇이라고 생각하십니까?

저는 많은 TB 이미지를 관리하는 몇몇 애플리케이션을 담당하고 있습니다.데이터베이스에 파일 경로를 저장하는 것이 가장 좋다는 것을 발견했습니다.

몇 가지 문제가 있습니다.

• 데이터베이스 스토리지는 보통 파일 시스템 스토리지보다 더 비쌉니다.
• 별도의 제품을 사용하지 않고 표준으로 파일 시스템 액세스 권한을 극대화할 수 있습니다.
  • 예를 들어, 많은 웹 서버는 운영 체제의 sendfile () system 호출을 사용하여 파일 시스템에서 네트워크 인터페이스로 직접 파일을 비동기식으로 보냅니다.데이터베이스에 저장된 이미지는 이 최적화의 혜택을 받지 못합니다.
• 웹 서버와 같은 것들은 파일 시스템에서 이미지에 접근하기 위해 특별한 코딩이나 처리를 필요로 하지 않습니다.
• 데이터베이스는 이미지와 메타데이터 간의 트랜잭션 무결성이 중요한 부분을 확보합니다.
  • DB 메타데이터와 파일 시스템 데이터 간의 무결성 관리가 더욱 복잡합니다.
  • 파일 시스템의 디스크에 데이터가 플러시되었는지 보장하기가 어렵습니다(웹 애플리케이션의 상황 내에서).

대부분의 문제가 그렇듯, 이것은 말처럼 간단하지 않습니다.이미지를 데이터베이스에 저장하는 것이 타당한 경우가 있습니다.

• 역동적으로 변화하는 이미지를 저장하고 있는데, 인보이스라고 하는데 2007년 1월 1일 그대로 인보이스를 받고 싶었습니까?
• 정부는 당신이 6년의 역사를 유지하기를 원합니다.
• 데이터베이스에 저장된 이미지는 다른 백업 전략이 필요하지 않습니다.파일 시스템에 저장된 이미지는 다음과 같습니다.
• 이미지가 데이터베이스에 있는 경우 이미지에 대한 액세스를 제어하는 것이 더 쉽습니다.유휴 관리자는 디스크의 모든 폴더에 액세스할 수 있습니다.이미지를 추출하기 위해 데이터베이스를 샅샅이 뒤지려면 정말 단호한 관리자가 필요합니다.

반면에 관련된 문제들이 있습니다.

• 이미지를 추출하고 스트리밍하려면 추가 코드가 필요합니다.
• 지연 시간이 직접 파일 액세스보다 느릴 수 있음
• 데이터베이스 서버의 부하 증가

파일 저장소.페이스북 엔지니어들은 그것에 대해 아주 좋은 이야기를 나눴습니다.한 가지 장점은 디렉토리에 있는 파일의 현실적인 한계를 아는 것이었습니다.

건초 더미 속의 바늘: 수십억 장의 사진을 효율적으로 저장

이는 다소 어려울 수 있지만 SQL Server 2008을 사용(또는 사용할 예정)하는 경우 새로운 FileStream 데이터 유형을 확인해 보는 것이 좋습니다.

파일스트림은 DB에 파일을 저장하는 것과 관련된 대부분의 문제를 해결합니다.

1. Blobs는 실제로 폴더에 파일로 저장됩니다.
2. Blobs는 데이터베이스 연결을 사용하거나 파일 시스템을 통해 액세스할 수 있습니다.
3. 백업이 통합됩니다.
4. 마이그레이션은 "그냥 효과가 있습니다.

그러나 SQL의 "Transparent Data Encryption"은 FileStream 개체를 암호화하지 않으므로, 이를 고려할 때 해당 개체를 varbinary로 저장하는 것이 더 나을 수 있습니다.

MSDN 문서에서:

Transact-SQL 문은 FILESTREAM 데이터를 삽입, 업데이트, 쿼리, 검색 및 백업할 수 있습니다.Win32 파일 시스템 인터페이스는 데이터에 대한 스트리밍 액세스를 제공합니다.
FILESTREAM은 파일 데이터를 캐싱하기 위해 NT 시스템 캐시를 사용합니다.이를 통해 FILESTREAM 데이터가 데이터베이스 엔진 성능에 미칠 수 있는 영향을 줄일 수 있습니다.SQL Server 버퍼 풀이 사용되지 않으므로 이 메모리를 쿼리 처리에 사용할 수 있습니다.

DB의 파일 경로는 확실히 바람직한 방법입니다. TB 이미지를 사용하는 고객들로부터 상당한 양의 이미지를 DB에 저장하는 것이 악몽이 되었다는 이야기를 여러 이야기를 들었습니다. 성능 타격만으로는 너무합니다.

제 경험상 가장 간단한 해결책은 기본 키에 따라 이미지 이름을 짓는 것입니다.따라서 특정 레코드에 속하는 이미지를 쉽게 찾을 수 있으며, 그 반대의 경우도 마찬가지입니다.하지만 동시에 이미지에 대한 어떤 것도 데이터베이스에 저장하지 않습니다.

여기서의 비결은 광신도가 되지 않는 것입니다.

여기서 주의할 점은 프로파일 시스템 캠프의 어느 누구도 특정 파일 시스템을 나열하지 않았다는 것입니다.FAT16부터 ZFS까지 모든 것이 모든 데이터베이스를 쉽게 능가한다는 것을 의미합니까?

아니요.

사실은 원시 속도에 대해서만 이야기할 때도 많은 데이터베이스가 많은 파일 시스템을 능가한다는 것입니다.

정확한 행동 방침은 정확한 시나리오에 맞는 올바른 결정을 내리는 것이며, 이를 위해서는 몇 가지 숫자와 사용 사례 추정치가 필요합니다.

참조 무결성 및 ACID 준수를 보장해야 하는 곳에서는 이미지를 데이터베이스에 저장해야 합니다.

데이터베이스에 저장된 이미지와 해당 이미지에 대한 메타 데이터가 동일한 파일을 참조한다고 트랜잭션으로 보장할 수는 없습니다.즉, 파일 시스템의 파일이 메타데이터와 동일한 트랜잭션에서 동시에 변경될 뿐이라고 보장할 수 없습니다.

다른 사람들이 말했듯이 SQL 2008은 파일 이름이나 식별자를 DB에 포인터로 저장하고 이미지를 파일 시스템에 자동으로 저장할 수 있는 파일 스트림 유형과 함께 제공됩니다. 이것은 훌륭한 시나리오입니다.

오래된 데이터베이스에 있는 경우, blob 데이터로 저장하는 경우, 데이터베이스에서 기능을 검색하는 데 어떤 것도 가져올 수 없기 때문에 파일 시스템에 주소를 저장하고 이미지를 그런 방식으로 저장하는 것이 가장 좋습니다.

이렇게 하면 파일 시스템에 공간을 절약할 수도 있습니다. 정확한 공간만 저장하거나 파일 시스템에 공간을 압축할 수도 있기 때문입니다.

또한 파일 시스템의 원시 이미지를 DB 히트 없이 탐색할 수 있는 일부 구조 또는 요소를 사용하여 저장하거나, 프로그램의 위치를 업데이트하는 다른 시스템, 하드 드라이브, S3 또는 다른 시나리오로 파일을 대량 전송할 수 있습니다.스토리지를 늘리려고 할 때 DB에서 이미지를 가져오려는 시도는 별 타격 없이 다시 시작합니다.

또한 일반적으로 히트한 이미지 URL을 기반으로 한 캐싱 요소를 웹 엔진/프로그램에 추가할 수 있으므로 여기에서도 저장할 수 있습니다.

자주 편집되지 않는 작은 정적 영상(몇 개 이하의 메그)은 데이터베이스에 저장해야 합니다.이 방법은 보다 간편한 이식성(이미지는 데이터베이스와 함께 전송됨), 보다 쉬운 백업/복원(이미지는 데이터베이스와 함께 백업됨), 보다 나은 확장성(수천 개의 작은 썸네일 파일이 포함된 파일 시스템 폴더는 확장성의 악몽처럼 들립니다) 등의 여러 이점을 가지고 있습니다.

데이터베이스에서 이미지를 제공하는 것은 쉽습니다. DB 서버에서 반환된 바이트 배열을 이진 스트림으로 제공하는 http 핸들러를 구현하기만 하면 됩니다.

여기 이 주제에 관한 흥미로운 백서가 있습니다.

BLOB 여부: 데이터베이스 또는 파일 시스템의 Large Object Storage

답은 "다름"입니다.물론 데이터베이스 서버와 블롭 스토리지에 대한 접근 방식에 따라 달라질 것입니다.또한 데이터에 액세스하는 방법뿐만 아니라 블롭에 저장되는 데이터 유형에도 따라 달라집니다.

크기가 작은 파일은 효율적으로 저장하고 데이터베이스를 저장 메커니즘으로 사용하여 전달할 수 있습니다.특히 파일이 자주 수정/업데이트되는 경우에는 파일 시스템을 사용하여 파일을 저장하는 것이 가장 좋습니다. (블롭 조각화는 성능과 관련하여 문제가 됩니다.)

여기 추가로 유념해야 할 사항이 있습니다.블랍을 저장하기 위해 데이터베이스를 사용하는 것을 지원하는 이유 중 하나는 ACID 준수입니다.그러나 SQL Server 처리량을 두 배로 늘린 백서(SQL Server의 대량 로그 옵션)에서 테스터가 사용한 접근 방식은 트랜잭션에 대한 초기 쓰기와 함께 blob 데이터가 기록되지 않았기 때문에 ACID의 'D'를 'd'로 효과적으로 변경했습니다.따라서 전체 ACID 준수가 시스템에 중요한 요구 사항인 경우 파일 I/O를 데이터베이스 블롭 I/O와 비교할 때 데이터베이스 쓰기에 대한 SQL Server 처리량 수치를 절반으로 줄입니다.

아직 아무도 언급하지 않았지만 분명히 주목할 만한 점은 대부분의 파일 시스템에 대용량 이미지를 저장하는 것과 관련된 문제가 있다는 것입니다.예를 들어 위에서 언급한 접근 방식을 사용하여 기본 키의 이름을 따서 각 이미지 파일의 이름을 지정하는 경우 대부분의 파일 시스템에서 매우 많은 수의 이미지(예: 수십만 또는 수백만 개)에 도달하면 하나의 큰 디렉터리에 모든 이미지를 넣으려고 하면 문제가 발생합니다.

일단 이에 대한 일반적인 해결책은 하위 디렉토리의 균형 잡힌 트리로 해시하는 것입니다.

아무도 언급하지 않은 것은 DB가 원자 행동, 거래 무결성 및 동시성을 보장한다는 것입니다.파일 시스템을 사용하면 참조적으로 무결성이 보장되지 않습니다. 그렇다면 파일 이름이 여전히 정확한지 어떻게 알 수 있습니까?

파일 시스템에 이미지가 있는데 새 버전을 쓰거나 파일을 삭제하는 동안 다른 사람이 파일을 읽고 있다면 어떻게 됩니까?

블록은 관리(백업, 복제, 전송)가 용이하기 때문에 사용합니다.그들은 우리에게 잘 들어맞습니다.

데이터베이스에 이미지에 대한 파일 경로만 저장할 때의 문제는 데이터베이스의 무결성을 더 이상 강제할 수 없다는 것입니다.

파일 경로가 가리키는 실제 이미지를 사용할 수 없게 되면 데이터베이스가 자신도 모르게 무결성 오류를 가지게 됩니다.

이미지는 실제로 찾는 데이터이며, 어떤 종류의 파일 시스템과 인터페이스할 필요 없이 하나의 통합 데이터베이스에서 더 쉽게 관리될 수 있기 때문에(파일 시스템이 독립적으로 액세스되는 경우 이미지가 갑자기 "사라질 수 있습니다),BLOB 같은 것으로 직접 보관하고 싶습니다.

제가 다니던 회사에서는 1억 5천 5백만 장의 이미지를 Oracle 8i(이후 9i) 데이터베이스에 저장했습니다. 7.5TB 상당.

일반적으로 저는 인프라스트럭처의 일부(데이터베이스)를 확장하는 데 가장 비용이 많이 들고 가장 어려운 작업을 수행하여 모든 부하를 투입하는 것을 강력히 반대합니다.반면에:특히 웹 서버가 여러 대 있어서 어떻게든 데이터를 동기화해야 하는 경우에는 백업 전략을 크게 단순화할 수 있습니다.

다른 대부분의 것들과 마찬가지로, 그것은 예상되는 크기와 예산에 따라 달라집니다.

SQL2005 blob 필드에 모든 이미지를 저장하는 문서 이미징 시스템을 구현했습니다.현재 수백 GB의 용량이 있으며, 응답 시간이 우수하고 성능 저하가 거의 또는 전혀 없습니다.또한 규정 준수를 위해 새로 게시된 문서를 광 주크박스 시스템에 보관하는 미들웨어 계층이 있으며 이를 통해 표준 NTFS 파일 시스템으로 노출됩니다.

저희는 특히 다음과 관련한 결과에 매우 만족하고 있습니다.

1. 간편한 복제 및 백업
2. 문서 버전 관리 시스템을 쉽게 구현할 수 있는 능력

웹 기반 애플리케이션이라면 아마존의 S3나 Nirvanix 플랫폼과 같은 타사 스토리지 전송 네트워크에 이미지를 저장하는 데 이점이 있을 수 있습니다.

가정:응용 프로그램이 웹 지원/웹 기반임

아무도 이에 대해 언급하지 않았다는 것이 놀랍습니다. 전문가인 다른 사람에게 이를 위임합니다. > 타사 이미지/파일 호스팅 프로바이더를 사용합니다.

다음과 같은 유료 온라인 서비스에 파일 저장

• 아마존 S3
• 모소 클라우드 스토리지

StackOverflow 스레드가 여기서 이 문제에 대해 이야기하고 있습니다.

이 스레드에서는 타사 호스팅 공급자를 사용해야 하는 이유를 설명합니다.

그럴만한 가치가 있어요.그들은 그것을 효율적으로 저장합니다.서버에서 클라이언트 요청 등으로 업로드되는 대역은 없습니다.

SQL Server 2008을 사용하지 않고 특정 이미지 파일을 데이터베이스에 넣어야 하는 확실한 이유가 있는 경우 "both" 접근 방식을 사용하여 파일 시스템을 임시 캐시로 사용하고 데이터베이스를 마스터 리포지토리로 사용할 수 있습니다.

예를 들어 비즈니스 로직은 이미지 파일을 제공하기 전에 디스크에 존재하는지 확인하고 필요할 때 데이터베이스에서 검색할 수 있습니다.이렇게 하면 여러 웹 서버의 기능을 이용할 수 있고 동기화 문제가 적을 수 있습니다.

이것이 얼마나 "현실 세계"의 예인지는 잘 모르겠지만, 저는 현재 트레이딩 카드 게임을 위한 상세한 정보를 저장하는 어플리케이션을 가지고 있습니다. 카드의 이미지를 포함해서 말이죠.데이터베이스에 대한 기록 수가 현재까지 2851개의 기록에 불과하다는 것을 인정받았지만, 특정 카드가 여러 번 출시되고 대체 예술품을 가지고 있다는 사실을 고려하면,실제로 작품의 "기본 사각형"을 스캔한 후 요청 시 카드의 테두리와 기타 효과를 동적으로 생성하는 것이 더 효율적이었습니다.

이 이미지 라이브러리의 원래 작성자는 요청에 따라 이미지를 렌더링하는 데이터 액세스 클래스를 만들었고, 이 클래스는 보기 및 개별 카드를 위해 매우 빠르게 수행됩니다.

이렇게 하면 새 카드가 출시될 때 배포/업데이트가 쉬워지기 때문에 이미지의 전체 폴더를 압축하여 파이프 아래로 보내고 적절한 폴더 구조가 만들어지도록 하는 대신 데이터베이스를 업데이트하고 사용자에게 다시 다운로드하게 할 수 있습니다.이 크기는 현재 최대 56MB로 좋지는 않지만 향후 출시를 위해 증분 업데이트 기능을 작업하고 있습니다.또한, 전화 접속자가 다운로드 지연 없이 애플리케이션을 받을 수 있도록 하는 "이미지 없음" 버전의 애플리케이션이 있습니다.

애플리케이션 자체가 데스크톱의 단일 인스턴스로 대상화되었기 때문에 이 솔루션은 현재까지 효과적으로 작동했습니다.이 모든 데이터가 온라인 액세스를 위해 보관되는 웹 사이트가 있지만, 이를 위해 동일한 솔루션을 사용하지는 않을 것입니다.파일 액세스는 이미지에 대한 요청 빈도와 볼륨으로 더 잘 확장될 수 있기 때문에 바람직합니다.

이것이 너무 허튼소리가 아니기를 바라지만, 저는 이 주제를 보고 비교적 성공적인 중소규모 애플리케이션에서 얻은 통찰력을 제공하고 싶었습니다.

SQL Server 2008은 파일 스트림 데이터 유형이라는 두 가지 장점을 모두 갖춘 솔루션을 제공합니다.

일반 테이블처럼 관리하고 파일 시스템의 성능을 갖습니다.

저장할 이미지의 개수와 크기에 따라 달라집니다.저는 과거에 이미지를 저장하기 위해 데이터베이스를 사용한 적이 있으며 경험이 꽤 좋습니다.

IMO, 이미지를 저장하기 위해 데이터베이스를 사용하는 것에 대한 장점은,

를 고정하기 이미지를 유지하기 위해 FS 구조가 필요하지 않습니다.
더할 때 인덱스는 이 뛰어납니다. B 더 많은 항목을 저장해야 할 경우 FS 트리보다 데이터베이스 인덱스 성능이 뛰어납니다.
를 캐싱하는 데 을 발휘합니다. 현명하게 조정된 데이터베이스는 질의 결과를 캐싱하는 데 탁월한 성능을 발휘합니다.
D. 백업은 간단합니다.또한 복제가 설정되어 있고 사용자에게 가까운 서버에서 내용이 전달되는 경우에도 잘 작동합니다.이러한 경우에는 명시적인 동기화가 필요하지 않습니다.

이미지가 작아질 경우(예: 64k), db의 스토리지 엔진이 인라인(기록상) BLOB를 지원하는 경우에는 간접적인 작업이 필요 없기 때문에 성능이 더욱 향상됩니다(Locality of reference 달성).

이미지를 저장하는 것은 작은 수의 거대한 이미지를 다룰 때 좋지 않은 생각일 수 있습니다.이미지를 db에 저장할 때 또 다른 문제는 생성, 수정 날짜와 같은 메타데이터를 응용 프로그램에서 처리해야 한다는 것입니다.

최근에 PDF/Word 파일을 MySQL 테이블에 저장하는 PHP/MySQL 앱을 만들었습니다(지금까지 파일당 최대 40MB).

장점:

• 업로드된 파일은 다른 모든 것과 함께 백업 서버에 복제되므로 별도의 백업 전략이 필요하지 않습니다(마음의 평화).
• 업로드/폴더가 필요 없고 모든 애플리케이션에 웹 서버가 어디에 있는지 알려줄 필요가 없기 때문에 웹 서버를 설정하는 것이 조금 더 간단합니다.
• 트랜잭션을 편집에 사용하여 데이터 무결성을 개선할 수 있으므로 고아 파일이나 누락 파일에 대해 걱정할 필요가 없습니다.

단점:

• 내 sqdump는 이제 테이블 중 하나에 500MB의 파일 데이터가 있기 때문에 시간이 오래 걸립니다.
• 파일 시스템과 비교했을 때 전반적으로 메모리/CPU 효율성이 떨어짐

저는 제 구현이 성공적이라고 생각합니다. 이는 백업 요구사항을 처리하고 프로젝트의 레이아웃을 단순화하기 때문입니다.그 성능은 앱을 사용하는 20-30명에게 좋습니다.

데이터베이스에 저장된 이미지와 DB에 저장된 경로가 있는 파일 시스템의 이미지 두 가지 상황을 모두 관리해야 했습니다.

첫 번째 솔루션인 데이터베이스의 이미지는 데이터 액세스 계층에서 데이터베이스 개체만 다루면 되기 때문에 다소 "깨끗"하지만, 이는 낮은 수를 다루어야 할 때만 유용합니다.

분명히 이진 대용량 개체를 처리할 때 데이터베이스 액세스 성능이 저하되고 데이터베이스 차원이 크게 증가하여 다시 성능이 저하됩니다.일반적으로 데이터베이스 공간은 파일 시스템 공간보다 훨씬 더 비쌉니다.

반면 파일 시스템에 큰 이진 개체가 저장되면 데이터베이스와 파일 시스템을 모두 고려해야 하는 백업 계획을 갖게 되며, 일부 시스템에서는 이 문제가 발생할 수 있습니다.

파일 시스템을 사용해야 하는 또 다른 이유는 이미지 데이터(또는 소리, 비디오 등)를 타사 액세스와 공유해야 하는 경우입니다. 요즘 저는 바이너리 데이터를 검색하기 위해 데이터베이스 액세스가 불가능하도록 웹 팜의 "외부"에서 액세스해야 하는 이미지를 사용하는 웹 앱을 개발하고 있습니다.그래서 때로는 선택의 폭을 넓히는 디자인 고려 사항도 있습니다.

또한 이진 개체에 액세스할 때 사용 권한 및 인증을 처리해야 하는 경우 이러한 요구 사항을 고려하십시오. 일반적으로 데이터를 db에 저장할 때 이러한 요구 사항을 보다 쉽게 해결할 수 있습니다.

저는 이미지 프로세싱 어플리케이션을 작업한 적이 있습니다.업로드된 이미지를 /images/[오늘 날짜]/[id number]와 같은 디렉토리에 저장했습니다.그러나 우리는 또한 이미지에서 메타데이터(exif 데이터)를 추출하여 타임스탬프 등과 함께 데이터베이스에 저장했습니다.

이전 프로젝트에서는 이미지를 파일 시스템에 저장했는데 백업, 복제 및 파일 시스템이 데이터베이스와 동기화되지 않아 많은 문제가 발생했습니다.

최근 프로젝트에서는 이미지를 데이터베이스에 저장하고 파일 시스템에 캐싱하고 있는데, 정말 잘 작동합니다.저는 지금까지 아무 문제가 없었습니다.

두 번째로 파일 경로에 대한 권장 사항입니다.저는 대규모 자산 수집을 관리해야 하는 몇 가지 프로젝트를 수행했는데, DB에 직접 저장하려는 시도는 장기적으로 고통과 좌절을 초래했습니다.

DB에 저장하는 것과 관련하여 제가 생각할 수 있는 유일한 실질적인 "프로"는 개별 이미지 자산을 쉽게 사용할 수 있는 가능성입니다.사용할 파일 경로가 없고 모든 이미지가 DB에서 바로 스트리밍되는 경우 사용자가 접근하지 말아야 할 파일을 찾을 위험이 없습니다.

그러나 웹 액세스 불가능한 파일 저장소에서 데이터를 가져오는 중개 스크립트로 해결하는 것이 더 나을 것으로 보입니다.따라서 DB 스토리지는 실제로 필요하지 않습니다.

데이터베이스 공급업체가 아닌 이상(Microsoft가 SQL Server에 수많은 이미지를 저장하는 Terraserver를 자랑하는 것과 같이) 데이터베이스를 사용할 수 있다는 것을 입증하는 것은 그다지 좋은 생각이 아닙니다.파일 서버와 데이터베이스의 경로에 이미지를 저장하는 것이 훨씬 간편한데, 굳이 신경 쓸 일이 있겠습니까?블롭 필드는 SUV의 오프로드 기능과 유사합니다. 대부분의 사람들이 블롭 필드를 사용하지 않고, 보통 문제가 발생하는 사람들이 있고, 그런 사람들도 있지만, 단지 재미를 위해서만 사용합니다.

이미지를 데이터베이스에 저장한다는 것은 이미지 데이터가 파일 시스템의 어딘가에서 끝나지만 직접 액세스할 수 없도록 가려진다는 것을 의미합니다.

+ves:

• 데이터베이스 무결성
• 이미지를 추가하거나 삭제할 때 파일 시스템의 동기화를 걱정할 필요가 없기 때문에 관리가 쉽습니다.

-ves:

• 성능 패널티 -- 데이터베이스 조회는 일반적으로 파일 시스템 조회보다 느립니다.
• 이미지를 직접 편집할 수 없습니다(crop, 크기 조정).

두 방법 모두 일반적이고 실행 가능합니다.장점과 단점을 살펴보세요.어느 쪽이든 단점을 극복할 방법을 고민해야 할 것입니다.데이터베이스에 저장한다는 것은 일반적으로 데이터베이스 매개변수를 조정하고 일종의 캐싱을 구현한다는 것을 의미합니다.파일 시스템을 사용하려면 파일 시스템+데이터베이스를 동기화할 수 있는 방법을 찾아야 합니다.

언급URL : https://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay