কোন মানটি কী কোনও টেবিলে আপডেট করা ঠিক আছে?


31

আমরা প্রিপেইড কার্ডগুলির জন্য একটি প্ল্যাটফর্ম বিকাশ করছি, যা মূলত কার্ড এবং তাদের ভারসাম্য, প্রদান ইত্যাদি সম্পর্কে ডেটা ধারণ করে

এখনও অবধি আমাদের কাছে একটি কার্ড সত্তা রয়েছে যার অ্যাকাউন্ট সত্তার সংকলন রয়েছে এবং প্রতিটি অ্যাকাউন্টে একটি পরিমাণ থাকে, যা প্রতিটি আমানত / প্রত্যাহারে আপডেট হয়।

দলে এখন বিতর্ক আছে; কেউ আমাদের বলেছেন যে এটি বিরতি দেয় কোডের 12 টি নিয়ম এবং প্রতিটি অর্থ প্রদানের ক্ষেত্রে এর মান আপডেট করা সমস্যা।

এটা কি আসলেই সমস্যা?

যদি তা হয় তবে আমরা কীভাবে এটি ঠিক করতে পারি?


3
ডিবিএ.এসইতে এই বিষয়টিতে এখানে একটি বিস্তৃত প্রযুক্তিগত আলোচনা রয়েছে: একটি সাধারণ ব্যাংক স্কিমা লেখা
নিক চামাস

1
আপনার দল এখানে কোডডের কোন নিয়ম তুলে ধরেছে? নিয়মগুলি ছিল একটি সম্পর্কিত সিস্টেমকে সংজ্ঞায়িত করার প্রয়াস এবং সাধারণভাবে স্পষ্টভাবে উল্লেখ করেনি। কোডড তার বইতে নরমালাইজেশন নিয়ে আলোচনা করেছিলেন ডাটাবেস পরিচালনার জন্য সম্পর্কিত মডেল
আইয়েন স্যামুয়েল ম্যাকলিন বয়স্ক

উত্তর:


30

হ্যাঁ, এটি অ-নর্মালাইজড, তবে মাঝেমধ্যে অ-নর্মালাইজড ডিজাইনগুলি কার্য সম্পাদনের কারণে জয়ী হয়।

