Những cân nhắc đặc biệt nào là cần thiết khi thiết kế cơ sở dữ liệu để lưu giữ hồ sơ tài chính?

Tôi hy vọng câu hỏi này không quá rộng. Trong tương lai tôi có thể cần thêm một số hệ thống theo dõi tài chính và kế toán vào một số ứng dụng (chủ yếu là các ứng dụng dựa trên web, nhưng câu hỏi của tôi cũng liên quan đến các ứng dụng trên máy tính để bàn).

Bây giờ, việc tạo một bản ghi đơn giản về các giao dịch tài chính về mặt lý thuyết là dễ dàng. Một bảng cơ sở dữ liệu với một vài cột có thể thực hiện công việc. Ngay cả MS Access, Excel hoặc thậm chí chỉ là một tệp văn bản ASCII đơn giản cũng có thể được sử dụng để lưu trữ ngày giao dịch, ID tài khoản và số tiền. Tuy nhiên, tôi cảm thấy rằng ngay cả một bảng SQL được sao lưu thường xuyên với tính toàn vẹn giao dịch có thể không đủ mạnh để theo dõi tài chính nghiêm túc.

Tôi nghe các thuật ngữ như "kế toán kép" và tôi có cảm giác rằng hầu hết các ứng dụng theo dõi tài chính (ví dụ: Mint.com hoặc GnuCash) có cấu trúc dữ liệu hoặc quy trình phức tạp hơn nhiều để đảm bảo chắc chắn rằng mọi thứ đều chắc chắn cộng lại một cách hoàn hảo, chính xác như nó cần, và rằng không có dữ liệu nào bị mất hoặc bị hỏng.

Câu hỏi của tôi là: Khi thiết kế một ứng dụng để theo dõi các giao dịch tài chính, cần cân nhắc thiết kế đặc biệt nào? Dường như có thể có rất nhiều vấn đề tiềm ẩn ... các vấn đề với độ chính xác làm tròn, kiểm tra chẵn lẻ, một số loại quy trình kiểm toán, sao lưu đặc biệt, bảo mật / mã hóa, các cách bổ sung để bảo vệ dữ liệu trong trường hợp nhập dữ liệu giữa chừng. ... Tôi không thực sự biết những gì tôi nên hỏi cụ thể, nhưng tôi có cảm giác rằng ngành lập trình có một tập hợp thực tiễn tốt nhất mà tôi không biết gì về nó. Họ là ai?

Biên tập:

Có vẻ như tôi đã mở một lon giun lớn hơn tôi mong đợi. Để làm rõ, tôi đang nghĩ cụ thể về hai loại ứng dụng:

1. "Kiểm tra sổ đăng ký" -những ứng dụng như GnuCash hoặc Quicken duy trì hồ sơ về các giao dịch cá nhân để sử dụng riêng.
2. Các ứng dụng theo dõi hóa đơn / tín dụng / hoặc "điểm" cho các nhà cung cấp và khách hàng giao dịch với một công ty.

Tôi có thể sẽ không thực hiện bất kỳ hoạt động ngân hàng trực tiếp hoặc (AFAIK) bất cứ điều gì có hàng tấn các quy định của chính phủ liên quan đến tài chính.

Bạn chắc chắn sẽ nhận được nhiều câu trả lời cho điều này. Tôi chắc chắn, nhiều câu trả lời duy tâm cũng vậy, tôi chỉ có thể trả lời từ kinh nghiệm của mình với tài chính và những gì thực sự diễn ra.

Bạn đã bao gồm phần lớn các vấn đề.

Độ chính xác làm tròn có xu hướng không thực sự là một vấn đề trong kinh nghiệm của tôi. Phần lớn các tổ chức tài chính lớn đã không phát triển chỉ sau một đêm (tức là mọi thứ trừ quỹ phòng hộ) có một loạt các ứng dụng kế thừa được tách ra do nhiều loại nhiên liệu. Họ có xu hướng không làm tròn chính xác một cách nhất quán; nói chung một khoản lãi và lỗ nhất định chỉ đơn giản được chấp nhận để làm tròn. Thật vậy, nhiều giờ làm việc của con người đã được sử dụng ở những nơi tôi từng làm việc ở đó con người nơi những người chọn 'cuối cùng đủ gần' khi nói đến việc khớp với số tiền chính xác / dự kiến. Hãy nhớ rằng, đây là một câu trả lời dựa trên thực tế, không phải những gì nên xảy ra.

Mã hóa - đừng dựa vào nó một cách thẳng thắn. Lưu trữ dữ liệu nhận dạng trong một hệ thống riêng biệt về mặt vật lý và logic so với dữ liệu được nhận dạng (ví dụ mã tài khoản ở mọi nơi, dữ liệu cá nhân riêng biệt).

