빈 공간을 저장하지 마라

나는 빈자리열의 사용 방식이 그것들을 잘 사용하지 못하게 하는 것을 자주 본다.
나는 내가 처음으로 직업 발전의 길에 올랐을 때 이런 모델을 만났던 것을 기억한다. 이 모든 것이 일리가 있는 것 같다.
"선택을 나타내는 열을 만듭니다. 사용자는 예 또는 아니오를 선택할 수 있지만 선택하지 않을 수도 있습니다."
ALTER TABLENAME
   ADD ColumnName bit null
이것은 당시에 일리가 있었고, 나는 그들과 더 많이 협력했다.나는 대부분의 경우 이것이 실천에서 무섭다고 느낀다.
흔히 볼 수 있는 용례를 가정해 봅시다.
  • 맞춤형 마스크 주문
  • "초편안 면"사용자 옵션
  • UI에서는 다음과 같은 TypeScript 객체를 사용하여 UI를 정의합니다.
    export class CustomShirt {
       ... // other properties
       IsExtraComfortable: boolean;
    }
    
    API에서는
    public class CustomShirtOrder
    {
        ... //other properties
        public bool? IsExtraComfortable { get; set; }
    }
    
    이곳의 모든 것이 보기에 매우 좋다.그러나 미래의 개발상들에게는 두 가지 작은 문제가 있다.
    UI/프런트엔드는 부울 값의 상태에 지나치게 집중해야 합니다.
    if (IsExtraComfortable != null && IsExtraComfortable) { }
    
    이것은 결코 큰 문제가 아니지만, 이것은 볼 연산을 사용하는 곳에서 오류를 도입할 기회이다.우리는 반드시 기억해야 한다.
  • 이것은 빈 필드임을 나타내는 인터페이스를 실현할 수 있다
  • 오용은 컴파일링 오류를 가져올 수 있습니다
  • 그러나 TypeScript가 최종적으로 자바스크립트로 컴파일되었기 때문에 명예(TypeSafety)를 보장할 수 없습니다.
  • 또한 합리적으로 명명된 변수'IsExtra Comfortable'의 전제는 셔츠가 특별히 편안한지 여부다. 사용자 인터페이스에 세 번째 상태가 필요하다면 시스템 구조도 세 번째 상태를 허용해야 한다.나는 이것이 매우 중요한 개념이라고 생각한다. 구조는 업무 논리를 반영해야 한다.
    주문 집행 부서에도 추가로 편안한 셔츠 부서가 있다고 가정해 보세요.따라서 다음 주문을 선택하면 호출 함수 검색이 수행됩니다.
    public Order GetNextShirtOrder(Filter filter)
    {
        bool comfortChoice = filter.IsExtraComfortable != null ?
    filter.IsExtraComfortable : false;
        var orders = new IQueryable<Order>();
    
        // when xtra comfort is requested:
        if (filter.IsExtraComfortable.HasValue && comfortChoice)
        {
           orders = db.Orders.Where(w => 
             w.IsExtraComfortable == true);
        }
    
        // when regular or undecided:
        if (!filter.IsExtraComfortable.HasValue || !comfortChoice)
        {
           // could get true and null, or false and null as required
           orders = db.Orders.Where(w => 
             w.IsExtraComfortable == comfortChoice ||
             w.IsExtraComfortable == null);
        }
    
        // Other filters
    
        return orders.OrderBy(o => o.OrderTime).FirstOrDefault();
    }
    
    우리는 대량의 추가 코드를 만들고 있는데, 이 코드들은 편안한 상태를 유지하고 테스트하기 매우 어렵다.이것은 혼란스러워서 일반적으로 허락되어서는 안 된다.
    현재 업무 수요는 'IsExtraComfortable' 에서 가입, 퇴출, 선택하지 않는 내용을 선택할 수 있습니다.
    우리는 그것을 대체할 수 있다.
    ALTER TABLENAME
       ADD IsExtraComfortable tinyint not null
    
    더 좋은 것은 매거에 매핑된 유형 테이블을 사용하는 것입니다.
    public enum ExtraComfortableNess
    {
       NotSelected = 0,
       RegularComfort  = 1,
       ExtraComfortable = 2
    }
    
    이렇게 하면 두 가지 중요한 장점이 있다.
  • 보고서에서 이 값의 의미를 볼 수 있다
  • C#의 Int는 기본적으로 0이므로 코드를 단순화할 수 있습니다
  • .
  • 다른 편안함
  • 이 추가되면 코드에 손대지 않아도 됩니다.
  • UI 값
  • 과 같은 내용을 볼 때만 유형표를 연결할 수 있습니다.
  • 우리는 편안한
  • 의 메타데이터를 얻을 수 있다
    다른 생각: 만약 우리가 정말로 IsExtraComforable의 속성을 원한다면, 우리는 당연히 이 점을 실현할 수 있다.
    public bool IsExtraComforable 
    {
        get { return ExtraComfortableNess == 1; }
        set { //not settable }
    }
    
    현재 6개월 안에 이 업무에 새로운'Primo Comfort Cotton'이 추가된다면 우리는 기존 논리와 새로운 논리를 한데 묶으려고 하지 않을 것이다.
    비어 있는 브리 값을 사용하면 우리의 논리가 좀 이상할 수도 있다.분명히 셔츠는 두 가지 원단으로 만들 수 없다.이것은 우리가 한 부울 값이 설정된 위치를 계속 검사할 것이며, 다른 부울 값이 설정되지 않았거나, 설정되지 않았음을 의미한다.
    두 주문 간의 업무 차이는 무엇입니까
    ShirtFabric : {IsExtraComfortable: false, PrimoFabric: true }
    

    ShirtFabric : {IsExtraComfortable: null, PrimoFabric: true }
    
    이 모든 것은 훨씬 쉬워질 것이다.
    ShirtFabric : Fabric.PrimoFabric
    
    또는
    ShirtFabric : 3
    
    공간 절약형
    우선, 우리가 통상적으로 비트를 사용하고 싶은 이유는 공간 제한이다.이유는 비트를 사용하면 디스크, 서버 메모리와 클라이언트에 아주 작은 물건을 저장할 수 있기 때문이다.
    SQL에서 이것은 때때로 옳을 뿐이다.
    그 중 한 바이트는'B'이고 한 바이트는'B'이다.N은 테이블의 비트레이트 수입니다. 우리의 비트레이트 크기는 더욱 비슷합니다.
    B=⌈N/8⌉
    그래서 1열은 여전히 한 바이트, 최대 8자리열이다.아니면 통조림이랑 똑같아요.9위열도 2바이트의 저장 공간이 필요하다.이것은 확실히 우리가bit열을 사용하는 가장 좋은 논거이다.
    하지만
    C#bool에서는 4바이트입니다.JavaScript(TypeScript로 확장) 부울 값도 4바이트입니다.
    한 마디로 하면 적어도 대다수 상황에서 우리는 공간을 절약하지 못했다.메모리에서 최대 255개(0-255)의 선택을 할 수 있는 작은 바이트와 기본값을 추가할 수 있으며 추가 비용을 증가시키지 않습니다.
    그러나 더 중요한 것은 한 열에 색인을 만들 수 없다는 것이다.모든 int열에서 사용할 수 있습니다.특히 현재Azure 등 서비스에서 DTU는 매우 비싸고 저장도 매우 싸다.수백만 줄의 비인덱스 값을 조회하는 비용은 때때로 더 많은 데이터를 사용하는 비용보다 훨씬 높다.
    마지막으로, 나는bit란에 대해 그렇게 가혹하지 않을 것이다.우리는 공간을 절약하는 서열을 얻었다.우리는tinyint와 같은 공간에서 8개의 값을 비트레이트로 저장할 수 있고 제3상태의 공간이 정확하지 않다.하지만 당신의 요구가 이렇다면:
    "모든 주문에 대해 표준 및 긴급 처리를 제공하며 스토리지에 긴급 처리가 필요한지 확인합니다."나는 당신이 시장 지도자와 당신이 자주 사용하는 사이트에 관심을 가지고 다음과 같은 모델에 주의하도록 격려합니다.
  • 표준 프로세싱(4-7일)
  • 긴급 처리(익일(영업일 기준)
  • 슈퍼 저축 처리(영업일 기준 5~10일 이내 x달러 절감)
  • 나는 우리가 모두 증강된 냄새를 맡을 수 있다고 생각한다. 그것은 우리의 비트기둥을 깨뜨릴 것이다.나는 틴트를 선택할 것이다.

    좋은 웹페이지 즐겨찾기