তবে, সুরক্ষার কারণে আমি সম্ভবত এটি একটু ভিন্নভাবে পৌঁছে দেব। (অস্বীকৃতি: আমি বর্তমানে নেই, বা আমি কখনও আর্থিক খাতেও কাজ করি নি I'm আমি কেবল এটি এখানে ফেলে দিচ্ছি))

কার্ডগুলিতে পোস্ট ব্যালেন্সের জন্য একটি টেবিল রাখুন। এটিতে প্রতিটি অ্যাকাউন্টের জন্য একটি সারি সন্নিবেশ করা হবে, প্রতিটি পিরিয়ডের শেষে (দিন, সপ্তাহ, মাস, বা উপযুক্ত যা কিছু) পোস্ট করা ভারসাম্য নির্দেশ করে। অ্যাকাউন্ট নম্বর এবং তারিখ অনুসারে এই টেবিলটিকে সূচক করুন।

মুলতুবি লেনদেনগুলি ধরে রাখার জন্য অন্য একটি সারণী ব্যবহার করুন, যা ফ্লাইতে .োকানো হয়। প্রতিটি পিরিয়ডের শেষে, একটি নিত্যনৈমিত্তিক চালান যা অ্যাকাউন্টের শেষ বন্ধ হওয়া ব্যালেন্সে আনপোস্টেড লেনদেনগুলিকে নতুন ব্যালেন্স গণনা করতে যোগ করে। হয় পোস্ট হিসাবে মুলতুবি লেনদেন চিহ্নিত করুন, বা এখনও কি মুলতুবি আছে তা নির্ধারণ করার জন্য তারিখগুলি দেখুন।

এইভাবে, আপনার অ্যাকাউন্টের সমস্ত ইতিহাসের যোগফল ছাড়াই চাহিদা অনুসারে কার্ডের ভারসাম্য গণনা করার একটি মাধ্যম রয়েছে এবং একটি উত্সর্গীকৃত পোস্টের রুটিনে ব্যালেন্সের পুনঃব্যবস্থা স্থাপনের মাধ্যমে আপনি নিশ্চিত করতে পারেন যে এই পুনঃব্যবস্থার লেনদেনের সুরক্ষা সীমাবদ্ধ রয়েছে একটি একক স্থান (এবং ব্যালেন্স টেবিলের উপর সুরক্ষাও সীমাবদ্ধ করে তাই কেবল পোস্টিং রুটিন এতে লিখতে পারে)।

তারপরে নিরীক্ষণ, গ্রাহক পরিষেবা এবং পারফরম্যান্স প্রয়োজনীয়তার দ্বারা প্রয়োজনীয় historicতিহাসিক ডেটা কেবল রাখুন।


1
মাত্র দুটি দ্রুত নোট। প্রথমটি যে আমি উপরে প্রস্তাব করছি লগ-সমষ্টি-স্ন্যাপশট পদ্ধতির খুব ভাল বর্ণনা এবং সম্ভবত আমার চেয়ে আরও পরিষ্কার। (আপনাকে উত্সাহিত) দ্বিতীয়ত, আমার সন্দেহ হয় আপনি এখানে "পোস্ট করা" শব্দটি কিছুটা অদ্ভুতভাবে ব্যবহার করছেন, যার অর্থ "ক্লোজিং ব্যালেন্সের অংশ" to আর্থিক ক্ষেত্রে, পোস্টের অর্থ সাধারণত "বর্তমানের খাত্তরের ভারসাম্য দেখানো" এবং সুতরাং মনে হয়েছিল এটি ব্যাখ্যা করার মতো এটি তাই বিভ্রান্তির কারণ হয় নি।
ক্রিস ট্র্যাভারস

হ্যাঁ, সম্ভবত আমি প্রচুর সূক্ষ্মতাগুলি মিস করছি। আমি কেবল ব্যবসায়ের কাছাকাছি সময়ে আমার চেকিং অ্যাকাউন্টে কীভাবে লেনদেনগুলি "পোস্ট" হয়ে দেখায় এবং সেই অনুযায়ী ভারসাম্য আপডেট হয় তার উল্লেখ করছি। তবে আমি হিসাবরক্ষক নই; আমি তাদের বেশিরভাগের সাথেই কাজ করি।
db2

এই হতে পারে এছাড়াও সক্স জন্য প্রয়োজন বা ভবিষ্যতে মত হতে, আমি ঠিক কি আপনি লগ ইন করতে হবে মাইক্রো-লেনদেন প্রয়োজনীয়তা সাজানোর জানি না, কিন্তু আমি defo জানেন কেউ কি প্রতিবেদনের প্রয়োজনীয়তা পরবর্তী সময়ের জন্য জিজ্ঞাসা করবে।
jcolebrand

আমি প্রতি বছরের শুরুতে উদাহরণস্বরূপ ভারসাম্য রক্ষার জন্য চিরস্থায়ী তথ্য রাখার প্রবণতা পোষণ করব, যাতে "মোট" স্ন্যাপশটটি কখনই ওভাররাইট না হয়ে যায় - তালিকাটি সহজেই সংযুক্ত হয়ে যায় (এমনকি প্রতিটি অ্যাকাউন্টের জন্য সিস্টেম দীর্ঘ সময় ব্যবহারে না থাকলেও) এক্ষেত্রে 1000 বার্ষিক মোট সংগ্রহ [ খুব আশাবাদী], যা খুব কমই পরিচালিত হবে না)। বহু বার্ষিক মোট পরিমাণ রাখলে নিরীক্ষণ কোডটি নিশ্চিত করতে সক্ষম হয় যে সাম্প্রতিক বছরগুলির মধ্যে লেনদেনের মোটের উপর যথাযথ প্রভাব ছিল [স্বতন্ত্র লেনদেনগুলি 5 বছরের পরে মুছে ফেলা হতে পারে তবে ততক্ষণে ভাল পরীক্ষা করা হবে]।
সুপারক্যাট

