Joshua Bloch의 Effective Java의 항목 중 하나는 클래스가 인스턴스를 가능한 한 적게, 바람직하게는 전혀 허용하지 않아야한다는 개념입니다.
종종 개체의 데이터는 어떤 형태의 데이터베이스에 유지됩니다. 이로 인해 데이터베이스 내에서 불변성의 아이디어, 특히 더 큰 시스템 내에서 단일 엔티티를 나타내는 테이블의 아이디어를 생각하게되었습니다.
내가 최근에 실험 한 것은 이러한 객체를 나타내는 행을 테이블에 업데이트하는 것을 최소화하려고 시도하고 가능한 한 많이 삽입을 시도하는 것입니다.
내가 최근에 실험하고 있었던 것의 구체적인 예. 나중에 추가 데이터가 포함 된 레코드를 추가 할 수 있다는 것을 알고 있으면 다음 두 테이블 정의와 같이이를 나타내는 다른 테이블을 만듭니다.
create table myObj (id integer, ...other_data... not null);
create table myObjSuppliment (id integer, myObjId integer, ...more_data... not null);
이 이름들이 구두가 아니라 단지 그 아이디어를 보여주기위한 것이 분명하다.
이것이 데이터 지속성 모델링에 대한 합리적인 접근입니까? 테이블에서 수행되는 업데이트, 특히 레코드가 처음 만들어 졌을 때 존재하지 않을 수있는 데이터에 대해 null을 채우는 것을 제한 할 가치가 있습니까? 이와 같은 접근법이 나중에 심각한 통증을 유발할 수있는 경우가 있습니까?
7
문제가없는 솔루션 인 것 같습니다 ... 업데이트를 피하기 위해 정교한 조정을 만드는 대신 업데이트해야합니다.
—
Fosco
솔루션에 대한 직관적 인 아이디어를 염두에두고 가능한 한 많은 사람들이이 솔루션을 실행하기를 원하고 이것이 내가 가진 문제에 대한 최상의 솔루션이 아닐 수 있다는 것을 깨닫는 것이 문제라고 생각합니다. 다른 곳에서 찾을 수 없다면 문제에 대해 다른 질문을 열 수 있습니다.
—
Ed Carrel
데이터베이스에서 업데이트를 피해야 할 이유가있을 수 있습니다. 그러나 이러한 이유가 발생하면 이는 최적화 문제 일 뿐이므로 문제가 있다는 증거 없이는 수행해서는 안됩니다.
—
dietbuddha
데이터베이스 내에서 불변성에 대한 강력한 주장이 있다고 생각합니다. 많은 문제를 해결합니다. 나는 부정적인 의견이 열린 사람들로부터 온 것이 아니라고 생각합니다. 전체 업데이트는 많은 문제의 원인입니다. 나는 우리가 모든 것을 거꾸로 가지고 있다고 주장 할 것이다. 전체 업데이트는 더 이상 존재하지 않는 문제에 대한 레거시 솔루션입니다. 저장은 싸다. 왜 그렇습니까? 버전 관리 시스템 인 감사 로그가있는 DB 시스템의 수는 분산 복제가 필요하며, 확장 복제에 대한 대기 시간을 지원하는 기능이 필요합니다. 불변성은이 모든 것을 해결합니다.
—
cirrus
@Fosco 일부 시스템은 데이터를 절대로 삭제하지 않아야합니다 (을 사용하여 포함
—
이즈 카타
UPDATE). 의사의 의료 기록처럼.