refactor: 문서 개선 중

2026-09-21 14:30:55 +09:00
parent c93cdea150
commit 805a18f486
1497 changed files with 525837 additions and 59152 deletions
@@ -35,25 +35,17 @@ source:

 고정 문구를 두는 이유는 예외의 원문 메시지에 저장소 제약 이름이나 SQL 조각이 섞일 수 있어서다. 그 판단은 서버 쪽 클래스의 javadoc 에 적혀 있다.

-참조 검사는 다섯 표를 하나의 존재 검사로 묶는다.
-
-sql
-SELECT 1 FROM document_relation        WHERE target_document_id = :id
-UNION ALL SELECT 1 FROM question_document_link  WHERE document_id = :id
-UNION ALL SELECT 1 FROM project_document_link   WHERE document_id = :id
-UNION ALL SELECT 1 FROM topic_featured_document WHERE document_id = :id
-UNION ALL SELECT 1 FROM project_decision        WHERE source_case_id = :id
-
+참조 검사는 다섯 표를 하나의 존재 검사로 묶는다. 실제 SQL은 이 기록의 근거인 `final/document.md` §16.1에 정상 SQL 코드 블록으로 남겨 두었다.

 같은 어댑터의 질문 삭제는 참조가 둘뿐이라 같은 문제가 덜하다 — project_question_link 와 home_focus_config.open_question_id 다.

-실제 사례에서 관계를 다 지워도 삭제가 안 됐다. 남아 있던 것은 프로젝트 링크 한 행이었고, 그 링크는 「관계」 편집기가 아니라 문서의 Project 필드가 만든다.
+실제 사례에서 Studio의 「관계」 편집기로 만든 연결을 다 지워도 삭제가 안 됐다. 남아 있던 것은 `project_document_link` 한 행이었고, 그 링크는 「관계」 편집기가 아니라 문서의 Project 필드가 만든다.

 사용자는 Project 필드를 「미지정」으로 바꾸고 저장한 뒤 삭제했다.

 ## 가정

-문구가 「another record」라고 하니 사용자가 관계를 먼저 찾는다고 보고 있다. 실제 사례가 하나이고, 다른 사용자가 같은 순서로 움직이는지는 확인하지 않았다.
+문구가 「another record」라고 하니 사용자가 Studio의 「관계」 편집기를 먼저 확인한다고 보고 있다. 실제 사례가 하나이고, 다른 사용자가 같은 순서로 움직이는지는 확인하지 않았다.

 다섯 참조를 종류별로 갈라도 응답 시간이 문제가 되지 않는다고 보고 있다. 하나의 존재 검사를 다섯 개로 나누는 비용은 재지 않았다.

@@ -84,7 +76,7 @@ UNION ALL SELECT 1 FROM project_decision        WHERE source_case_id = :id
 문구가 코드마다 하나이므로 코드를 나누면 문구도 갈린다. 대신 계약의 열거형이 늘고 반입한 두 저장소가 함께 움직인다.

 **막는 참조를 목록으로 돌려준다**
-어느 기록이 걸었는지까지 보인다. 관계는 이름을 보일 수 있지만 프로젝트 링크와 주제 대표 기록은 다른 화면이라 이름만으로는 어디를 고칠지 알기 어렵다.
+어느 기록이 걸었는지까지 보인다. 문서 relation은 연결된 기록 이름을 보일 수 있지만 프로젝트 링크와 주제 대표 기록은 다른 화면이라 이름만으로는 어디를 고칠지 알기 어렵다.

 **문구만 고쳐 프로젝트 연결을 함께 언급한다**
 가장 싸다. 다섯 중 어느 것인지는 여전히 말하지 못하고, 사용자가 확인할 화면이 셋으로 늘어난다.