ตกลงเพื่อเก็บค่าซึ่งอัพเดตในตารางหรือไม่?


31

เรากำลังพัฒนาแพลตฟอร์มสำหรับบัตรเติมเงินซึ่งโดยทั่วไปเก็บข้อมูลเกี่ยวกับบัตรและยอดเงินการชำระเงินและอื่น ๆ

จนถึงตอนนี้เรามีนิติบุคคลที่มีการรวบรวมบัญชีนิติบุคคลและแต่ละบัญชีมีจำนวนเงินซึ่งจะอัพเดทในทุกการฝาก / ถอน

ตอนนี้มีการถกเถียงกันในทีม มีคนบอกเราว่าการแบ่งกฎ 12 ข้อของ Coddและการอัปเดตค่าในการชำระเงินแต่ละครั้งนั้นเป็นปัญหา

นี่เป็นปัญหาจริงๆหรือ

ถ้าเป็นเช่นนั้นเราจะแก้ไขได้อย่างไร


3
มีการอภิปรายทางเทคนิคอย่างกว้างขวางในหัวข้อนี้ที่ DBA.SE: การเขียนโครงสร้างธนาคารอย่างง่าย
Nick Chammas

1
กฎข้อใดของ Codd ที่ทีมของคุณอ้างถึงที่นี่ กฎนี้เป็นความพยายามของเขาในการกำหนดระบบที่เกี่ยวข้องและไม่ได้กล่าวถึงการทำให้เป็นมาตรฐานอย่างชัดเจน Codd ไม่หารือเกี่ยวกับการฟื้นฟูในหนังสือของเขาแบบจำลองเชิงสัมพันธ์สำหรับการจัดการฐานข้อมูล
เลนซามูเอลแมคลีนผู้อาวุโส

คำตอบ:


30

ใช่มันไม่ได้ทำให้เป็นมาตรฐาน แต่บางครั้งการออกแบบที่ไม่ได้ทำให้เป็นมาตรฐานได้รับรางวัลด้วยเหตุผลด้านประสิทธิภาพ

อย่างไรก็ตามฉันอาจจะเข้าหามันแตกต่างกันเล็กน้อยเพื่อเหตุผลด้านความปลอดภัย (ข้อจำกัดความรับผิดชอบ: ปัจจุบันนี้ฉันยังไม่มีหรือเคยทำงานในภาคการเงินมาก่อนฉันเพิ่งจะทิ้งเรื่องนี้ไว้)

มีโต๊ะสำหรับโพสต์ยอดคงเหลือบนบัตร สิ่งนี้จะมีแถวแทรกสำหรับแต่ละบัญชีซึ่งแสดงยอดคงเหลือที่ผ่านรายการในตอนท้ายของแต่ละงวด (วันสัปดาห์เดือนหรืออะไรก็ตามที่เหมาะสม) จัดทำดัชนีตารางนี้ตามหมายเลขบัญชีและวันที่

ใช้ตารางอื่นสำหรับการทำธุรกรรมที่ค้างอยู่ซึ่งถูกแทรกทันที เมื่อปิดแต่ละงวดให้เรียกใช้ชุดคำสั่งที่เพิ่มธุรกรรมที่ยังไม่ได้โพสต์ลงในยอดคงเหลือปิดล่าสุดของบัญชีเพื่อคำนวณยอดคงเหลือใหม่ ทำเครื่องหมายธุรกรรมที่รอดำเนินการตามที่โพสต์หรือดูวันที่เพื่อพิจารณาว่ายังมีอะไรรอดำเนินการ

ด้วยวิธีนี้คุณมีวิธีการคำนวณยอดเงินคงเหลือในบัตรตามต้องการโดยไม่ต้องสรุปประวัติบัญชีทั้งหมดและโดยการคำนวณยอดคงเหลือใหม่ในขั้นตอนการโพสต์เฉพาะคุณสามารถมั่นใจได้ว่าความปลอดภัยในการทำธุรกรรมของการคำนวณใหม่นี้ จำกัด ที่เดียว (และ จำกัด การรักษาความปลอดภัยในตารางดุลดังนั้นเฉพาะขั้นตอนการโพสต์เท่านั้นที่สามารถเขียนได้)