Nói chung, trong khi các bản sao lưu được yêu cầu, các bản sao lưu ngoại tuyến hiếm khi được gọi vào - mọi thứ đã trở nên sai lầm tại thời điểm đó. Bản sao sản xuất ấm thường được yêu cầu - tuy nhiên điều này sẽ phụ thuộc vào nhu cầu cụ thể của riêng bạn. Trong thực tế chung, chúng tôi có một bản sao sản xuất tại chỗ ấm áp của tất cả các hệ thống VÀ một trang web khắc phục thảm họa với sản xuất riêng và các bản sao ấm áp. Bản sao ấm có xu hướng chậm một vài phút trong bản sao, vv

Kiểm toán là chìa khóa cho mọi hệ thống tài chính mà tôi từng làm việc. Bạn có 2 yêu cầu cơ bản A) Bạn có thể theo dõi từng thay đổi được thực hiện cho dữ liệu, bởi ai, khi nào và tại sao? B) Bạn có thể chứng minh trạng thái lịch sử của dữ liệu của bạn? Rằng nó không bị giả mạo?

A) là bắt buộc cho các nhóm hoạt động - hệ thống của bạn sẽ được sử dụng theo 100 cách bạn không bao giờ mong đợi và thông tin này rất quan trọng để mở rộng, báo cáo đột xuất, lý do pháp lý và gỡ lỗi.

B) Xem trường hợp AMEX so với Vee Vinhnee - nơi AMEX không thể thu 40k nợ họ vì họ không thể chứng minh rằng hồ sơ của họ không được tạo thành. Các giải pháp thường được sử dụng cho điều này là dập thời gian đáng tin cậy. Các tài chính lớn có các ngân hàng bảo lãnh đảm bảo các giao dịch và do đó vốn cung cấp thời gian đáng tin cậy. Có các nhà cung cấp thương mại cho điều này cho các cuộc sống / kịch bản khác.

Những cân nhắc chủ yếu là hợp pháp . Nếu bạn chỉ nhìn vào nó từ góc độ an toàn / độ tin cậy, một tờ excel có thể không an toàn vốn có so với một tờ giấy trong một số ngăn kéo. Tính toàn vẹn giao dịch của Access có thể tốt hơn so với nhân viên bán hàng bị gián đoạn bởi một cuộc gọi.

Nhưng, để khách hàng của bạn được phép sử dụng nó, bạn phải thực hiện theo luật pháp địa phương. Một số điều tôi gặp phải (ở Đức)

• Định dạng tài liệu cho vấn đề lưu trữ , bởi vì có luật pháp mà các doanh nghiệp phải giữ giấy tờ của họ trong 10 năm. Trong 10 năm, có thể chương trình của bạn không còn nữa. Do đó, bạn phải lưu trữ tài liệu theo cách được chứng nhận DIN / ISO (.pdf dường như đủ ở Đức)
• Trails Trails thường là cần thiết, ví dụ bạn có thể phải trình bày các phiên bản khác nhau của cùng một tài liệu, với ngày sửa đổi.
• Vị trí của các vấn đề lưu trữ , vì 'Datenschutz' (quyền riêng tư), có thể khác nhau ở quốc gia lưu trữ. Điều này làm cho các dịch vụ dựa trên đám mây có một chút khó khăn.
• Một số tài liệu phải được lưu trữ theo cách không thể thay đổi . Làm thế nào chính xác điều này đạt được dường như phụ thuộc chủ yếu vào nitpicking hợp pháp (một bài báo là bất biến, một cd là có thể thay đổi, một cd được ký bởi một công nhân là không)

Bạn chắc chắn nên liên hệ với một luật sư, để biết cụ thể, hoặc ít nhất là làm việc trong quan hệ đối tác chặt chẽ với khách hàng.

Các yếu tố độ tin cậy trở nên quan trọng đáng kinh ngạc khi bạn giao dịch với tiền của mọi người. Nếu Twitter mất một tweet, đó không phải là vấn đề lớn; nếu bạn tính phí thẻ tín dụng của ai đó nhưng mất đơn đặt hàng của họ, ai đó trong tổ chức của bạn sẽ nhận được một tiếng vang từ một khách hàng tức giận. Vì vậy, có hai điều: 1. Bạn không muốn điều đó xảy ra ngay từ đầu, nhưng 2. điều đó cuối cùng sẽ xảy ra cho dù bạn có cẩn thận đến đâu, vì vậy bạn muốn đưa RẤT NHIỀU năng lượng vào loại cơ chế ghi nhật ký và truy tìm điều đó sẽ giúp bạn quay lại và tìm ra thứ tự "bị mất" và khắc phục tình hình.

