관계형 데이터베이스에서 싱글 톤을 모델링하는 가장 좋은 방법


12

웹 응용 프로그램을위한 관계형 데이터베이스 스키마를 설계 할 때 종종 하나의 행과 하나의 행만 포함하는 테이블을 만드는 경우가 종종 있습니다. 그것이 그것을 설계하는 잘못된 방법 인 것 같은 느낌이 들지만, 나는 훨씬 더 나은 것을 생각 해낼 수 없거나, 분명히 "올바른 방법"입니다.

최근 예는 사용자가 홈 페이지의 컨텐츠를 수동으로 제어 할 수있는 사이트입니다. 홈 페이지는 하나뿐입니다. 설명 텍스트가 포함 된 영역의 텍스트 필드와 같이 홈페이지를 구축하는 데 필요한 모든 필드가있는 테이블을 만들었습니다. 큰 이미지 파일의 이름을 저장하는 필드입니다. 홈페이지에 소개 될 기사를 가리키는 일부 외래 키. 작동하지만 한 행만있는 테이블을 갖는 것은 잘못된 느낌입니다.

과거에는 홈페이지 테이블에 여러 행을 허용하고 무작위로 하나를 선택하는 것과 같은 다른 많은 디자인을 시도했습니다. "active"라는 부울 필드를 추가하고 활성 홈페이지 중 하나를 임의로 선택하려고했습니다. 주어진 시간에 응용 프로그램 논리에서 하나의 행만 활성화하려고했습니다. 홈페이지 테이블을 만들지 않고 기사와 같은 다른 모든 항목을 가져와 feature_on_homepage와 같은 이름을 가진 부울 필드를 갖도록 시도했습니다.

대부분의 경우 설정 파일에 상수가 많은 홈페이지를 만들 수있었습니다. 설정 파일의 주요 문제점은 개발자가 제어 할 수 있다는 것입니다. 홈페이지의 내용과 같은 내용은 사용자가 편집해야하는 내용이므로 데이터베이스로 이동해야합니다.

많은 사이트에서 5 개의 최신 기사를 선택하는 것과 같은 쿼리로 홈페이지와 같은 것을 만들 수 있기 때문에이 문제가 없습니다. 그러나 엄격한 요구 사항으로 수동으로 선별 된 페이지가 있으면 데이터베이스에서 모델링하기가 까다로워집니다. 그러나 사진 테이블과 기사 테이블이 있다고 가정하십시오. 요구 사항은 홈페이지가 정확히 5 장의 사진, 정확히 3 개의 기사 및 사용자가 수동으로 제어하는 ​​2 개의 임의의 텍스트 블록을 표시해야한다는 것입니다. 데이터베이스에서 올바른 방법으로 모델링하는 방법은 무엇입니까?

또한 홈페이지 이외의 다른 많은 경우 에이 모델링 문제가 있습니다. 내가 생각해 낼 수있는 가장 쉽고 가장 일반적으로 적용 가능한 예입니다.


단일 행 테이블이 어떤 식으로 테이블의 낭비를 나타내는 것 외에는 어떤 문제가 있는지 분명하지 않습니다. 실제로 겪고있는 문제를 해결하려고하십니까?
David Aldridge

답변:


10

간단한 방법 중 하나는 홈 페이지 속성을 이름 및 값 열로 구성된 속성 테이블에 저장하거나 다른 이름으로 호출하는 것입니다.

HomePageProperty1-UserValue1

HomePageProperty2-UserValue2

이상적인 솔루션은 아니지만 간단하고 유연합니다. 또한 하나의 행 시나리오로 테이블을 제거합니다.


1
이 방법은 여러 가지 목적으로 작동합니다. 예를 들어, 스키마 버전 정보, 매일 순환해야하는 것들에 대한 회전 포인터 등을 저장합니다. 스키마 버전 정보는 무엇이 잘못되었는지 진단 할 때 중요합니다. 데이터베이스 전용 수정에 패치가 적용되도록하는 합리적인 방법입니다.
Berin Loritsch

2
+1-이것은 데이터 아키텍트가 비슷한 목적으로 나에게 준 정확한 테이블 레이아웃입니다.
Ali

3
이 접근 방식의 문제점은 다른 변수 유형을 다른 열로 나타내야하며 사용할 열과 필수 열을 알려주는 논리가 필요하다는 것입니다. 부울 값이 부울이거나 날짜가 날짜이거나 특정 속성이 널 (null) 일 수 없거나 특정 범위에 속하거나 조건을 충족해야한다는 것을 정의 할 수는 없습니다. 단일 행 테이블로.
David Aldridge

3

해결해야 할 문제가 있다는 것이 확실하지 않습니다.

단일 행 테이블은 데이터베이스 자체에 전혀 문제가되지 않으며 데이터 유형 및 제한 조건을 데이터에 적용 할 수 있습니다.

솔직히 말해서 당신이 진짜 문제를 해결하려고 노력하고 있는지 잘 모르겠습니다.


2

실제로 파일로 저장 해야하는 데이터베이스를 사용하고있는 것 같습니다.