จากนั้นให้เก็บข้อมูลในอดีตเท่าที่จำเป็นโดยการตรวจสอบการบริการลูกค้าและข้อกำหนดด้านประสิทธิภาพ


1
เพียงบันทึกย่อสองอย่าง ครั้งแรกนั่นเป็นคำอธิบายที่ดีมากเกี่ยวกับวิธีการบันทึกรวมภาพรวมที่ฉันแนะนำข้างต้นและอาจชัดเจนกว่าฉัน (โหวตให้คุณ) ประการที่สองฉันสงสัยว่าคุณกำลังใช้คำว่า "โพสต์" ค่อนข้างแปลกที่นี่เพื่อหมายถึง "ส่วนหนึ่งของยอดคงเหลือปิด" ในด้านการเงินการโพสต์มักจะหมายถึง "แสดงในยอดดุลบัญชีแยกประเภทปัจจุบัน" และดังนั้นจึงดูเหมือนว่ามันคุ้มค่าที่จะอธิบายว่าดังนั้นจึงไม่ทำให้เกิดความสับสน
Chris Travers

ใช่อาจมีรายละเอียดปลีกย่อยมากมายที่ฉันพลาดไป ฉันแค่อ้างถึงวิธีการทำธุรกรรมที่ปรากฏเป็น "โพสต์" ไปยังบัญชีการตรวจสอบของฉันที่ใกล้ชิดของธุรกิจและยอดเงินที่ปรับปรุงตาม แต่ฉันไม่ใช่นักบัญชี ฉันแค่ทำงานกับพวกเขาหลายคน
db2

นี้อาจยังเป็นความต้องการสำหรับ SOX หรือชอบในอนาคตผมไม่ทราบว่าสิ่งที่ประเภทของการทำธุรกรรมไมโครต้องการคุณต้องเข้าสู่ระบบ แต่ฉัน defo จะถามคนที่รู้สิ่งข้อกำหนดในการรายงานมีการภายหลัง
jcolebrand

ฉันมีแนวโน้มที่จะเก็บข้อมูลที่ไม่สิ้นสุดสำหรับยอดคงเหลือ ณ จุดเริ่มต้นของทุก ๆ ปีเพื่อให้ภาพรวม "ยอดรวม" ไม่เคยถูกเขียนทับ - รายการจะถูกผนวกเข้าด้วยกัน (แม้ว่าระบบจะยังคงใช้งานได้นานพอสำหรับแต่ละบัญชี สะสม 1,000 ผลรวมรายปี [ มองโลกในแง่ดีมาก ] ซึ่งแทบจะไม่สามารถจัดการได้) การรักษายอดรวมรายปีเป็นจำนวนมากจะอนุญาตให้ใช้รหัสตรวจสอบเพื่อยืนยันว่าธุรกรรมระหว่างปีที่ผ่านมามีผลกระทบที่เหมาะสมกับยอดรวม [ธุรกรรมแต่ละรายการอาจถูกลบทิ้งหลังจาก 5 ปี แต่จะได้รับการตรวจสอบอย่างดีแล้ว]
supercat

17

ในอีกด้านหนึ่งมีปัญหาที่เราพบบ่อยในซอฟต์แวร์บัญชี ถอดความ:

ฉันจริงๆต้องปีสิบรวมของข้อมูลที่จะหาวิธีการที่เงินมากอยู่ในการตรวจสอบบัญชีหรือไม่

คำตอบที่แน่นอนคือคุณไม่ทำ มีวิธีการไม่กี่ที่นี่ หนึ่งคือการจัดเก็บค่าที่คำนวณได้ ฉันไม่แนะนำวิธีการนี้เนื่องจากข้อบกพร่องของซอฟต์แวร์ซึ่งทำให้ค่าที่ไม่ถูกต้องนั้นยากที่จะติดตามและดังนั้นฉันจะหลีกเลี่ยงวิธีการนี้

