2
그래서 나는이 nightmere (RDBMS) 있습니다. 나는 여기서 많은 질문을했지만 아무도 대답하지 못했다. rdbms에서 oo 개념을 모방하는 것에 대해 대답하지 않았다 ...전체 데이터베이스 무결성 (5 배 더 많은 테이블) 대 rdbms에 oo 개념을 모방 한 대
많은 웹 사이트 (포럼, 소셜 네트워크 등)에는 게시 된 내용에 대한 많은 기능이있다.
그들은, 의견을 가질 수는
을 엔티티 :
나는 갈 수 ... 갈 어떤 방법을 결정하기 어려운 pritty입니다 (같은 단지 별과 의견을 말할 수) 각 게시물의 유형을 입력하십시오 (이 엔티티 ID는 각 게시 테이블에서 참조되며 기능은 엔티티 ID도 참조합니다). 또한 엔티티 유형이 무결성 트리거를 만들기 위해 필요합니다. 예를 들어 주석 엔티티는 같은 기능을 가질 수 있지만 주석 기능은 가질 수 없습니다. 게시물에 더 많은 기능을 추가해야하는 경우이 엔티티 유형 필드는 악몽입니다 (일부 새 엔티티 유형을 추가해야합니다). 그리고 이것은 단순히 데이터 무결성을 엉망으로 만듭니다.또는 5 배 이상 db 테이블. 이 말은 모든 단일 유형의 게시 테이블에 대한 기능 테이블을 디자인하는 것을 의미합니다. 더 많은 조인, 긴 쿼리가 필요하지만 적어도 데이터 무결성이나 확장성에 문제가 없다는 것을 알고 있습니다.
나는 rdbms를 사용해야하며 oodbms 방식이나 그래프 db 방식으로 갈 수 없습니다.
두 가지 유형의 디자인 중에서 무엇을 선택하겠습니까? 아니면 어떻게하면 좋을까요?
(특히 NULL 고유성의 TSQL 깨진 핸들링 : - /). 나는 "템플릿"또는 "mixin"RDBMS가 있었으면 좋겠다. Grrr. 즉, 많은 OOM이 "전통적인"RDBMS에 매핑 될 수 있으므로 "OOM을 포기할 필요가 없습니다"또는 계층 구조가 필요합니다. DB 수준의 무결성은 흥미로운 부분입니다. –
@pst orm은 제약 조건에 대한 트리거를 어떻게 구축할까요? (하드 코딩 된 제약 조건 트리거를 생성하는 PHP orm은 보지 못했습니다.) 저는 정말로 orms에 있지 않습니다. (PHP orms) – Tudor
@pst orms가 자동으로 다형성 연관과 rdbms 문제를 해결할 것이라고 생각하지 않습니다. – Tudor