빈 공간을 저장하지 마라
나는 내가 처음으로 직업 발전의 길에 올랐을 때 이런 모델을 만났던 것을 기억한다. 이 모든 것이 일리가 있는 것 같다.
"선택을 나타내는 열을 만듭니다. 사용자는 예 또는 아니오를 선택할 수 있지만 선택하지 않을 수도 있습니다."
ALTER TABLENAME
ADD ColumnName bit null
이것은 당시에 일리가 있었고, 나는 그들과 더 많이 협력했다.나는 대부분의 경우 이것이 실천에서 무섭다고 느낀다.흔히 볼 수 있는 용례를 가정해 봅시다.
export class CustomShirt {
... // other properties
IsExtraComfortable: boolean;
}
API에서는public class CustomShirtOrder
{
... //other properties
public bool? IsExtraComfortable { get; set; }
}
이곳의 모든 것이 보기에 매우 좋다.그러나 미래의 개발상들에게는 두 가지 작은 문제가 있다.UI/프런트엔드는 부울 값의 상태에 지나치게 집중해야 합니다.
if (IsExtraComfortable != null && IsExtraComfortable) { }
이것은 결코 큰 문제가 아니지만, 이것은 볼 연산을 사용하는 곳에서 오류를 도입할 기회이다.우리는 반드시 기억해야 한다.주문 집행 부서에도 추가로 편안한 셔츠 부서가 있다고 가정해 보세요.따라서 다음 주문을 선택하면 호출 함수 검색이 수행됩니다.
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
}
이렇게 하면 두 가지 중요한 장점이 있다.다른 생각: 만약 우리가 정말로 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상태의 공간이 정확하지 않다.하지만 당신의 요구가 이렇다면:
"모든 주문에 대해 표준 및 긴급 처리를 제공하며 스토리지에 긴급 처리가 필요한지 확인합니다."나는 당신이 시장 지도자와 당신이 자주 사용하는 사이트에 관심을 가지고 다음과 같은 모델에 주의하도록 격려합니다.
Reference
이 문제에 관하여(빈 공간을 저장하지 마라), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/athomsfere/don-t-store-null-bits-3ped텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)