Điều tồi tệ nhất tuyệt đối là, ví dụ, có một khoản phí thẻ tín dụng, nhưng KHÔNG ghi lại tất cả những gì nó dành cho, hoặc nó thuộc về ai, v.v.

Đối với các công cụ tài chính, bạn thực sự cần phải suy nghĩ ngay cả các kịch bản dường như siêu khả thi và lên kế hoạch xử lý chúng: "Chúng tôi đã tính phí thẻ tín dụng, nhưng máy chủ cơ sở dữ liệu đã ngừng hoạt động trước khi chúng tôi có thể cập nhật hồ sơ tương ứng." Được rồi, làm sao bây giờ? Vô hiệu phí? Đăng nhập giao dịch vào một tập tin để con người có thể sửa nó sau? Ok, nếu đĩa đầy và bạn không thể ghi vào tệp thì sao? Vân vân.

[1] Sử dụng các bảng bảo mật (không gây nhầm lẫn với người dùng DB nội bộ) cho người dùng và cho ứng dụng của bạn. mô-đun, biểu mẫu, trang web:

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

[2] Không xóa các bản ghi trong ứng dụng của bạn., Sử dụng trường trạng thái, có thể là số nguyên, có thể là boolean hoặc bit, cho biết bản ghi đó được coi là "đã xóa". Làm cho bạn ứng dụng. hiển thị các bản ghi không bị xóa (được đánh dấu là đã xóa, bởi trường đó) và tạo một số biểu mẫu trường hợp đặc biệt, trong đó ứng dụng. không hiển thị các hồ sơ được đánh dấu là đã xóa.

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

Tính năng này được gọi là "xóa ảo". Việc xóa thực sự được gọi là "xóa vật lý".

[3] Sử dụng các trường trong tất cả các bảng liên quan đến truy cập, lưu trữ người dùng (đơn) tạo bản ghi và người dùng (cuối cùng) đã thay đổi bản ghi và datetime, nếu có thể, hãy thêm mô-đun hoặc tùy chọn trong đó mỗi bản ghi sửa đổi:

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

[4] Trong một số trường hợp, giá trị tiền tệ hoặc tiền có thể ảnh hưởng đến kết quả, khi được sử dụng một số bản ghi một cách chi tiết và, được thêm vào một giá trị duy nhất, bản ghi tiêu đề ina.

Hầu hết các thương hiệu cơ sở dữ liệu hỗ trợ, ngày nay, một trường dữ liệu tiền tệ hoặc tiền tệ. Sử dụng nó.

Trong một số trường hợp đặc biệt, một số người lưu trữ chúng vào một giá trị float cố định hỗ trợ một số chữ số thập phân, ("thập phân") hoặc thậm chí dưới dạng giá trị chuỗi.

Những kỹ thuật này là một con dao hai lưỡi. Nếu ứng dụng của bạn yêu cầu loại định sẵn đó, hãy tìm kiếm trên web, để có hướng dẫn về cách triển khai nó, đúng cách.

Chúc mừng. [đừng quên đưa một hộp cá ngừ mở cho mèo con, hoặc bỏ ăn]

Bạn đã gắn thẻ câu hỏi của mình securitynhưng bạn chủ yếu nói về tính nhất quán và độ tin cậy, vì vậy tôi sẽ cố gắng trả lời phần đó của phương trình:

• Sử dụng các giao dịch cơ sở dữ liệu để đảm bảo tính toàn vẹn của các hoạt động hàng loạt. Ví dụ cơ bản nhất là chuyển khoản giữa hai tài khoản - một tài khoản được khấu trừ số tiền và tài khoản kia được ghi có. Sử dụng các giao dịch để đảm bảo chuyển một phần không bao giờ xảy ra (chỉ một bên được thay đổi).
• Để chính xác, sử dụng DECIMAL loại thay vì phao. Tính toán chậm hơn nhiều nhưng bạn không nên cảm nhận vì hầu hết các tính toán tài chính là rất cơ bản
• Sử dụng nhân rộng cho thời gian hoạt động và hotcopies để sao lưu. Bạn cũng nên xem xét các ảnh chụp nhanh LVM để phục hồi