วิธีที่ดีกว่าที่จะทำคือสิ่งที่ฉันเรียกว่าวิธีการบันทึกภาพรวม - รวม ด้วยวิธีนี้การชำระเงินและการใช้ของเราเป็นส่วนเสริมและเราไม่เคยอัปเดตค่าเหล่านี้ เรารวบรวมข้อมูลในช่วงระยะเวลาหนึ่งและแทรกบันทึกสแนปชอตที่คำนวณซึ่งแสดงข้อมูล ณ เวลาที่สแน็ปช็อตใช้ได้ (โดยปกติจะเป็นช่วงเวลาก่อนที่จะมี)

ตอนนี้สิ่งนี้ไม่ได้ละเมิดกฎของ Codd เพราะเมื่อเวลาผ่านไปภาพรวมอาจน้อยกว่าที่สมบูรณ์แบบขึ้นอยู่กับข้อมูลการชำระเงิน / การใช้งานที่แทรกไว้ หากเรามีสแนปชอตในการทำงานเราสามารถตัดสินใจล้างข้อมูลอายุ 10 ปีโดยไม่กระทบต่อความสามารถของเราในการคำนวณยอดคงเหลือปัจจุบันตามความต้องการ


2
ฉันสามารถเก็บผลรวมที่คำนวณได้และฉันปลอดภัยอย่างสมบูรณ์ - ข้อ จำกัด ที่เชื่อถือได้ทำให้มั่นใจได้ว่าหมายเลขของฉันถูกต้องเสมอ: sqlblog.com/blogs/alexander_kuznetsov/archive/2009/01/23/…
AK

1
ในกรณีของฉันไม่มีวิธีแก้ปัญหา - ข้อ จำกัด ที่เชื่อถือได้จะไม่ทำให้คุณลืมอะไรเลย ฉันไม่เห็นความจำเป็นในทางปฏิบัติสำหรับปริมาณ NULL ในระบบของชีวิตจริงที่ต้องรู้จำนวนรวมที่ใช้งาน - สิ่งเหล่านี้ขัดแย้งกับสิ่งอื่น ๆ หากคุณเห็นความต้องการในทางปฏิบัติโปรดแบ่งปัน sceanrio ของคุณ
AK

1
ตกลง แต่นี่จะไม่ทำงานเหมือนใน db ของซึ่งอนุญาตให้ NULL หลายตัวโดยไม่ละเมิดเอกลักษณ์ใช่ไหม นอกจากนี้การรับประกันของคุณก็แย่เช่นกันถ้าคุณลบข้อมูลในอดีตใช่ไหม
Chris Travers

1
ตัวอย่างเช่นถ้าฉันมีข้อ จำกัด ที่ไม่ซ้ำกันใน (a, b) ใน PostgreSQL ฉันสามารถมีหลายค่า (1, null) สำหรับ (a, b) เพราะแต่ละ null ถือว่าเป็นค่าที่ไม่ซ้ำกันซึ่งฉันคิดว่าถูกต้องเชิง semantically ค่า .....
Chris Travers

1
เกี่ยวกับ "ฉันมีข้อ จำกัด เฉพาะเกี่ยวกับ (a, b) ใน PostgreSQL ฉันสามารถมีหลายค่า (1, null)" - ใน PostgreSql เราจำเป็นต้องใช้ดัชนีบางส่วนที่ไม่ซ้ำกันใน (a) โดยที่ b เป็นค่าว่าง
AK

7

สำหรับเหตุผลด้านประสิทธิภาพในกรณีส่วนใหญ่เราต้องเก็บยอดเงินปัจจุบันไม่เช่นนั้นการคำนวณในทันทีอาจช้าลงอย่างเด็ดขาด

เราเก็บผลรวมสะสมที่คำนวณไว้ล่วงหน้าในระบบของเรา เพื่อรับประกันว่าหมายเลขถูกต้องเสมอเราใช้ข้อ จำกัด โซลูชันต่อไปนี้ถูกคัดลอกมาจากบล็อกของฉัน มันอธิบายสินค้าคงคลังซึ่งเป็นปัญหาเดียวกัน:

