Thiết lập một hệ thống kế toán kép để sử dụng cá nhân và để giúp quản lý một doanh nghiệp thực sự nhỏ. Cố gắng đặt một vài tính năng có vẻ phù hợp bây giờ.

Quy tắc kinh doanh

Logic, đối với những người không quen thuộc với kế toán, là: tiền không được tạo ra cũng không bị phá hủy, nó chỉ được chuyển từ tài khoản này sang tài khoản khác. Mỗi giao dịch có một bên Nợ và một bên Tín dụng. Một vài ví dụ:

1. Mức lương từ chủ lao động của bạn: Tín dụng Salary, Ghi nợ Bank Account- tiền đến từ tiền lương của bạn và đã chuyển đến tài khoản ngân hàng của bạn.

2. Trả tiền thuê nhà: Tín dụng Bank Account, Ghi nợ Rent- tiền đến từ tài khoản ngân hàng của bạn và chuyển đến tài khoản thuê của bạn.

Tài khoản có thể là tài khoản 'chứng khoán, theo nghĩa là số dư của tài khoản được tích lũy (tài khoản ngân hàng là một ví dụ điển hình) hoặc có thể là tài khoản thông lượng / lưu lượng, theo nghĩa là số dư của tài khoản không được tích lũy (tiền thuê là một ví dụ tốt).

Logic đằng sau thiết kế

Ý tưởng là có một JournalDBbảng chính lưu trữ các mục chính. Bảng JournalTxlưu trữ từng tài khoản liên quan đến giao dịch. Mỗi mục (từ JournalDB) có một ID và mỗi giao dịch (từ JournalTx) được liên kết với Mục nhật ký. Kịch bản trường hợp cơ bản là có 1 mục nhập JournalDBvà hai (hoặc nhiều) giao dịch trong JournalTx. Mỗi mục có thể có một cost_center, a projectvà một vài thuộc tính khác.

Về cơ bản có hai cách thiết kế (theo câu hỏi này ) - như một hàng cho mỗi kiểu giao dịch và hai hàng cho mỗi giao dịch. Trong lần đầu tiên, tôi sẽ có một dòng với tài khoản tín dụng và tài khoản ghi nợ, trên dòng thứ hai (dòng này) có n-line, một dòng cho mỗi tài khoản bị ảnh hưởng.

Tài khoản

Bảng Tài khoản là Biểu đồ Tài khoản (trên biệt ngữ kế toán). Có cấu trúc phân cấp - Tôi đã sử dụng kiểu danh sách kề. Mặc dù không thường xuyên lắm, nhưng các tài khoản sẽ có hoạt động CRUD. Tôi đã thêm parent_imediate, parent_secondnhư một giải pháp thực sự xấu xí để tạo ra các tập hợp (ví dụ: tính tổng tài khoản Tài sản), nhưng đưa ra thách thức (không biết làm thế nào để thực hiện điều đó sau một nghiên cứu dài), có vẻ như là một cách dễ dàng - bất kỳ đầu vào hoặc đề nghị về vấn đề đó cũng được hoan nghênh.

Truy vấn chính

Nhận các báo cáo, thường là montlhy: về cơ bản tất cả các giao dịch với các giao dịch tổng hợp đã ảnh hưởng đến từng giao dịch sau đó. Kịch bản trường hợp tốt nhất sẽ là một bảng trụ (cột là ngày), với mỗi hàng là một tài khoản. Tôi đoán một phiên bản "xếp chồng" của cái này cũng sẽ hoạt động tốt.

Tài khoản chỉ là một chiều - tôi có thể muốn truy vấn bằng cost_centerhoặc bằng projectví dụ.

Các tính năng khác

Tôi muốn có khả năng lập ngân sách tài khoản (do đó là bảng ngân sách), cũng như có "mục tiêu" (tôi muốn có những kỳ nghỉ sẽ tiêu tốn của tôi 1.000 đô la). Tôi cũng muốn có thẻ và có thể thiết lập các hóa đơn định kỳ (là giao dịch "dự kiến")

Quan hệ cơ bản

Một mục (tạp chí_db) có nhiều giao dịch (tạp chí_tx). Một cost_center, dự án, v.v có nhiều mục Một tài khoản có nhiều giao dịch. Một liên hệ có nhiều mục.

Nghi ngờ chính của tôi

Tôi mới bắt đầu tìm hiểu về DB / Lập trình, vì vậy hãy chịu đựng những sai lầm rõ ràng.

1. Là thiết kế này vững chắc từ quan điểm lập trình / hiệu suất / tính năng?
2. Làm thế nào để thực hiện báo cáo? Truy vấn DB (bảng dẫn xuất) hoặc tạo một bảng mới (như nhật ký) và tạo các kích hoạt để cập nhật số dư tài khoản cho mỗi mục nhập? (đọc trong câu hỏi này không phải là một ý tưởng tuyệt vời)
3. Bất cứ điều gì tôi có thể thiếu?

Tôi nghĩ rằng câu hỏi của bạn khá rộng và khó trả lời. Nhưng đây là một số điều tôi nhận thấy về thiết kế của bạn:

Thiết kế chung

Một số bảng trong thiết kế của bạn vi phạm hình thức bình thường đầu tiên. Một ví dụ điển hình là contact_adresstrong đó có adress1, adress2và adress3như cột. Thông thường một địa điểm chỉ có một địa chỉ đường phố và sau đó một cột địa chỉ là đủ, nhưng trong trường hợp bạn thực sự muốn có khả năng thêm nhiều địa chỉ đường phố vào một địa điểm, bạn nên di chuyển các địa chỉ đó sang một bảng khác ( contact_adress, street_adress). Điều này cũng đúng cho journal_bills( detail1, detail2) và accountsbảng: Thay vì parent_imediate, parent_secondvà parent_thirdmột đĩa đơn parentthuộc tính nên là đủ. Để có được cha mẹ thứ hai hoặc thứ ba, bạn có thể sử dụng CTE đệ quy thay thế.

Tôi không biết tất cả các yêu cầu kinh doanh của bạn, nhưng bạn nên kiểm tra xem thiết kế của bạn có cho phép bạn nhập dữ liệu vô nghĩa không: Tài khoản có thể là tiền mặt và tín dụng không? Nếu bạn có tiền tệ, tỷ giá hối đoái là gì? Mã zip có thể bắt đầu bằng một hoặc nhiều số không? Số điện thoại thì sao? Đối với một số điều có các thực tiễn tốt nhất, ví dụ như làm thế nào để đối phó với các sự kiện định kỳ .

Đặt tên

Một số tên cột là khó hiểu ( ag, acc, pmt), có thể dẫn đến các vấn đề bảo trì nếu ai đó đã làm việc với cơ sở dữ liệu của bạn. Sử dụng một hướng dẫn phong cách nếu bạn không chắc chắn làm thế nào để đặt tên cho mọi thứ. Nói chung, nên tuân theo sơ đồ đặt tên đồng ý, ví dụ: đặt cho mỗi bảng một tên số nhiều.

Làm thế nào để thực hiện báo cáo?

Tôi sẽ bám vào các truy vấn SQL đơn giản và cố gắng tránh xa các hàm phức tạp như kích hoạt trừ khi bạn thực sự cần, điều này có lẽ không bao giờ xảy ra đối với một ứng dụng đơn giản.