Merge remote-tracking branches 'origin/CODEX', 'origin/sub_laptop_1' and 'origin/sub_laptop_2' into sub_laptop_3

docs/raw/요구_1104/_조사_804_저장소속도.md

@@ -0,0 +1,63 @@
+# 조사 804 — 영구저장소 꼴과 속도 (요구 804 · 실측 + 코드 조사 · 결정 전)
+
+## 1. 저장 꼴(실측)
+
+| 자료 | 꼴 | 크기 |
+|---|---|---|
+| M01 기계 | 파일 하나 | 1.5 MB |
+| M01 자재 | 파일 하나(30,711 줄) | 15 MB |
+| M01 로직 · 수식 문서 | 품셈 장마다(118 파일) | 11.7 MB |
+| M02 단가산출(SK) | 항목마다 파일 | 평균 2.2 MB · 개인 층 47 건 102 MB · 마스터 층 34 건 126 MB |
+| M02 일위대가 · 사전조합 | 항목마다 파일 | 1 ~ 3 MB(같은 사본을 품음) |
+| DB(MariaDB) | 회사 · 사용자 · 프로젝트 행만 | 목록 · 색인 · 잠금은 전부 파일 |
+
+- SK 한 건 속(SK-000048): 문서 본체 2.5 천 자 · 가져온 정보 3.6 천 자 · M01 값 사본 15 만 자가 `사본` · `수식` 두 자리에 같은 내용으로 두 번 → 파일의 약 99 % 가 사본.
+- 같은 지문(단가판)의 값 묶음도 SK 마다 따로 저장(공유 없음) · 사본에는 기계 고르기 후보 줄까지 모두 들어감(177 줄).
+
+## 2. 시간(메인 서버 · 따뜻한 상태 · 읽기만 잼)
+
+| 조작 | 시간 |
+|---|---|
+| M01 기계 표 한 쪽 | 0.03 초 |
+| M01 자재 표 한 쪽 · 찾기 | 0.2 초 |
+| M01 단가산출 기초 목록 | 0.1 ~ 0.4 초 |
+| M02 SK 한 건 열기 | 0.07 초 |
+| M02 개인 층 목록(47 건) | 3.1 ~ 3.5 초 |
+
+- 쓰기 시간은 사용자 자료를 건드리게 되어 재지 않음(코드로만 확인).
+
+## 3. 느린 까닭(코드)
+
+1. 층 목록 — 판을 만들려고 SK 파일을 통째로 읽고(sha256) · 요약 때 다시 파싱 · 기준 금액 셈 때 또 파싱 → SK 한 건에 읽기 세 번 + 셈 · 요청 사이 기억 없음 · 목록용 요약 파일 없음(`M02_Template_Layers.list_templates` · `M02_Labor_Ref.summaries`).
+2. M01 저장(별칭 한 칸도) — 15 MB 파일 다시 씀 · 폴더 전체(26 MB) 두 번 읽음 · 전체 검사 두 번(모든 층 일위대가 · 사전조합 파일을 두 번 다 파싱) · 그 뒤 기억 다시 지음(`M01_MasterData_Store.save` · `Store_Cache.check_saved`).
+3. SK 저장 — M01 줄 전체 훑기(사본 모으기)를 저장 한 번에 두 번 이상 · SK 파일을 디스크에서 여러 번 다시 읽음 · 셈 반복 · 2 MB 를 들여쓰기 + fsync 로 씀(`clean_doc` → `settle` → `stamp` · `grow` → `prices.collect`).
+4. 사본 중복 — 위 1 ~ 3 의 읽기 · 쓰기 비용을 모두 키움.
+5. M01 표 읽기(`rows` · `tables` · `groups`) — 기억을 안 쓰고 요청마다 파일 파싱(지금은 0.2 초라 급하지 않음).
+
+## 4. 판단
+
+- 「층마다 한 파일」 이 아님 — M02 는 항목마다 파일이고 · 문제는 그 한 건이 사본으로 부풀어 있는 것 + 목록 · 저장이 큰 파일을 되풀이 읽고 쓰는 것.
+- 저장 꼴을 통째로 바꾸기(DB 이전)보다 아래 차례가 효과 대비 위험이 작음.
+
+| 차례 | 안 | 기대 | 위험 |
+|---|---|---|---|
+| A | 층마다 목록 요약 색인(이름 · 판 · 기준 금액 · 쓰는 곳 수 — 저장 때 갱신 · 어긋나면 다시 지음) | 층 목록 3.3 초 → 0.1 ~ 0.3 초 | 작음 |
+| B | 저장 길 줄이기 — M01 저장: 폴더 두 번 읽기 · 전체 검사 두 번을 바뀐 것만 · SK 저장: 모으기 · 다시 읽기 · 셈 한 번씩 | 저장 · 불러오기(항목 수 × 저장) 시간 | 중간 |
+| C | 사본 줄이기 — ① `사본` · `수식` 한 번만 ② 실제로 읽은 줄만 ③ 같은 지문 묶음은 한 번만 저장하고 SK 는 지문만 가리킴 | SK 2.2 MB → 수십 KB · 층 100 MB → 수 MB · 열기 · 저장 · 복사 · 시놀로지 동기화 모두 가벼워짐 | 중간(기존 파일 옮기기 · 안 쓰는 묶음 치우기 · 프로젝트 복사본) |
+| D | 목록 · 색인 · 잠금을 DB 로 | 여러 서버 · 동시 저장 안전 | 큼 · 지금 속도 문제엔 필요 없음 → 보류 |
+
+- 「만들 때 복사 · 그 뒤 연결 끊김」 원칙은 A ~ C 어느 것에서도 그대로(C ③ 의 묶음은 지문으로 굳은 사본).
+
+## 5. 사본에 든 줄의 실제 쓰임(요구 806 · SK-000048 실측)
+
+- 이 단가산출이 실제 쓰는 값 = 기계 둘(굴착기(무한궤도) 0.7㎥ · 진동롤러(자주식) 12ton) + 경유 전국평균 한 줄 + 건설기계운전사 한 줄 = 4 줄.
+- 사본에 든 값 = 177 줄: 기계 138(두 계산식의 「기계」 고르기 후보 전부 — GC000267 9 대 + GC000269 129 대 · 14.6 만 자) · 유가 36(휘발유 · 경유 × 지역 18) · 직종 3 → 173 줄(약 98 %)은 이 단가산출이 안 쓰는 값.
+- 까닭 = 사본 모으기가 「식이 고를 수 있는 후보 전부」 를 닫힌 묶음으로 박음(옵션을 바꿔도 사본 안에서 셈하려는 뜻).
+- 안 C ② 가 이것 — 실제로 읽은 줄만 박고 · 옵션 · 기계를 바꿔 새로 필요한 줄은 바꾸는 때의 M01 값으로 가져와 저장 때 박음(822-1 이 넣은 「읽은 줄을 저장 때 박기」 길 재사용).
+
+## 6. 사용자 결정(요구 808) · 진행 차례
+
+- 기계 = 항목 하나가 파일 하나(M01 기계 · 내 기계) · 자재는 한 파일 그대로 · A · B · C 진행.
+- C 는 ②(실제로 읽은 줄만)부터 — 177 줄 → 4 줄이면 ①(두 번 든 것) · ③(공유 저장)의 남는 효과가 작고 · ② 는 옛 코드가 읽어도 무해(없는 줄은 지금 M01 값으로 읽음) · ① · ③ 은 파일 꼴이 바뀌어 **데스크탑(임시 배포 · 옛 코드)이 같은 storage 를 읽는 동안**은 깨질 수 있어 전역 깃 싱크와 묶을 때만.
+- 바꿔 끼운 기계 · 옵션의 값 = 바꾸는 때의 M01 값(정함 · 브레인).
+- 걸음: 826-1 층 목록 요약(sub2 · 바로) → 826-2 M01 기계 항목별 파일 · 내 기계 항목별 파일 · M01 저장 길 줄이기(sub1 · 822-2b 뒤) → 826-3 사본 = 읽은 줄만 · SK 저장 길 줄이기(sub3 · 823-1 뒤).

