Phương pháp tiếp cận
Bạn có hai lỗi trong cách tiếp cận của mình, điều này dẫn đến sự phức tạp.
-
Bất kỳ cột nào có thể được dẫn xuất, chẳng hạn như AVERAGE của bạn không nên được lưu trữ.
Nếu nó được lưu trữ, nó tạo thành một cột trùng lặp ... dẫn đến Cập nhật Bất thường, như bạn đang gặp phải. Điểm của Chuẩn hóa là loại bỏ sự trùng lặp dữ liệu và do đó loại bỏ các Bất thường Cập nhật. Nó cũng loại bỏ các mã phức tạp như mã này, cũng như các trình kích hoạt, v.v.
Tính SUM (), AVG (), v.v., trong bộ kết quả chỉ , đang bay.
-
Sử dụng cột ID, về cơ bản có nghĩa là bạn có Hệ thống lưu hồ sơ, không có Cơ sở dữ liệu quan hệ. Không liệt kê nhiều vấn đề mà nó gây ra (tôi đã làm điều đó ở nơi khác), chỉ cần đặt tên cho vấn đề ở đây
- bạn có tư duy về ID.
ID là một con trỏ bản ghi vật lý, nó không cung cấp tính duy nhất của hàng, theo yêu cầu đối với Cơ sở dữ liệu quan hệ.
ID là một con trỏ bản ghi vật lý, nó không có nghĩa gì, người dùng không nên nhìn thấy nó. Nhưng bạn (và những người khác) đã cho nó ý nghĩa.
Điều này liên kết bạn với cấu trúc vật lý của tệp, chứ không phải cấu trúc logic của dữ liệu. Điều này làm phức tạp mã của bạn.
Do đó, mà không cung cấp cho bạn một
CREATE TABLEđã chỉnh sửa , giữ nguyên trạng thái của bạn, hãy để chúng tôi giả sử rằng ID và AVERAGE, không tồn tại trong tệp.
Mục thứ ba, không liên quan đến cách tiếp cận, có vẻ như từ hình cho trước, 10.58, bạn muốn Kilomét trên lít, trong khi số học bạn đã chi tiết (Lít trên 100 km) sẽ cho ra 9.44. Nếu bạn muốn một mức trung bình của một số loại, tốt hơn hết bạn nên tìm hiểu các yếu tố trước.
Giải pháp
(Code obsolete due to revision)
Câu hỏi được sửa đổi
Tôi đã cố gắng lấy các số liệu bạn đưa ra, trong khi câu hỏi vẫn còn bối rối (lưu ý các nhận xét về hiệu ứng đó). Vì bạn đã Đã sửa đổi câu hỏi của bạn, yêu cầu bây giờ rõ ràng. Bây giờ có vẻ như bạn muốn (a) Lít trên 100 km [vẫn không phải là "trung bình"], và (b) một con số tổng thể cho mỗi bản ghi [một loại tổng số lần chạy]. Trong trường hợp đó, hãy sử dụng mã này.
Các ghi chú trên vẫn có hiệu lực và có thể áp dụng.
SELECT CARID,
DATETIME,
KM,
LI,
LPCK = ( LI_TOT / ( ( KM_LAST-KM_FIRST / 100 ) ) -- not stored
FROM (
-- create a Derived Table with KM_FIRST
SELECT CARID,
DATETIME,
-- not stored
KM_FIRST = (
SELECT MIN( KM ) -- get the first KM for car
FROM CONSUM
WHERE CARID = C.CARID
),
KM_LAST = (
SELECT MAX( KM ) -- get the last KM for car
FROM CONSUM
WHERE CARID = C.CARID
),
KM, -- KM for this row
LI, -- LI for this row
LI_TOT = (
SELECT SUM( LI ) -- get the total LI for car
FROM CONSUM
WHERE CARID = C.CARID
AND KM != ( -- exclude first LI for car
SELECT MIN( KM ) -- get the first KM for car
FROM CONSUM
WHERE CARID = C.CARID
)
)
FROM CONSUM C
) AS CONSUM_EXT
ORDER BY CARID,
DATETIME
Lưu ý rằng tôi đang thao tác dữ liệu và chỉ dữ liệu, không có trường vật lý, chúng ta không nên quan tâm đến các khía cạnh vật lý của tệp. Lít trên 100 km (cái mà bạn đang gọi là AVERAGE) không được lưu trữ, và có thể tránh được Sự bất thường về Cập nhật. Con số tổng thể cho mỗi bản ghi được tính "nhanh", chỉ tại thời điểm hiển thị.
Điều này cũng loại bỏ /first entry của bạn vấn đề.
Tất nhiên, CARID cũng như vô nghĩa đối với người dùng.
Vui lòng bình luận hoặc đặt câu hỏi, v.v.
Lưu trữ cứng
Có nhiều vấn đề với việc lưu trữ một giá trị có thể được suy ra. Đây là Mã hóa cứng ở cấp độ lưu trữ dữ liệu. Chắc chắn, bạn có thể sử dụng một bộ kích hoạt để giảm bớt cơn đau, nhưng nó vẫn không hoạt động, vì (a) nguyên tắc bị hỏng và (b) nó vi phạm các nguyên tắc kỹ thuật hiện có. Ví dụ. điều gì sẽ xảy ra khi LI cho một hàng được nhập không chính xác (ví dụ:700,17) và sau đó được sửa (ví dụ:70,17)? Tất cả các hàng tiếp theo cho ô tô đó hiện không chính xác và phải được tính toán lại và cập nhật. Vì vậy, bây giờ bạn cần một trình kích hoạt Cập nhật cũng như một trình kích hoạt Chèn. Các hợp chất gây ung thư.
Khái niệm Bất thường về Cập nhật, cấm lưu trữ các giá trị có thể bắt nguồn, đã xuất hiện với chúng tôi từ năm 1970, vì lý do chính đáng. Chúng tôi tránh chúng, vì lý do chính đáng.