17

অন্যদিকে, একটি সমস্যা রয়েছে যা আমরা অ্যাকাউন্টিং সফ্টওয়্যারটিতে প্রায়শই চালাচ্ছি। Paraphrased:

চেকিং অ্যাকাউন্টে কত টাকা আছে তা জানতে আমার কী সত্যিই দশ বছরের ডেটা সংগ্রহ করতে হবে?

অবশ্যই উত্তর আপনি না। এখানে কয়েকটি পন্থা রয়েছে। এক গণনা করা মান সংরক্ষণ করছে। আমি এই পদ্ধতির প্রস্তাব দিচ্ছি না কারণ সফ্টওয়্যার বাগগুলি যা ভুল মানগুলির কারণ হতে পারে তা ট্র্যাক করা খুব শক্ত এবং তাই আমি এই পদ্ধতিটি এড়াতে পারি।

এটি করার আরও ভাল উপায় হ'ল আমি লগ-স্ন্যাপশট-সামগ্রিক পদ্ধতির কল call এই পদ্ধতির মধ্যে আমাদের অর্থ প্রদান এবং ব্যবহারগুলি সন্নিবেশ করানো হয় এবং আমরা কখনই এই মানগুলি আপডেট করি না। পর্যায়ক্রমে আমরা সময়ের সাথে সাথে ডেটা একত্রিত করি এবং একটি গণনাযুক্ত স্ন্যাপশট রেকর্ড সন্নিবেশ করি যা স্ন্যাপশটটি বৈধ হওয়ার সময় ডেটা উপস্থাপন করে (সাধারণত উপস্থিত হওয়ার আগে সাধারণত একটি সময়কাল )।

এখন এটি কোডের নিয়মগুলি ভঙ্গ করে না কারণ সময়ের সাথে সাথে স্ন্যাপশটগুলি sertedোকানো পেমেন্ট / ব্যবহারের ডেটার উপর পুরোপুরি নির্ভরশীলতার চেয়ে কম হতে পারে। আমাদের যদি স্ন্যাপশট কাজ করে থাকে তবে আমরা চাহিদা অনুসারে বর্তমানের ভারসাম্যগুলি গণনা করার ক্ষমতাকে প্রভাবিত না করে 10 বছরের পুরানো তথ্য মুছে ফেলার সিদ্ধান্ত নিতে পারি।


2
আমি গণনা করা চলমান মোট সঞ্চয় করতে পারি এবং আমি পুরোপুরি নিরাপদ - বিশ্বস্ত প্রতিবন্ধকতা আমার সংখ্যা সর্বদা সঠিক তা নিশ্চিত করে: sqlblog.com/blogs/alexender_kuznetsov/archive/2009/01/23/…
এ কে

1
আমার সমাধানে কোনও প্রান্তের কেস নেই - একটি বিশ্বস্ত প্রতিবন্ধকতা আপনাকে কোনও কিছু ভুলতে দেয় না। আমি বাস্তব জীবন ব্যবস্থায় নুল পরিমাণের কোনও ব্যবহারিক প্রয়োজন দেখছি না যা চলমান মোট জানতে হবে - এগুলি একে অপরের বিরোধিতা করে। আপনি যদি ব্যবহারিক প্রয়োজন দেখেন তবে দয়া করে আপনার দৃশ্যগুলি ভাগ করুন।
একে

1
ঠিক আছে, তবে তারপরে এটি ডিবি'র মতো কাজ করবে না যা স্বতন্ত্রতা লঙ্ঘন না করে একাধিক এনএলএল অনুমতি দেয়, তাই না? এছাড়াও আপনার গ্যারান্টি খারাপ হয়ে যায় যদি আপনি অতীতের ডেটাগুলি পরিষ্কার করেন, তাই না?
ক্রিস ট্র্যাভারস