Một số cân nhắc tôi thấy là bạn phải tính đến các kiểm soát nội bộ. Điều này có nghĩa là tất cả quyền truy cập cho các hành động đối với các bảng (Chèn / xóa / cập nhật) phải thông qua các procs được lưu trữ (và không có SQl động) để không có bảng nào cho phép ghi hoặc xóa quyền trực tiếp trên bảng cho bất kỳ ai trừ quản trị viên hệ thống. Bạn cũng phải tính đến các kiểm soát nội bộ không cho phép ai đó tạo ra một công ty mới và sau đó tính phí các mặt hàng cho công ty đó (một lộ trình gian lận). Những hành động như thế sẽ luôn đòi hỏi mọi người ở hai vai trò khác nhau phải phê duyệt. Ngoài ra kiểm tra không nên được cắt trừ khi một người nhập dữ liệu và người khác phê duyệt chi phí.

Tất cả các bảng nên có các kích hoạt tạo hồ sơ kiểm toán. Bạn đang tìm cách ngăn chặn gian lận và nếu nó xảy ra để xác định chính xác ai đã thực hiện hành động này khi nào.

Trong các ứng dụng tài chính, bạn quan tâm nhiều hơn đến rất nhiều quy trình phụ trợ mà Giao diện người dùng chưa từng thấy. Mối quan tâm đầu tiên của bạn là ngăn chặn gian lận và do đó, nhiều kiểm tra mà không ai biết được được thực hiện trong phần phụ trợ.

Tôi sẽ không giải quyết một ứng dụng tài chính dưới bất kỳ hình thức nào nếu không đọc GAAP (ở Mỹ, các quốc gia khác có chuẩn mực kế toán riêng) và có CPA làm tư vấn vì thực hành kế toán không chính xác có thể dẫn đến thời gian ngồi tù. Đây là một lĩnh vực kỹ thuật cao và một người không có kiến ​​thức cần thiết không có doanh nghiệp cố gắng tạo ra phần mềm trong lĩnh vực này.

Kế toán thường là về xác minh. Miễn là bạn nhớ điều này và hiểu mối quan hệ giữa mỗi thực thể, thật khó để hiểu sai.

Tôi sẽ cố gắng liệt kê ra càng nhiều kiểm tra càng tốt nhưng sẽ luôn bỏ lỡ một số kiểm tra, hy vọng nó sẽ đủ để bạn bắt đầu tự đào.

Tổng số ghi nợ == Tổng số tín dụng, điều này đúng cho dù bạn đang nói về bộ tài khoản ENTIRE hoặc chỉ một giao dịch riêng lẻ. Nếu nó không kiểm đếm, bạn đã bỏ lỡ ít nhất một bài đăng ở đâu đó. Đây là cách General Ledger tự cân bằng.

Các khoản phải thu (ghi nợ ròng vào tài khoản kiểm soát) == Tổng hóa đơn (tổng cộng tất cả số tiền có thể thanh toán) - Tổng số đã nhận (tổng cộng tất cả các khoản thanh toán nhận được). Đây là một ví dụ về cách tổng số giao dịch trong các điều khoản tài liệu VẬT LÝ và tài liệu thực tế phải cân bằng với Sổ cái chung (mục nhập kép).

Số dư ngân hàng (theo bảng sao kê ngân hàng của bạn) == Tổng số Sổ cái của bạn cho tài khoản đó + bất kỳ séc nào nhận được không được gửi - bất kỳ séc nào được phát hành không được ký vào. Đây là ví dụ về cách kiểm tra tài khoản ngân hàng / tiền mặt với Tổng Sổ cái.

Như bạn có thể thấy, mọi giao dịch, sổ cái phụ, thậm chí chứng khoán, liên kết trực tiếp với Sổ Cái.

Nếu bạn đang thực hiện kiểm tra đơn vị, việc kiểm tra đơn giản khá dễ dàng để đảm bảo các số dư này tồn tại mỗi khi bạn chèn / cập nhật giao dịch miễn là bạn biết phải kiểm tra những gì.

Tất nhiên có nhiều số dư để kiểm tra / kiểm đếm nhưng bạn nên có ý chính của công việc cần thiết. Về cơ bản, mọi thứ đều cân bằng với mọi thứ khác, cho dù đó là tài liệu vật lý, các mục General Ledger, báo cáo ngân hàng. Nó được coi là một sự cân bằng hoàn hảo, hoặc trong trường hợp bạn lười đối phó với làm tròn, gần hoàn hảo.

Càng nhiều kiểm tra bạn có thể thực hiện trong khi bạn đang phát triển nó, tỷ lệ bạn nhận được một cái gì đó sai càng ít.

BTW, khi bạn đối phó với làm tròn, cố gắng đi bằng số thập phân thay vì phao, nó sẽ giúp bạn tiết kiệm rất nhiều đau đầu trên đường. : P