สิ่งที่ต้องพิจารณาเป็นพิเศษในการออกแบบฐานข้อมูลเพื่อเก็บบันทึกทางการเงิน

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

ตอนนี้การสร้างบันทึกทางธุรกรรมทางการเงินอย่างง่ายเป็นเรื่องง่ายในทางทฤษฎี ตารางฐานข้อมูลหนึ่งตารางที่มีคอลัมน์น้อยสามารถทำงานได้ แม้แต่ MS Access, Excel หรือแม้แต่ไฟล์ข้อความ ASCII ธรรมดาก็สามารถใช้เก็บวันที่ทำธุรกรรมรหัสบัญชีและจำนวนเงินดอลล่าร์ได้ อย่างไรก็ตามฉันรู้สึกว่าแม้ตาราง SQL ที่สำรองไว้เป็นประจำซึ่งมีความสมบูรณ์ของธุรกรรมอาจไม่แข็งแกร่งพอสำหรับการติดตามทางการเงินที่ร้ายแรง

ฉันได้ยินคำศัพท์เช่น "double-entry accounting" และฉันรู้สึกว่าแอพติดตามการเงินส่วนใหญ่ (เช่น Mint.com หรือ GnuCash) มีโครงสร้างข้อมูลหรือกระบวนการที่ซับซ้อนมากขึ้นเพื่อให้แน่ใจว่าทุกสิ่ง เพิ่มขึ้นอย่างสมบูรณ์ตามที่ควรและไม่มีข้อมูลสูญหายหรือเสียหาย

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

แก้ไข:

ดูเหมือนว่าฉันจะเปิดเวิร์มกระป๋องขนาดใหญ่กว่าที่ฉันคาดไว้ เพื่อชี้แจงฉันคิดเฉพาะแอพสองประเภท:

1. "ตรวจสอบรีจิสทรี" - แอปประเภทเช่น GnuCash หรือ Quicken ที่เก็บบันทึกการทำธุรกรรมส่วนบุคคลสำหรับการใช้งานของตนเอง
2. แอพที่ติดตามใบแจ้งหนี้ / เครดิต / หรือ "คะแนน" สำหรับผู้ขายและลูกค้าที่จัดการกับ บริษัท

ฉันอาจจะไม่ทำการธนาคารโดยตรงหรือ (AFAIK) สิ่งใดก็ตามที่มีข้อบังคับของรัฐบาลที่เกี่ยวข้องกับการเงินอยู่

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

คุณได้ครอบคลุมปัญหาส่วนใหญ่แล้ว

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

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

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

การตรวจสอบเป็นกุญแจสำคัญในทุกระบบการเงินที่ฉันเคยทำ คุณมีข้อกำหนดพื้นฐาน 2 ข้อ A) คุณสามารถติดตามทุกการเปลี่ยนแปลงที่เกิดขึ้นกับข้อมูลโดยใครเมื่อใดและเพราะเหตุใด B) คุณสามารถพิสูจน์สถานะทางประวัติศาสตร์ของข้อมูลของคุณได้หรือไม่? ว่ามันไม่ได้ถูกดัดแปลงด้วย?

A) เป็นสิ่งจำเป็นสำหรับทีมปฏิบัติการ - ระบบของคุณจะถูกใช้ใน 100 วิธีที่คุณไม่เคยคาดคิดมาก่อนและข้อมูลนี้มีความสำคัญต่อการขยายตัวการรายงานเฉพาะกิจเหตุผลทางกฎหมายและการแก้ไขข้อบกพร่อง

B) ดูกรณี AMEX กับ Vee Vinhnee - ที่ AMEX ไม่สามารถรวบรวม 40k เป็นหนี้กับพวกเขาเนื่องจากพวกเขาไม่สามารถพิสูจน์ได้ว่าบันทึกของพวกเขาไม่ได้ถูกสร้างขึ้น การแก้ปัญหาที่ใช้โดยทั่วไปสำหรับการนี้คือการประทับเวลาที่เชื่อถือได้ สถาบันการเงินขนาดใหญ่มีธนาคารผู้ค้ำประกันที่รับประกันการทำธุรกรรมและให้การรับรองเวลาที่เชื่อถือได้โดยเนื้อแท้ มีผู้ให้บริการเชิงพาณิชย์สำหรับสิ่งนี้สำหรับวิถีชีวิต / สถานการณ์อื่น ๆ

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

แต่เพื่อให้ลูกค้าของคุณได้รับอนุญาตให้ใช้งานคุณต้องทำตามกฎหมายท้องถิ่นของคุณ บางสิ่งที่ฉันพบ (ในเยอรมนี)