1
উদাহরণস্বরূপ যদি পোস্টগ্রিজ এসকিউএল-এ আমার (ক, খ) এক অনন্য বাধা থাকে, আমি (ক, খ) এর জন্য একাধিক (১, নাল) মান রাখতে পারি কারণ প্রতিটি নালকে সম্ভাব্য অনন্য হিসাবে ধরা হয়, যা আমি মনে করি অজানা জন্য শব্দার্থগতভাবে সঠিক মান .....
ক্রিস ট্র্যাভারস

1
"পোস্টগ্রিজ এসকিউএল-এ আমার (ক, খ) এর উপর একটি অনন্য বাধা আছে, আমার একাধিক (1, নাল) মান থাকতে পারে" - পোস্টগ্র্যাসকিএল-এ আমাদের (ক) উপর একটি অনন্য আংশিক সূচক ব্যবহার করা উচিত যেখানে খ নাল হয়।
একে

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

এটি আমার কাছে ঘটেছিল যে আপনার পদ্ধতির বিশাল সীমাগুলির মধ্যে একটি হ'ল নির্দিষ্ট historicalতিহাসিক তারিখে কোনও অ্যাকাউন্টের ভারসাম্য গণনা করার জন্য এখনও একত্রিত হওয়া দরকার, আপনি যদি এই ধারণাও না করেন যে সমস্ত লেনদেন যথাক্রমে তারিখ অনুসারে প্রবেশ করা হয়েছে (যা সাধারণত খারাপ হয়) ধৃষ্টতা).
ক্রিস ট্র্যাভারস

@ ক্রিসট্রেভারগুলি সমস্ত চলমান মোটগুলি সব upতিহাসিক তারিখের জন্য সর্বদা আপ টু ডেট থাকে। সীমাবদ্ধতা যে গ্যারান্টি দেয়। সুতরাং কোনও historicতিহাসিক তারিখের জন্য কোনও সমাহার প্রয়োজন হয় না। আমাদের যদি কিছু historicতিহাসিক সারি আপডেট করতে হয়, বা কোনও ব্যাক-তারিখ সন্নিবেশ করানো হয় তবে আমরা পরবর্তী সমস্ত সারিগুলির চলমান মোটগুলি আপডেট করি। আমি মনে করি পোস্টগ্রিকস্কুয়ালে এটি অনেক সহজ, কারণ এতে সীমাবদ্ধতা স্থগিত হয়েছে।
একে

6

এটি একটি খুব ভাল প্রশ্ন।

ধরে নিই যে আপনার একটি লেনদেনের সারণি রয়েছে যা প্রতিটি ডেবিট / ক্রেডিট সঞ্চয় করে, আপনার নকশায় কোনও ভুল নেই। আসলে, আমি প্রিপেইড টেল্কো সিস্টেমের সাথে কাজ করেছি যা ঠিক এইভাবে কাজ করেছে।

আপনার যে প্রধান জিনিসটি করা দরকার তা হ'ল আপনি SELECT ... FOR UPDATEথাকাকালীন ভারসাম্যটি কিছু করছেনINSERTআপনার ডেবিট / ক্রেডিট করার যে । কিছু ভুল হয়ে গেলে এটি সঠিক ব্যালেন্সের গ্যারান্টি দিবে (কারণ পুরো লেনদেনটি আবার ফিরিয়ে দেওয়া হবে)।

অন্যরা যেমন নির্দেশ করেছে, আপনার নির্দিষ্ট সময়কালে সমস্ত লেনদেনের সময়কালের সমাপ্তি / শেষের ভারসাম্য সঠিকভাবে নিশ্চিত হওয়ার জন্য আপনার নির্দিষ্ট সময়ের মধ্যে ব্যালেন্সগুলির স্ন্যাপশট প্রয়োজন। এটি করার জন্য পিরিয়ড শেষে (মাস / সপ্তাহ / দিন) এ মধ্যরাতে চলে এমন একটি ব্যাচের কাজ লিখুন।


4