docs/raw/요구_1104/사용자요구_1104.md

@@ -1041,3 +1041,38 @@ STmate 의 「굴삭기(1.0m3)은 무한궤도
 
 1. 추가 확인사항 sk-000048 항목은 내가 다른 경쟁사의 프로그램에서 가져오기 테스트를 하고 있음. 정상적으로  가져온것같고 여기서 기계를 변경했는데 산출근거의 데이터가 업데이트 안됨. 조사 시작
 2. 단가산출에서 기계의 우측에 복사해 내 기계로 항목이 있음. 복사해서 내기계로 가져갈 필요가 없어보임. 기계의 시스템 관리자를 제외한 회사관리자와 일반사용자는 에서 항목추가로 추가하는게 만들어서 하는게 어떤지. 검토 .
+
+## 요구 801 (11-12 · 사용자 · 1 그 말이 아니라 단가산출 상세 화면에서 0.7㎥ 를 1.0㎥ 로 바꿨는데 우측 산출 로직 값이 안 바뀌어 확인하라는 것 · 다시 확인 · 2 새 기계 추가의 직종 = 내용이 많아 드롭다운에 검색 필요 · 검색되면 적당히만 보여 줌 · 지정된 경우 다시 열면 선택된 항목 주변을 보여 주는 기능은 유지)
+
+1. 그말이 아니라 내가 단가산출 상세화면에 접근해서 0.7m2 을 1.0m2으로 변경해봤는데 우측 산출로직에서 값 변경이 없어서 확인하라고 한거야. 다시 확인
+2. 새 기계 추가에서 직종의 경우 내용이 많아 드롭다운 항목들 중 검색도 있어야함. 검색이 되면 많은 항목을 보여줄필요없으니 적당히만 보여주고 추가로 지금은 지정된 경우 다시 열면 선택된 항목이 주변을 보여줌. 이 기능은 유지.
+
+## 요구 802 (11-12 · 사용자 · M02 — 내 기계 · 내 품목을 「개인관리」 컨테이너로 병합 · 안에 단추 둘 · 이름 「기계」 · 「자재」 · 「구조물 조합」 컨테이너를 「일위대가」 바로 아래로)
+
+M02에서 내 기계와 내 품목은 개인관리 컨테이너로 병합함. 내부에는 2개의 버튼으로 해당페이지를 열면됨. 내 기계의 이름은 기계, 내 품목은 자재로 변경, 그리고 일위대가 바로 아래에 구조물 조합 컨테이너가 들어보게 변경
+
+## 요구 803 (11-12 · 사용자 · 내장 캐드 — 드래그하면 그리드 표현이 고정돼 있음 · 따라가는 게 맞는 것 같은데 어떻게 생각하는지)
+
+내장 캐드에서 드래그를 하면 그리드 표현이 고정되어있음. 따라가는게 맞는것같은데? 어떻게 생각함.
+
+## 요구 804 (11-12 · 사용자 · 영구저장소 데이터 형태 조사 — M01 기계 · 단가산출 기초 · M02 단가산출 · 일위대가 · 구조물 조합 · 내 기계가 마스터 · 회사 · 개인마다 각각 하나의 파일로 저장 → 불러오기 · 업데이트가 느린 것으로 판단 · 조사부터 하고 판단)
+
+다음 조사는 영구저장소의 데이터 형태에 대한 고민, 내가 보기에는 현재 영구저장소에 저장되는 M01 기계, 단가산출 기초, M02의 단가산출, 일위대가, 구조물조합, 내 기계 등이 각각 마스터, 회사, 개인 항목에 따라 각각 하나의 파일로 저장되어있어. 불러오기나 업데이트에 속도가 느린걸로 판단됨. 너의 생각은 조사부터 해보고 판단하자.
+
+## 요구 805 (11-12 · 사용자 · 내장 캐드 그리드 — 오토캐드처럼 줌 인 · 아웃에 따라 크기 · 표현되는 수를 제어 · 많이 줌 아웃해도 느려지지 않고 보기 좋게 · 확인하고 반영)
+
+내장 캐드에서 그리드 표현은 오토캐드를 참고해보면 줌인아웃에 따라 크기나 표현되는 숫자를 제어하여 효과적으로 보여줌. 그래야 많이 줌아웃하면 느려지지 않고 보기 좋을테니까. 확인해보고 반영해줘.
+
+## 요구 806 (11-12 · 사용자 · 속도 조사에서 이상한 점 — M01 정보를 사본으로 가져가는 건 좋은데 상관없는 내용도 같이 갖고 있는 것 아닌지)
+
+나는 너가해준 속도 느림에서 이상하다고 느낀 부분이 M01의 정보를 사본으로 가져가는건 좋은데 내가 보기에는 상관없는 내용도 같이 가지고 있는거 아니야?
+
+## 요구 807 (11-12 · 사용자 · A · B · C 는 잠시 대기 · 물음 먼저 — 단가산출의 항목 · 기계의 항목이 하나의 파일인지)
+
+ABC는 잠시대기, 내 질문에 대한 대답부터 단가산출의 항목, 기계의 항목이 하나의 파일이야?
+
+## 요구 808 (11-12 · 사용자 · 1 기계 하나의 항목은 하나의 파일로 분리하는 게 맞아 보임 · 2 자재는 어쩔 수 없음 · 3 A · B · C 진행)
+
+1. 기계 하나의 항목은 하나의 파일로 분리하는게 맞아보임.
+2. 자재는 어절수 없음.
+3. ABC 진행