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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 사건연도 분리

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

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

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

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

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