การคำนวณผลรวมสะสมนั้นช้ามากไม่ว่าคุณจะใช้เคอร์เซอร์หรือการรวมรูปสามเหลี่ยม เป็นเรื่องน่าดึงดูดอย่างยิ่งที่จะทำให้เป็นปกติในการจัดเก็บผลรวมสะสมในคอลัมน์โดยเฉพาะอย่างยิ่งถ้าคุณเลือกบ่อยครั้ง อย่างไรก็ตามตามปกติเมื่อคุณยกเลิกการทำให้เป็นปกติคุณต้องรับประกันความถูกต้องของข้อมูลที่ถูกทำให้ผิดปกติ โชคดีที่คุณสามารถรับประกันความสมบูรณ์ของผลรวมการรันด้วยข้อ จำกัด ตราบใดที่ข้อ จำกัด ทั้งหมดของคุณเชื่อถือได้ผลรวมการทำงานทั้งหมดของคุณนั้นถูกต้อง ด้วยวิธีนี้คุณสามารถมั่นใจได้อย่างง่ายดายว่ายอดเงินปัจจุบัน (ยอดรวมการรัน) ไม่เคยเป็นค่าลบ - การบังคับใช้โดยวิธีอื่นอาจช้ามากเช่นกัน สคริปต์ต่อไปนี้แสดงให้เห็นถึงเทคนิค

CREATE TABLE Data.Inventory(InventoryID INT NOT NULL IDENTITY,
  ItemID INT NOT NULL,
  ChangeDate DATETIME NOT NULL,
  ChangeQty INT NOT NULL,
  TotalQty INT NOT NULL,
  PreviousChangeDate DATETIME NULL,
  PreviousTotalQty INT NULL,
  CONSTRAINT PK_Inventory PRIMARY KEY(ItemID, ChangeDate),
  CONSTRAINT UNQ_Inventory UNIQUE(ItemID, ChangeDate, TotalQty),
  CONSTRAINT UNQ_Inventory_Previous_Columns UNIQUE(ItemID, PreviousChangeDate, PreviousTotalQty),
  CONSTRAINT FK_Inventory_Self FOREIGN KEY(ItemID, PreviousChangeDate, PreviousTotalQty)
    REFERENCES Data.Inventory(ItemID, ChangeDate, TotalQty),
  CONSTRAINT CHK_Inventory_Valid_TotalQty CHECK(TotalQty >= 0 AND (TotalQty = COALESCE(PreviousTotalQty, 0) + ChangeQty)),
  CONSTRAINT CHK_Inventory_Valid_Dates_Sequence CHECK(PreviousChangeDate < ChangeDate),
  CONSTRAINT CHK_Inventory_Valid_Previous_Columns CHECK((PreviousChangeDate IS NULL AND PreviousTotalQty IS NULL)
            OR (PreviousChangeDate IS NOT NULL AND PreviousTotalQty IS NOT NULL))
);
GO
-- beginning of inventory for item 1
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
VALUES(1, '20090101', 10, 10, NULL, NULL);
-- cannot begin the inventory for the second time for the same item 1
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
VALUES(1, '20090102', 10, 10, NULL, NULL);

Msg 2627, Level 14, State 1, Line 10
Violation of UNIQUE KEY constraint 'UNQ_Inventory_Previous_Columns'. Cannot insert duplicate key in object 'Data.Inventory'.
The statement has been terminated.

-- add more
DECLARE @ChangeQty INT;
SET @ChangeQty = 5;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20090103', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

SET @ChangeQty = 3;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20090104', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

SET @ChangeQty = -4;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20090105', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

-- try to violate chronological order

SET @ChangeQty = 5;
INSERT INTO Data.Inventory(ItemID,
  ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty)
SELECT TOP 1 ItemID, '20081231', @ChangeQty, TotalQty + @ChangeQty, ChangeDate, TotalQty
  FROM Data.Inventory
  WHERE ItemID = 1
  ORDER BY ChangeDate DESC;

Msg 547, Level 16, State 0, Line 4
The INSERT statement conflicted with the CHECK constraint "CHK_Inventory_Valid_Dates_Sequence". The conflict occurred in database "Test", table "Data.Inventory".
The statement has been terminated.


SELECT ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty
FROM Data.Inventory ORDER BY ChangeDate;