ব্যালেন্সটি নির্দিষ্ট ব্যবসায়ের নিয়মের ভিত্তিতে একটি গণনা করা পরিমাণ, সুতরাং হ্যাঁ আপনি ভারসাম্যটি রাখতে চান না বরং কার্ডে এবং সেইজন্য অ্যাকাউন্টের লেনদেন থেকে এটি গণনা করতে চান।

আপনি নিরীক্ষণ এবং বিবৃতি প্রতিবেদনের জন্য কার্ডে সমস্ত লেনদেন এবং এমনকি পরে বিভিন্ন সিস্টেমের ডেটা রাখতে চান।

নীচের লাইন - এমন কোনও মানগুলি গণনা করুন যা আপনাকে যখন প্রয়োজন হিসাবে গণনা করতে হবে


এমনকি যদি লেনদেনের সংখ্যাও থাকতে পারে? সুতরাং আমি কি প্রতিবার এটির সংশোধন করা দরকার? পারফরম্যান্সে এটা একটু কঠিন হতে পারে না? আপনি কেন এই জাতীয় সমস্যা এটি সম্পর্কে কিছুটা যুক্ত করতে পারেন?
মিথির

2
@ মিথির কারণ এটি অ্যাকাউন্টিংয়ের বেশিরভাগ নিয়মের বিপরীতে এবং এটি সমস্যার সন্ধান করা অসম্ভব করে তোলে। আপনি যদি কেবল একটি চলমান মোট আপডেট করেন তবে আপনি কীভাবে জানবেন কোনগুলি সমন্বয় প্রয়োগ করা হয়েছে? সেই চালানটি কি একবার বা দুবার জমা হয়েছিল? আমরা ইতিমধ্যে পেমেন্টের পরিমাণ কেটে দিয়েছি? আপনি যদি লেনদেনগুলি ট্র্যাক করেন তবে উত্তরগুলি জানেন, আপনি যদি মোটটি ট্র্যাক করেন তবে।
জেএনকে

4
কোডের নিয়মের উল্লেখটি হ'ল এটি স্বাভাবিক ফর্মটি ভেঙে দেয়। ধরে নিচ্ছি আপনি লেনদেনের কিছুটা ট্র্যাক করেন (যা আপনার আমার মনে করতে হবে), এবং আপনার পৃথক একটি মোট চলমান আছে, যদি তারা একমত না হন তবে এটি সঠিক? আপনার সত্যের একক সংস্করণ দরকার। কার্যকারিতা ইস্যুটি উপস্থিত না হওয়া অবধি / ঠিক করবেন না।
জেএনকে

@ জেএনকে এখন যেভাবে চলছে - আমরা লেনদেন এবং মোট রাখি, সুতরাং আপনার উল্লেখ করা সমস্ত কিছুই প্রয়োজনে নিখুঁতভাবে অনুসরণ করা যেতে পারে, ব্যালেন্স মোটটি প্রতিটি ক্রিয়াকলাপের পরিমাণটি পুনরায় গণনা থেকে রোধ করার জন্য।
মিথির

2
এখন, এটি কোডের নিয়মগুলি ভঙ্গ করবে না যদি পুরানো তথ্য কেবল 5 বছর ধরে রাখা যায়, তাই না? এই সময়ে ভারসাম্যটি কেবল বিদ্যমান রেকর্ডগুলির যোগফল নয়, পূর্ববর্তী বিদ্যমান রেকর্ডগুলি শুদ্ধ হওয়ার পরে, বা আমি কিছু হারিয়ে যাচ্ছি? আমার কাছে মনে হচ্ছে এটি কেবল কোডের নিয়মগুলি ভঙ্গ করবে যদি আমরা অসীম ডেটা ধরে রাখার বিষয়টি অনুমান করি তবে এটি অসম্ভব। এটি নীচে বলার কারণে এই কারণেই বলা হচ্ছে, আমি মনে করি ধারাবাহিকভাবে আপডেট হওয়া মান সংরক্ষণ করা সমস্যার জন্য জিজ্ঞাসা করছে।
ক্রিস ট্র্যাভারস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.