2012-01-16 4 views
4

내가 묻는 이유는 MySQL이 현재 지원하지 않는 특정 CHECK 제약 조건을 사용하기 위해서입니다. 이러한 유형의 제약 조건이 없으면 응용 프로그램 코드가 데이터베이스의 책임을 더 많이 차지하므로 외래 키와 참조 무결성을 사용하는 모든 이유가 줄어들 것입니다.MySQL을 '멍청한'데이터 저장소가 아닌 다른 용도로 사용하면 어떤 이점이 있습니까?

'무언가'데이터 모델을 만들고 참조 무결성 검사를 모두 응용 프로그램 코드의 한 계층으로 이동하면 참조 무결성 오류가 응용 프로그램 코드에서가 아니라 응용 프로그램에 트래핑되므로 테스트가 잠재적으로 간단해질 수 있습니다. db. 또한 테스트 전에 새로운 모듈이 반드시 완성 될 필요가 없으므로 잠재적으로 새로운 모듈의 개발 속도를 높일 수 있습니다.

그래서 MySQL에서 '적절한'데이터 모델을 고수하고 외래 키와 'ON UPDATE CASCADE'문 등을 유지하는 다른 이점이 있습니까?

아니면 우리가 MySQL을 도려내고 뭔가 다른 것으로 옮겨야합니까?!

감사합니다.

+1

나는 무결성이 유효성 제약 조건과 약간 다르다고 생각합니다. – newtover

+0

@newtover 물론 그들은 다릅니다. 우리는 검증을 할 수 없을 때 RI를 사용하는 이점을 보지 못했지만, 응용 프로그램에 모두 포함되어 있다면 둘 다 가질 수 있습니다 ... – Bendos

+1

당신이 저지른 경우 (맥주처럼) 소프트웨어를 사용하는 것과 관련하여 [PostgreSQL] (http://www.postgresql.org/docs/8.1/static/ddl-constraints.html)을 고려해 보셨습니까? –

답변

7

일부 개발자는 데이터베이스에서 비즈니스 논리가 전혀 없다고 주장합니다. 즉, 바보 데이터 저장소입니다. 그래서 이것은 분명히 유효한 전략입니다.

제약 조건 (및 기타 비즈니스 논리)을 데이터베이스에서 옮기는 것에 대한 우려는 모든 곳에서 제약 조건을 적용하는 것이 더 어렵다는 것입니다. 모든 단일 응용 프로그램의 모든 단일 개발자가 해당 제약 조건을 위반할 수 있습니다. DBA는 도울 수 없습니다.

그래서 데이터베이스 자체에 이러한 규칙이 적용됩니다.

+7

Tom Kyte (Oracle Expert)는 "* 응용 프로그램이 유일한 것이 아니며 해당 데이터를 사용할 마지막 것이 아닙니다 *"(해당 데이터가 중요 할 경우) –

+0

고맙습니다 @ DOK, 네 말이 맞아,하지만 DBA가 개발자 들과는 다른 사람들이라고 생각 하는게 일반적 일거야. 내 경험에 의하면 (솔직히 말해서 작은 프로젝트에서!) 그들은 똑같은 사람이어서 데이터베이스를 응용 프로그램과 같이 망칠 수 있습니다. – Bendos

0

예, MySQL에서 지원하지 않는 기능이 필요한 경우 다른 것으로 이동할 수 있습니다.

2

단일 행 테이블의

  • 단일 값 열거
  • 그것은 불편,하지만 마지막에 트리거

  • FK 다른 방법

    • 의 점검 제한 조건을 에뮬레이션 할 수 있습니다 세계.

      어쨌든 응용 프로그램에서 모든 제약 조건을 수행 할 수 있거나 수행해야하는 것은 아닙니다. 독창성? 제로섬 점검 (예 : 계정이 비활성화되기 전에 잔액 = 0).

      잘못되었을 때 정리할 데이터와 정리가 ...

  • +0

    안녕하세요. @ gbn, 귀하의 의견에 감사드립니다. 일부 유효성 검사에는 트리거를 사용하는 것이 고려되었지만 실제 CHECK와 비교할 때 항상 고려 사항처럼 보였습니다. DB가 자체적 인 무결성을 유지하지 못한다면 고아 레코드, 업데이트 변형 등의 위험을인지하고 있지만 완전히 제거하는 것은 아닙니다. 단지 다른 레이어로 이동하는 것입니다. DOK에 대한 언급에서 언급했듯이 DBA는 개발자이기 때문에 사용하는 메커니즘이 엉망입니다. – Bendos

    관련 문제