ChangeDate              ChangeQty   TotalQty    PreviousChangeDate      PreviousTotalQty
----------------------- ----------- ----------- ----------------------- -----
2009-01-01 00:00:00.000 10          10          NULL                    NULL
2009-01-03 00:00:00.000 5           15          2009-01-01 00:00:00.000 10
2009-01-04 00:00:00.000 3           18          2009-01-03 00:00:00.000 15
2009-01-05 00:00:00.000 -4          14          2009-01-04 00:00:00.000 18


-- try to change a single row, all updates must fail
UPDATE Data.Inventory SET ChangeQty = ChangeQty + 2 WHERE InventoryID = 3;
UPDATE Data.Inventory SET TotalQty = TotalQty + 2 WHERE InventoryID = 3;
-- try to delete not the last row, all deletes must fail
DELETE FROM Data.Inventory WHERE InventoryID = 1;
DELETE FROM Data.Inventory WHERE InventoryID = 3;

-- the right way to update

DECLARE @IncreaseQty INT;
SET @IncreaseQty = 2;
UPDATE Data.Inventory SET ChangeQty = ChangeQty + CASE WHEN ItemID = 1 AND ChangeDate = '20090103' THEN @IncreaseQty ELSE 0 END,
  TotalQty = TotalQty + @IncreaseQty,
  PreviousTotalQty = PreviousTotalQty + CASE WHEN ItemID = 1 AND ChangeDate = '20090103' THEN 0 ELSE @IncreaseQty END
WHERE ItemID = 1 AND ChangeDate >= '20090103';

SELECT ChangeDate,
  ChangeQty,
  TotalQty,
  PreviousChangeDate,
  PreviousTotalQty
FROM Data.Inventory ORDER BY ChangeDate;

ChangeDate              ChangeQty   TotalQty    PreviousChangeDate      PreviousTotalQty
----------------------- ----------- ----------- ----------------------- ----------------
2009-01-01 00:00:00.000 10          10          NULL                    NULL
2009-01-03 00:00:00.000 7           17          2009-01-01 00:00:00.000 10
2009-01-04 00:00:00.000 3           20          2009-01-03 00:00:00.000 17
2009-01-05 00:00:00.000 -4          16          2009-01-04 00:00:00.000 20

มันเกิดขึ้นกับฉันว่าหนึ่งในข้อ จำกัด อย่างมากของวิธีการของคุณคือการคำนวณยอดคงเหลือของบัญชีในวันที่ในอดีตที่เฉพาะเจาะจงยังคงต้องการการรวบรวมเว้นแต่คุณจะตั้งสมมติฐานว่าการทำธุรกรรมทั้งหมดจะถูกเรียงลำดับตามวันที่ สมมติฐาน)
Chris Travers

@ChrisTravers ผลรวมทั้งหมดที่วิ่งอยู่เสมอที่ทันสมัยสำหรับวันประวัติศาสตร์ทั้งหมด ข้อ จำกัด รับประกันได้ว่า ดังนั้นจึงไม่จำเป็นต้องมีการรวบรวมสำหรับวันประวัติศาสตร์ใด ๆ หากเราต้องอัปเดตแถวประวัติศาสตร์บางส่วนหรือใส่แถวที่ล้าสมัยเราจะอัปเดตยอดรวมทั้งหมดของแถวที่ทำงานในภายหลัง ฉันคิดว่านี่เป็นเรื่องง่ายกว่าใน postgreSql เพราะมีข้อ จำกัด รอการตัดบัญชี
AK

6

นี่เป็นคำถามที่ดีมาก

สมมติว่าคุณมีตารางธุรกรรมที่เก็บแต่ละเดบิต / เครดิตไม่มีอะไรผิดปกติกับการออกแบบของคุณ อันที่จริงฉันได้ทำงานกับระบบ telco แบบเติมเงินที่ทำงานด้วยวิธีนี้

สิ่งสำคัญที่คุณต้องทำคือให้แน่ใจว่าคุณทำSELECT ... FOR UPDATEยอดเงินคงเหลือในขณะที่คุณINSERTเดบิต / เครดิต สิ่งนี้จะรับประกันยอดเงินที่ถูกต้องหากมีสิ่งผิดปกติ (เนื่องจากธุรกรรมทั้งหมดจะถูกย้อนกลับ)

