불량 상태란을 만들지 않기 위해 주의해야 할 일

웹 응용 프로그램 개발에서는 테이블에 상태 표시줄을 설정하는 경우가 많습니다.
여기서 우리는 실제 업무에서 겪는 불량 상태열 디자인을 교재로 삼아 정확한 상태란 디자인이 무엇인지 생각할 것이다.

상태를 구분해야 하는 이유

상태는 문자와 같이 객체의 상태를 나타냅니다.
개발에서 조작 대상(대상)이 있는 상태에서 값을 명명하거나 분배할 수 있다.
예를 들어 처리할 대상이 글이라면 공개 중, 초고 등 상태로 분리한다.
상태를 이렇게 정의해야 하는 이유는 이 상태에서만 실행되거나 실행하고 싶지 않은 처리가 있기 때문이다.
이것은 제목에서 유일하게 주의해야 할 점이다. 상태를 정의할 때 이 점을 주의하지 않으면 다음과 같은 불량 상태 설계를 완성할 수 있다.

반모드의 하나.추출 상태의 입도가 비정상적이다

가령 Yahoo𐁻!만약 어떤 매체가 유사한 뉴스를 발표했다고 가정한다면.
이 매체는 운영사무국이 기자가 쓴 기사를 검토해 내용에 문제가 없으면 게재하는 업무 절차다.

이 상태에서만 실행하고 싶은 처리나 실행하고 싶지 않은 처리가 있는지 여부를 감안하여 다음과 같은 두 가지는 실행하고 싶은 처리나 실행하고 싶지 않은 처리에 속한다.

문장의 심사를 위해 문장을 제작하면 통지

기사 검토 종료 전까지 기사 비공개

그렇다면 이 상자에 다음과 같은 데이터 디자인이 있다면 어떨까요?

※ 상태의 특성상 사용자 ID 등 외부 키나 글 본문 등 다른 열은 기재되지 않았습니다.
먼저 편집status에 관한 열입니다.
인출 상태는'신청 중·재신청 중'이 있지만, 이를 구분할 필요는 없다.
'신청 중','재신청 중'상태는'보도 심사를 위해 기사를 썼으면 통지한다'는 식의 처리가 필요하지만, 1차든 2차 신청이든 사무국에서 진행하는 심사라는 업무 절차에는 지장이 없기 때문이다.
따라서'신청 중'을 총결산으로 삼는 것이 좋다.
상태를 추출하려면 얼마든지 할 수 있어요.
예를 들어'신혼, 감기, 식중독, 식사 중, 휴식 중'등 사람의 상태를 바꾸어 보려고 한다.
이렇게 되면 경계가 없기 때문에 입도가 작은 것을 모아야 한다.
예컨대 근태관리시스템에 결근 사유 등을 보관하는 경우'감기·식중독'은 너무 가늘다.몸이 불편하다기보다는 큰 알갱이의 취합이 좋다.
또'신혼'이라는 상태는 현실 세계에서 고려해야 할 상태일 수 있지만, 근태시스템에'신혼 때 특별휴가를 준다'등의 처리가 없는 상황에서 실장에 정의의 의미가 없다는 것이다.
이처럼 특정 처리와 관련이 없는 상태가 있으면 혼란을 초래할 수 있다.
실상에서 사용하지 않는 상태는 헛수고이기 때문에 끊임없이 절약해야 한다.

반모드의 두 번째.상태 막대 중첩

첫 번째는 상태 값의 중복 값이고, 두 번째는 여러 상태 표시줄에 걸쳐 상태가 중첩되는 경우다.
상술한 데이터 설계는 아직 약간의 좋지 않은 점이 있다.그것은 두 개의 저장 상태가 있는 열이다.
우선 이 시행방식에서 상태를 정의하는 목적은'글의 심사를 위해 글이 작성되면 공지한다'는 처리와'글의 심사가 끝날 때까지 보도를 공개하지 않는다'는 처리가 특정 상태에서 이뤄지도록 하는 것이다.
두 열의 사용자 정의 상태를 비교할 때 제어할 수 있는 값이 완전히 중첩됩니다.
표를 만들면 일목요연하다.

구체적으로 중복되는 부분은 다음과 같다.
*초안 중 비공개 중 하나만 있으면 기사 편집 여부를 판단할 수 있습니다
*'완성','공개 중'중 하나만 있으면 공개 보도가 가능한 상태인지 판단할 수 있다
※'신청 중','재신청'에 대해서는 앞에서 설명한 바와 같이
이런 상황에서 status열은 하나로 합칠 수 있는데 만약 수치가'편집 중, 신청 중, 공개 중'이라는 세 개라면 훨씬 간단하다.

후기

이상은 상태막대 디자인입니다.