2011-01-16 7 views
0

간단한 인벤토리 응용 프로그램을 만들고 있습니다. 테이블에는 Quantity, Price 및 TotalPrice 열이 있습니다. 어느 것이 더 좋습니까? TotalPrice를 Computed Column으로 수량 * 가격으로 사용하거나이 계산을 애플리케이션에서 수행하고 TotalPrice에 저장합니까?간단한 곱셈을위한 계산 열?

답변

2

데이터베이스 설계의 한 가지 규칙은 일반적으로 쉽게 검색 할 수있는 정보를 저장하지 않습니다.

귀하의 경우 계산 열을 만들지는 않지만 검색하는 동안 곱셈을 수행합니다. price * quantity을 직접 선택하거나이 계산을 포함하는보기를 작성하십시오.

보기에는 애플리케이션의 모든 문을 변경하지 않고도 VAT 등의 수식을 쉽게 변경할 수 있다는 이점이 있습니다.

+0

그래서보기를 추가해야합니까? – SMUsamaShah

+0

그것은 (분명히 간단히) 계산의 정의를 중앙 집중화합니다. 검색 (예 : 보고서)에만 사용되는 경우보기로 이동합니다. 그러나 DBMS 및 프로그래밍 언어에 따라보기를 통해 데이터를 업데이트하려고하면 몇 가지 문제가 발생할 수 있습니다. 그렇다면 SELECT 문에 곱셈을 추가하거나 응용 프로그램에서 간단하게 처리합니다. 환경에 따라 다릅니다. 이를위한 "황금률"은 없습니다. –

+0

보기가 좋게 들립니다. 향후 "TotalPrice"계산이 변경되면 500 개의 쿼리가 아닌보기 만 변경됩니다. 또는 동일한 효과에 대해 쿼리에서 함수를 호출 할 수 있습니다. –

0

왜 계산에서 계산을 할 수있을 때 계산 된 열을 저장합니까?

SELECT (Quantity * Price) as TotalPrice FROM my_table 
+0

기록을 유지하십시오. – SMUsamaShah

+0

그리고 TotalPrice가 변경되면 세금이 필요합니다. 그런 다음 모든 쿼리가 아니라 한 곳에서 변경하면됩니다. – PostMan

1

가격 또는 수량을 업데이트하면 TotalPrice에서 2cd 업데이트를해야합니다. 다른 개발자가 2cd 업데이트를 잊어 버린 경우 어떻게해야합니까? 이제 나쁜 데이터가 있습니다.

트리거를 동기화 상태로 유지할 수는 있지만 잘못된 데이터의 가능성은 여전히 ​​존재합니다. 일부 RDMS에서는 집합 기반 업데이트에서 업데이트 된 각 행에 대해 트리거가 실행되지 않습니다.

하지만 때로는 계산 된 필드를 저장해야합니다. 테이블이 큰 경우 계산 된 필드를 검색 할 계획입니다. (색인을 생성하려면 데이터를 저장해야합니다). 일부 설계에서는 계산 된 필드를 저장할뿐만 아니라 계산도 집계합니다.

계산 된 입력란을 저장하는 것이 항상 잘못된 것은 아니며, 단점을 알고 있는지 확인하십시오.

* EDIT * 다른 점. "Amount_Paid"를 계산하면 계산 수식을 변경할 때 고객이 지불 한 실제 금액이 손실됩니다.

디자인 문제를 해결합니다. 엄지 손가락의 규칙을 어기면 엄지 손가락을 떼십시오. * END EDIT *

+0

나는 그 열에 CHECK() 제약 조건을 가지지 않고서도 계산할 수있는 열을 저장하는 것이 잘못 될 것이라고 덧붙이겠습니다. –