• รูปแบบเอกสารสำหรับเรื่องการจัดเก็บเพราะมีกฎหมายที่ธุรกิจจะต้องเก็บเอกสารของพวกเขาเป็นเวลา 10 ปี ใน 10 ปีโปรแกรมของคุณอาจไม่สามารถใช้งานได้อีกต่อไป ดังนั้นคุณต้องจัดเก็บเอกสารตามวิธีการที่ได้รับการรับรอง DIN / ISO (.pdf ดูเหมือนว่าเพียงพอในเยอรมนี)
• บ่อยครั้งที่เส้นทางการตรวจสอบมีความจำเป็นเช่นคุณอาจต้องนำเสนอเอกสารเวอร์ชันเดียวกันหลายเวอร์ชันพร้อมวันที่แก้ไข
• ตำแหน่งของที่เก็บข้อมูลมีความสำคัญเนื่องจาก 'Datenschutz' (ความเป็นส่วนตัว) ซึ่งอาจแตกต่างกันในประเทศที่จัดเก็บ สิ่งนี้ทำให้บริการบนคลาวด์ยุ่งยากเล็กน้อย
• เอกสารบางอย่างที่จะต้องมีการเก็บไว้ในทางที่ไม่แน่นอน ความสำเร็จนี้ดูเหมือนว่าจะขึ้นอยู่กับ nitpicking ตามกฎหมายเป็นส่วนใหญ่ (กระดาษไม่เปลี่ยนรูปได้, ซีดีไม่แน่นอน, ซีดีที่ลงนามโดยคนงานไม่ได้)

คุณควรติดต่อทนายความเพื่อขอข้อมูลเฉพาะหรืออย่างน้อยก็ต้องทำงานร่วมกับลูกค้าอย่างใกล้ชิด

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

สิ่งที่เลวร้ายที่สุดคือต้องเสียค่าธรรมเนียมบัตรเครดิต แต่ไม่มีการบันทึกทุกอย่างที่มีไว้ใช้หรือเป็นของใคร ฯลฯ

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

[1] ใช้ตารางความปลอดภัย (อย่าสับสนกับผู้ใช้ฐานข้อมูลภายใน) สำหรับผู้ใช้และสำหรับแอปของคุณ โมดูลฟอร์มหน้าเว็บ:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] อย่าลบบันทึกในแอปของคุณใช้ฟิลด์สถานะอาจเป็นจำนวนเต็มอาจเป็นบูลีนหรือบิตที่ระบุว่าบันทึกนั้นเป็น "ลบ" แล้ว ทำให้แอพของคุณ แสดงระเบียนที่ไม่ถูกลบ (ทำเครื่องหมายว่าถูกลบโดยเขตข้อมูลนั้น) และสร้างแบบฟอร์มกรณีพิเศษบางแอป จะแสดงบันทึกที่ทำเครื่องหมายว่าลบแล้ว

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

คุณสมบัตินี้เรียกว่า "การลบเสมือน" การลบที่แท้จริงเรียกว่า "การลบทางกายภาพ" อย่างอิสระ

[3] ใช้ฟิลด์ในตารางทั้งหมดที่เกี่ยวข้องกับการเข้าถึงจัดเก็บผู้ใช้ (เดี่ยว) ที่สร้างเรคคอร์ดและผู้ใช้ (สุดท้าย) ที่เปลี่ยนเรคคอร์ดและ datetime ถ้าเป็นไปได้ให้เพิ่มโมดูลหรือตัวเลือกที่แต่ละเรคคอร์ดคือ การแก้ไข:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[4] ในบางกรณีค่าสกุลเงินหรือค่าเงินอาจส่งผลต่อผลลัพธ์เมื่อใช้หลายระเบียนในรายละเอียดและเพิ่มลงในค่าเดียวคือบันทึกส่วนหัว ina

แบรนด์ฐานข้อมูลส่วนใหญ่รองรับวันนี้เขตข้อมูลสกุลเงินหรือเงิน ใช้มัน.

ในบางสถานการณ์พิเศษบางคนเก็บไว้ในค่าทศนิยมคงที่ที่สนับสนุนตัวเลขทศนิยมหลาย ("ทศนิยม") หรือแม้กระทั่งเป็นค่าสตริง

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

ไชโย [อย่าลืมให้ปลาทูน่ากระป๋องกับคิตตี้หรือโหวตไม่ได้]

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

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

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

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

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

ฉันจะไม่ใช้งานแอพพลิเคชั่นทางการเงินทุกชนิดโดยไม่ต้องอ่าน GAAP (ในสหรัฐอเมริกาประเทศอื่น ๆ มีมาตรฐานการบัญชีของตนเอง) อย่างถี่ถ้วนและการมี CPA เป็นที่ปรึกษาเนื่องจากการปฏิบัติด้านบัญชีที่ไม่ถูกต้อง นี่เป็นเขตข้อมูลด้านเทคนิคสูงและมีคนที่ไม่มีความรู้ที่จำเป็นไม่มีธุรกิจที่พยายามสร้างซอฟต์แวร์ในพื้นที่นี้

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

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

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

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

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

อย่างที่คุณเห็นทุกธุรกรรมย่อยบัญชีแยกประเภทหุ้นสัมพันธ์โดยตรงกับบัญชีแยกประเภททั่วไป

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

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

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

BTW เมื่อคุณจัดการกับการปัดเศษลองไปกับทศนิยมแทนการลอยมันจะช่วยให้คุณปวดหัวมากลงไปที่ถนน : P