ตามที่คนอื่น ๆ ได้ชี้ให้เห็นคุณจะต้องมีภาพรวมของยอดคงเหลือ ณ ช่วงเวลาที่กำหนดเพื่อตรวจสอบว่าการทำธุรกรรมทั้งหมดในช่วงเวลาที่กำหนดพร้อมกับยอดคงเหลือเริ่มต้น / สิ้นสุดอย่างถูกต้อง เขียนงานแบ็ตช์ที่รันตอนเที่ยงคืนในตอนท้ายของรอบบัญชี (เดือน / สัปดาห์ / วัน) เพื่อทำสิ่งนี้


4

ยอดคงเหลือเป็นจำนวนเงินที่คำนวณตามกฎทางธุรกิจบางอย่างดังนั้นใช่คุณไม่ต้องการเก็บยอดคงเหลือไว้ แต่คำนวณจากธุรกรรมบนบัตรและบัญชี

คุณต้องการติดตามการทำธุรกรรมทั้งหมดบนการ์ดสำหรับการตรวจสอบและการรายงานงบและแม้แต่ข้อมูลจากระบบที่แตกต่างกันในภายหลัง

Bottom line - คำนวณค่าใด ๆ ที่จำเป็นต้องคำนวณและเมื่อคุณต้องการ


แม้ว่าอาจมีธุรกรรม 1,000 รายการ? ดังนั้นฉันจะต้องคำนวณใหม่ทุกครั้งหรือไม่ มันยากกับการแสดงหรือเปล่า? คุณช่วยเพิ่มนิดหน่อยเกี่ยวกับสาเหตุของปัญหานี้ได้ไหม
Mithir

2
@Mithir เพราะขัดต่อกฎการบัญชีส่วนใหญ่และทำให้ไม่สามารถติดตามปัญหาได้ หากคุณเพิ่งอัปเดตผลรวมสะสมคุณจะทราบได้อย่างไรว่าการปรับค่าใดถูกนำไปใช้ ใบแจ้งหนี้นั้นได้รับเครดิตครั้งเดียวหรือสองครั้ง เราหักจำนวนเงินที่ชำระไปแล้วหรือยัง? หากคุณติดตามธุรกรรมที่คุณรู้คำตอบหากคุณติดตามยอดรวมที่คุณทำไม่ได้
JNK

4
การอ้างอิงถึงกฎของ Codd คือมันแบ่งแบบฟอร์มปกติ สมมติว่าคุณติดตามธุรกรรมบางครั้ง (ซึ่งคุณจะต้องคิด) และคุณมีผลรวมการแยกต่างหากซึ่งถูกต้องหากพวกเขาไม่เห็นด้วย? คุณต้องการความจริงเพียงเวอร์ชั่นเดียว อย่าแก้ไขปัญหาด้านประสิทธิภาพจนกว่าจะมีอยู่จริง
JNK

@JNK อย่างที่เป็นอยู่ตอนนี้ - เราทำธุรกรรมและยอดรวมดังนั้นทุกสิ่งที่คุณกล่าวถึงสามารถติดตามได้อย่างสมบูรณ์แบบหากจำเป็นยอดรวมยอดคงเหลือเพียงเพื่อป้องกันไม่ให้เราคำนวณจำนวนเงินใหม่ทุกการกระทำ
Mithir

2
ทีนี้มันจะไม่ทำลายกฎของ Codd ถ้าข้อมูลเก่าอาจถูกเก็บไว้พูด 5 ปีใช่ไหม? ความสมดุล ณ จุดนั้นไม่เพียง แต่ผลรวมของระเบียนที่มีอยู่ แต่ยังรวมถึงระเบียนที่มีอยู่ก่อนหน้านี้ตั้งแต่ถูกลบล้างหรือฉันหายไปบางอย่าง ดูเหมือนว่าฉันจะทำลายกฎของ Codd หากเราถือว่าการเก็บข้อมูลไม่สิ้นสุดซึ่งไม่น่าเป็นไปได้ สิ่งนี้ถูกพูดด้วยเหตุผลที่ฉันพูดด้านล่างฉันคิดว่าการจัดเก็บค่าการอัพเดทอย่างต่อเนื่องกำลังถามถึงปัญหา
Chris Travers
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.