code-for-korea / sanjae.server Goto Github PK

한 화면에 보여질 항목 수 50개로 늘리기
혹은 선택 할 수 있게 하거나
딱히 가이드는 없는데 가급적 페이지 전환을 덜하기 위해

현재는 만들어져 있는 엑셀 파일을 받을 수 있는 링크로 가는데,
서비스에서 추가로 입력 된 데이터를 포함한 서비스 데이터를 엑셀로 내려받는 기능.
위치는 현재처럼 목록 우측 상단에 있으면 됨.

만들어 두신 코드를 실행 해 봤는데, 크게 많이 손볼 곳 없이 잘 되어 있는 것 같습니다.
Working conditions는 제가 CharField로 처음에 작성했는데, 제가 실수했어요.
근무조건과 업무 환경은 근로자가 근무한 내용이나 환경에 대한 서술이 필요한 것이라 TextField가 맞을 것 같습니다.

편집창의 질병코드에 질병코드 선택 팝업 연결
javascript로 만든 질병코드 선택 팝업은 아래 host.html 참고하여 붙이면 될 듯.
https://github.com/Code-for-Korea/Industrial_disasters/tree/main/CodePicker

질병명으로 검색을 요청하셨는데 그냥 일반 문자열 검색으로 질병명 컬럼과 판결문 컬럼을 대상으로 하는게 좋을듯.

• OPENDATA_API_KEY, SECRET_KEY를 환경 변수로 이전
• ...

아래 내용을 요약하면...
개발 내용은 개발자가 개발하기 편한 것으로, 법적인 내용이나 의학적 내용은 전문가의 자문을 받되, 우선은 개발하기 편리한 것을 기준으로 하시죠.

1. TODO 앱 이름과 모델 이름을 구분하는 게 좋지 않을까..

• 매 건 이런 의문을 가지고 진행하시면 정신 건강에 좋지 않으니, naming은 편하신 것을 쓰시면 좋겠습니다.
• naming이라는 것이 각자의 오랜 습관에 영향을 많이 받으니, 코드 작성자가 가장 편한 것을 쓰는 것이 정답일 것 같고, 협업을 해야 할 경우, 필요한 부분은 잘 문서로 정리 해 두면 될 것 같습니다. 개발하기 편하신 것으로 하시죠.

2. 연관사건이 ForeignKey가 될 수 있을까? 현재 목록에 없는 사건번호도 있어서 일괄적용은 어려울 듯.

• 연관 사건은 최대 5개까지 있었어요. 제가 django를 아직 잘 모르는데, ForeignKey도 동적인 배열로 가져갈 수 있다면 ForeignKey로 가도 좋겠네요.
• 말씀하신 것 처럼, 목록에 있는 것도 있고 없는 것도 있으니, 목록에 있는 연관사건과 목록에 없는 연관 사건을 구분하면 어떨까요? 목록에 없는 연관 사건은 DB update 후, 체크 로직을 반영하고.
• 목록에 있는 것은 링크가 반영되고, 없는 것은 dimmed처리 되거나 링크 없이 텍스트 그대로 보여주도록 하시죠.

3. 사건연도 분리

• 어디에 나오는 사건 연도를 말씀하시는지요?
• 사건번호는 그 자체로 고유한 코드라서 이 값으로 법원의 사건정보를 조회하니 이 값은 그대로 유지하는 것이 좋을 것 같아요.
• 연도 속성이 필요하면 사건번호 필터링으로 하거나 별도 속성 추가하는 것이 어떨까요?

4. 법원 이름 띄어쓰기 다른 케이스 존재. 통일

• 법원 이름은 공백을 다 삭제하는 것으로 통일하면 어떨까요?

5. 법원이 별도 테이블로 존재해야 하는가?

• 그럴 필요는 없을 것 같아요.
• 나중에 검색이나 가공을 위한 상세 속성 고도화를 따로 진행하는 것이 좋을 것 같아요. 그때 이야기를 하려면 뭔가 눈에 보이는 것이 있어야 할테니, 우선은 먼저 눈에 보이는 것 만드는 것을 목표로 하고, 구현하시기 용이한 것을 기준으로 하시죠.

-업무환경처럼 편집 가능 속성으로 처리

• UI layout은 일단 구현하기 용이한 형태로 하되, 현재 업무 환경 영역을 상하 반으로 나눠서 아래쪽에 추가

좀 큰 덩어리 일 수 있는데...
최근 데이터를 조회하는 방법을 확인하면 데이터 땡겨오는 시간을 줄일 수 있을 듯합니다.
신규 데이터 조회하여 현재 없는 데이터이면 추가.
스케쥴러를 만들어서 자정 같은 시간에 돌아가게 할 수 있으면 좋지만,
여의치 않으면 관리자만 실행 할 수 있는 버튼 노출로 한번씩 업데이트 해 주거나.
새로운 날짜의 첫번째 사용자가 로그인 하면 업데이트 체크를 하거나...

최종 수정 일시와 최종 수정 계정 표시
위치는 질병코드와 질병명 속성 두 개가 하나로 합쳐져서 남은 곳을 활용하면 될 듯.

DB 초기 설정시 공공데이터API에서 가져온 판례 중 같은 사건번호로 두 개의 판결문 데이터가 조회되는 경우가 200여건 있습니다. 예를 들어:

• http://sanjae.codefor.kr/rulings/27591/
• http://sanjae.codefor.kr/rulings/27592/

이 두 항목은 판결문, 제목 등 대부분의 속성이 동일하지만 '사고질병구분'이 '업무상질병'과 '기타'로 다르게 등록되어 있습니다. 이들 사건 중복항목을 어떤 식으로 처리하면 좋을지 의견 구합니다.

(한쪽만 남기고 삭제한다, 둘 다 유지하고 사용자가 데이터 취합한 뒤 직접 판단하도록 한다 등)

• A00:XXXXXXXXX 형식의 한가지 문자열 데이터만 있으면 되고 필요하면 간단히 파싱 가능하므로.

목록을 컬럼별로 오름차순/내림차순 정렬