2

현재 제품 이미지, 사용자 프로필 사진, 로고 등 다양한 유형의 이미지가있는 제품에서 작업하고 있습니다. 쿼리 성능이 좋은 데이터베이스가 필요합니다.MySQL 데이터베이스 디자인 - 이미지 저장 - 단일 테이블 또는 다중 테이블

두 DB 디자인을 염두에두고 있습니다.

옵션 1 - I가 단일 ImageModel 파일을 사용할 수 있습니다

  1. ID, 제목, url_full, url_thumb, 상태 및 타임 스탬프 필드가 하나의 테이블

    장점에있는 모든 이미지를 저장 삭제/업데이트 데이터를 삽입하십시오. 따라서 이미지 저장을위한 다중 논리가 존재하지 않습니다. 이것은 하나의 로직 인 "단일 테이블에 저장"입니다. 이미지가 저장 될 때마다 그래서, 제품 이미지 및 더 적은 사용자 이미지의 많은이있는 경우

단점

  1. , 사용자 이미지 질의 인해 느려질 것
  2. ImageModel의 방법을 호출 할 수 있습니다 엄청난 수의 제품에 이르기까지.

OPTION 2 - 아이디, 제목, url_full, url_thumb, 상태 및 타임 스탬프 필드와 다른 테이블에서 이미지의 다른 유형을 저장

장점

    기록
  1. 수 증가 한 섹션에서 다른 쿼리 속도에 영향을주지 않습니다.

단점

  1. 각 이미지 유형에 대한 별도의 모델 파일/함수를 작성해야한다.
  2. 이미지를 저장해야 할 때마다 유형을 지정해야합니다.

제 질문은 더 나은 접근 방법입니다. 장점과 단점은 실제 관심사입니다. 또한 다른 장점/단점이 있다면 목록을주십시오. 또는 다른 god db 디자인이 있다면 제안하십시오.

많은 제품과 사용자가있는 실제 시나리오를 기준으로 답하십시오.

+0

"좋은 쿼리 성능"- 쿼리를 표시하십시오; 그들 없이는 우리는 당신을 도울 수 없습니다. –

+0

이미지의 일반적인 크기는 얼마입니까? 우리가 킬로바이트를 말한다면, 한 가지 대답이 더 낫습니다. 메가 바이트 다음에 다른 것이 좋습니다. –

답변

3

이것은 긴 주석으로 시작되어 답변으로 게시하기로 결정했습니다. 다른 테이블에 다른 유형의 이미지를 저장하는 것은 나에게 나쁜 생각처럼 들립니다. 예를 들어 새로운 유형의 카테고리가 나중에 표시되는 경우 디자인의 규모가 어떻게 변할 것인가? 그러면 임의의 수의 새로운 이미지 테이블을 추가하는 것에 대처할 수 있습니까? 또한 모든 이미지를 쿼리하려면 비용이 많이 소요될 수있는 일련의 조인 또는 유니온이 필요합니다.

당신은 멀티 이미지 테이블 스키마에 다음과 같은 이점을 언급 :

이미지를 하나의 이미지를 사용하는 경우 하나 개의 섹션에있는 레코드의 수는 다른

의 쿼리 속도에 영향을주지 않습니다 증가 테이블에서 인덱스가 type 컬럼에 있으면, 한 유형의 레코드 수를 늘리더라도 반드시 두 번째 유형의 이미지에 대한 u 리가 증가하지는 않습니다. 그리고 당신이 준 단일 이미지 테이블의 단점은 다음과 같습니다.

제품 이미지가 많고 사용자 이미지가 적을 경우 많은 수의 제품으로 인해 사용자 이미지 쿼리가 느려집니다.

많은 레코드를 추가하면 일반적으로 쿼리 속도가 느려집니다. 그러나 형식에 적절한 인덱스를 지정하면이 문제가 크게 줄어 듭니다.

적절한 색인이있는 단일 이미지 테이블이 훨씬 더 좋습니다.

+0

감사합니다. 사실 나는 팀의 다른 건축가의 제안에서 혼란 스러웠다. 희망 구조가 아마도 최선일 것이라고 희망한다. –

+1

sepearate 테이블에 이미지를 저장하는 것이 한 가지 시나리오는 테이블이 너무 큽니다. 수백만 건 이상의 기록. 그러나 그때조차도, 당신은 단일 테이블 모델을 sharding하고있을뿐입니다. –

+0

우리의 응용 프로그램은 2 백만 명의 사용자를 목표로하고 있습니다. 처음에는 시간이 지나면 확장 될 수있는 약 75000 개의 제품이 있습니다 .. –

-2

어떻게 이미지를 제공하겠습니까? <img src=http:...>을 경유하는 경우에는 단 하나의 대답, 즉 별개의 파일이 있습니다.

예, 축소판은 base64로 변환하고 img 태그에 포함하는 것과 같은 다른 메커니즘으로 수행 할 수 있습니다. 이 일 수 있습니다. 페이지에 미리보기 이미지가 많은 경우에 가장 적합 할 수 있습니다.

그러나 쿼리하는 열과 동일한 테이블의 축소판을 사용하면 성능이 저하 될 수 있습니다. 따라서 우리는 쿼리와 테이블 스키마를보아야합니다 (지금까지와 마찬가지로).