귀하의 설명은 사용자가 컨텐츠를 편집 할 수있는 많은 Wiki 페이지를 상기시킵니다. Wikis 또는 적어도 내가 본 구현에서는 페이지가 파일로 유지됩니다.

이를 통해 사용자가 홈페이지를 캐시 할 수 있도록하는 등의 웹 세부 정보를 확인할 수 있습니다. 페이지를 파일로 저장하면 실제로 무료로 제공되지만 데이터베이스에 저장된 컨텐츠를 기반으로 모든 요청에 ​​대한 페이지.

어쨌든 대부분의 응용 프로그램의 영구 데이터가 데이터베이스에 저장되어 있지만 모든 것을 저장해야한다는 의미는 아닙니다. 데이터베이스는 우리 무역의 도구 중 하나 일뿐입니다. 우리는 가능한 많은 도구를 잘 활용하는 법을 배워야합니다.


2

하나의 행이있는 테이블에는 아무런 문제가 없습니다.

이것이 디자인의 일부인 경우 시행해야합니다. 테이블에 식별 컬럼을 제공하고 고유 제한 조건을 지정한 다음 단일 값만 허용하도록 컬럼 제한 조건을 추가하십시오. 이렇게하면 아무도 두 번째 행을 추가 할 수 없으므로 테이블을 읽는 SQL 문에 where 절이없는 경우 치명적일 수 있습니다.

많은 수의 열을 얻기 시작하면 테이블을 좁히고 구성 항목 당 하나의 행을 갖도록 유혹 할 수 있습니다. 타입 안전과 검증을 잃어 버리기 때문에 이것은 최선의 아이디어가 아닙니다. 또한 다중 테넌시 와의 호환성을 잃게 되므로 중요 할 수 있습니다. 더 나은 솔루션은 엔티티가 실제로 무엇인지 다시 생각하고 엔티티마다 별도의 단일 행 테이블을 갖는 것입니다.

그렇습니다. 단일 행 테이블이 정상이라고 말하는 것이 아니라 둘 이상의 테이블을 원할 수도 있습니다.


1

STATIC_CONTENT라는 테이블을 작성하고 키, 컨텐츠, 활성 / 비활성 추적기 등의 열을 가질 수 있습니다. 그런 다음 "HomePage"키를 사용하여 행을 작성하고 홈페이지에서 해당 키의 정적 컨텐츠를로드하십시오. 표시합니다. 이렇게하면 다른 정적 컨텐츠 (페이지, 연락처 페이지 등)가있는 경우 해당 테이블에 행을 추가 할 수 있습니다.


1

단 하나의 행만있는 테이블을 갖는 것 자체로는 잘못된 것이 없습니다. 특정 엔티티의 인스턴스가 하나만있는 경우이를 나타내는 가장 자연스러운 방법 일 수 있습니다.

그러나 무작위 로 행 선택하는 것은 잘못과 잘못입니다. 도메인 논리에 단일 행만 필요한 경우 실제로 더 많은 행이 있으면 데이터에 오류가있는 것입니다. 따라서 데이터베이스에 유효하지 않은 데이터를 기록하는 사람 또는 대상을 파악하여 그렇게하지 못하게해야합니다! 데이터베이스에 따라 테이블에 제약 조건을 추가하여 처음에는 이런 일이 발생하지 않도록 할 수 있습니다 (예 : 기본 키로 특정 값만 허용).


0

Walter에 추가하기 만하면됩니다 ..

특성 테이블 구조는 여러 데이터 유형을 허용해야합니다.

Fileds:
PropertyName
PropertyTextValue
PropertyDateValue
PropertyNumericValue
PropertyBoolValue

이를 통해 행당 하나의 속성 값만 설정되도록 어떻게 보장합니까? 응용 프로그램에서 적용하기는 쉽지만 누군가가 데이터베이스를 수동으로 업데이트하고 거기에 일부 데이터를 넣는 경우 어떻게해야합니까?
Apreche

0

한 단계 더 추상화 할 수있을 것 같습니다. 결국 "홈페이지"는 "페이지"입니다. 필요한 속성을 가진 다른 유형의 페이지를 가질 수 있습니다. 사이트에 섹션이있는 경우 "홈 페이지"와 동일하게 작동하는 "SectionHomePage"가 필요할 수 있습니다.

요구 사항은 홈페이지가 정확히 5 장의 사진, 정확히 3 개의 기사 및 사용자가 수동으로 제어하는 ​​2 개의 임의의 텍스트 블록을 표시해야한다는 것입니다. 데이터베이스에서 올바른 방법으로 모델링하는 방법은 무엇입니까?

이렇게 해보자. ArticlePage 테이블을 추가하여 그에 따라 속성을 분리하는 방법을 알 수 있습니다.

PAGES
Id
Title
Description

HOMEPAGES
PageId (FK)
PhotoListLimit
ArticleListLimit
TextBlockListLimit

ARTICLEPAGE
PageId (FK)
ArticleMainQuote
ArticleMainBody
ArticlePhoto1
ArticlePhoto2

그것은 나를 위해 잘 작동하고 심지어 큰 사이트를 위해 잘 작동 할 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.