2021-gpu-is-mine
2021-gpu-is-mine copied to clipboard
woowacourse-teams
Job의 expectedTime의 저장 방식을 결정한다.
이슈 설명
Job 관련 결정할 사항이 있어서 글 남깁니다!
현재 Job의 expectedTime 값을 String으로 저장하고 있는데요! 이 부분을 어떤 방식으로 저장할지 결정해야 해서 의견을 듣고 싶어서 글을 남겨요!
어떤 방식을 취하는 지는 상황 마다 다를 거라 생각하는데요! 어떤 방식으로 입력값을 받는 부분도 영향을 받을 것 같아요. 밑에 부분은 제가 생각한 방식 몇 가지를 적어보겠습니다!
- hour 단위로 저장한다. 1일 2시간 30분 -> 24 + 2 + 0.5 = 26.5 -> 이 부분은 소수점으로 저장되어서, 분을 60으로 나누는 과정에서 정보가 훼손 될수 있습니다. (소수점 버림)
- minute 단위로 저장한다. 2시간 30분 -> 2 * 60 + 30 = 150 -> 우리가 초 단위로 정보를 입력받지 않을 것이라 생각해서, 소수점까지 안내려간다는 장점이 있습니다.
- day, hour, minute 의 칼럼을 별도로 두고 각각 저장한다. 1일 2시간 30분 ->day=1, hour=2, minute=30 요런 방식으로 저장하는 방식입니다!
참고한 자료는 아래고요! https://stackoverflow.com/questions/1540123/best-way-to-store-time-interval-values-in-mysql
결정된 이후로는 프론트엔드에서 어떠한 방식으로 시간을 넘겨줄지도 의논해 봐야할 것 같아요!
- 라벨을 달아주세요.
분 단위로 넘겨주면 프론트에서 활용 자유도가 높아질 것 같아요. 프론트에서 시간 또는 날짜 단위로 표시하고 싶다면 분 단위를 계산하면 된다고 생각합니다. 아니면 백에서 분 단위를 프론트가 원하는 방식으로 계산해서 넘겨주면 됩니다.
결론: 분 단위로 저장하는게 좋을 것 같아요.
저희가 시간 예측 기능은 아마 만들 시간이 없어 보입니다(실제 시간 예측). 그리고 실제 예측이 아니라 사용자가 기록해야한다면 사용자가 실제 예측 시간이 분이라는 값을 입력할정도로 자세한 값을 입력하려고할까요? 이런 면에서 저는 시간 단위로 우선 가져가는게 좋다고 봅니다
- 소수점 단위의 저장은 불가능 한가용?
minute형태로 저장하는 방식으로 결정됐다면 FE측에서 hour로 받아서 minute단위로 변환하여 전달해도 좋을 것 같아요 ! -
hour로 받은 정보를minute형태로 변환하는 이유를 알 수 있을까요?-
학습이라는 데이터의 단위가 주로hour~day정도라서분단위 데이터가 없어지더라도 추후에 어플리케이션에 큰 영향을 미칠까 싶습니다 (위험한 생각일까요?? 🤔)
-
실제 시간 예측이 되지 않는다면, 시간 예측 기능을 아예 빼버리는건 어떨까요?
실제 작동할 시간과 상관없는 정보를 입력받고 이를 보여주는 게 큰 의미가 있을까 싶네요..
저도 예측시간이 꼭 필요한가에 대한 것은 의문입니다.ㅎㅎ 애초에 시간예측을 하기 어렵기 때문에 이런 서비스가 만들어 졌다고 생각이 들어서요. 오히려 에뮬레이터를 만들기 어려운 상황에서 필요했던 데이터라고 생각이 듭니다. 동동의 의견처럼 아예 없애는 것도 좋다는 생각입니다 :)
오호, 기존의 구현을 유지한다는 생각을 했더니, 지워버린다는 생각은 못했네요!
그렇다면 아래의 부분에 어떤 정보들이 들어가는 게 좋을까요? 남겨진 Job의 갯수 정도?
Job의 상태마다 보여지는 정보가 달라지겠네요! (물론 기존에도 달랐지만, 형태 자체가 달라질듯!)
@wannte 그렇네용.. 그렇다면 대기중, 완료중, 실행중, 취소된 잡이 보여줘야 하는 정보가 다 달라져서, 지금처럼 하나의 리스트로 보여주는 방식은 적합하지 않겠네욤
'앞에 몇개 Job이 남아있는지'는 보여줘야할 거 같고, 그 밖에 뭐가 더 필요할지는 고민을 더 해보겠습니다