Tại sao thiết kế cơ sở dữ liệu GnuCash lại chịu ảnh hưởng từ các thương nhân thế kỷ 16?

Câu chuyện về việc kích thước đường sắt tiêu chuẩn bị chi phối bởi kích thước mông ngựa của những con La Mã cổ đại là một ví dụ kinh điển về sự phụ thuộc vào đường đi (path dependence). Nhưng bạn có biết, phần mềm kế toán mã nguồn mở GnuCash cũng chịu một số phận tương tự, chịu ảnh hưởng sâu sắc bởi các thương nhân Tây Ban Nha từ thế kỷ 16?

Trong một đêm làm việc với cốc cà phê trên bàn, tác giả Vitalik đã nhận ra rằng việc hỗ trợ hàng hóa (commodities) trong dự án HandsOnMoney không đơn giản như việc lưu trữ một con số và tính tổng. Đó là một hành trình xuyên suốt từ văn hóa, lịch sử cho đến kỹ thuật phần mềm.

Lớp đầu tiên: Văn hóa và đơn vị tiền tệ

Không phải đồng tiền nào cũng chia nhỏ thành 100 phần như Dollar hay Euro. Nhật Bản có Yên không có đơn vị nhỏ nào sau thập phân do lạm phát. Dinar Kuwait lại có 1.000 đơn vị nhỏ để đảm bảo độ chính xác cao trong giao dịch. Ngay cả Bitcoin cũng có tới 100 triệu Satoshis.

Lịch sử còn có những đồng tiền như "Real de a ocho" có thể chia thành 8 mảnh. Điều này đặt ra câu hỏi lớn: Làm thế nào để lưu trữ các giá trị này một cách chính xác trong máy tính?

Lớp thứ hai: Thách thức của phần mềm

Máy tính không thực sự giỏi xử lý phân số. Các kiểu dữ liệu float hay double chỉ là sự xấp xỉ, không phải là con số chính xác. Một ví dụ kinh điển là phép tính: 1.03 - 0.42 = 0.6100000000000001.

Trong tài chính, sai số làm tròn nhỏ này có thể tích tụ theo thời gian và gây ra những sai lệch nghiêm trọng trong cân đối kế toán. Các kỹ sư phần mềm thường sử dụng mẫu hình "Money" — lưu trữ số tiền dưới dạng số nguyên của đơn vị nhỏ nhất (ví dụ: 523 cent thay vì $5.23). Tuy nhiên, giải pháp này lại gặp vấn đề với các loại hàng hóa có độ chia nhỏ không cố định hoặc thay đổi theo thời gian.

Lớp thứ ba: Bóng ma lịch sử

GnuCash ra đời vào năm 1998, trước khi thị trường chứng khoán Mỹ chuyển sang định dạng thập phân vào năm 2001. Trước đó, các mã chứng khoán trên NYSE được giao dịch dưới dạng phân số (ví dụ: 1/8 đô la).

Tại sao lại là 1/8? Hãy ngược dòng thời gian về thế kỷ 16. Các thương nhân Tây Ban Nha khi đếm các đồng vàng doubloon thường sử dụng 8 ngón tay (loại trừ ngón cái). Do đó, đơn vị nhỏ nhất tự nhiên của họ là 1/8. Quy ước này đã được NYSE kế thừa và tồn tại hàng thế kỷ, ảnh hưởng trực tiếp đến cách các nhà phát triển GnuCash thiết kế cơ sở dữ liệu để lưu trữ giá trị dưới dạng phân số.

Lớp thứ tư: Thiết kế thiên tài hay di sản lỗi thời?

Vào năm 2026, hầu hết mọi giao dịch đều dùng thập phân. Việc GnuCash vẫn lưu trữ phân số có vẻ như là một di tích cổ lỗ sĩ. Thậm chí, nó còn gây ra lỗi hiển thị khó hiểu cho người dùng khi nhìn thấy các giá trị như 1250/2449.

Tuy nhiên, thiết kế này lại tỏ ra cực kỳ linh hoạt với thế giới tiền điện tử hiện đại. Ví dụ, nếu bạn mua 1 Bitcoin vào năm 2011 với giá 90 cent, GnuCash có thể xử lý việc bán đi một phần nhỏ cực kỳ của số Bitcoin đó (ví dụ: 3 Satoshis) vào năm 2026 chỉ bằng cách thay đổi độ chính xác của hàng hóa từ 1 lên 100.000.000. Không cần thay đổi cấu trúc dữ liệu, mọi phép tính vẫn chính xác tuyệt đối.

Lớp thứ năm: Đánh đổi về hiệu suất

Mặc dù linh hoạt, việc lưu trữ mọi thứ dưới dạng phân số gây áp lực lớn lên hiệu suất. Để cộng hoặc trừ hai phân số, hệ thống phải tìm mẫu số chung và rút gọn kết quả. Độ phức tạp tính toán này cao hơn nhiều so với việc cộng trừ các số nguyên thập phân đơn giản.

Đó là lý do hầu hết các hệ thống hiện đại, bao gồm cả HandsOnMoney, chọn cách lưu trữ số lượng dưới dạng các đơn vị nhỏ nhất (minor units) với độ chính xác cố định. Cách tiếp cận này đơn giản hơn, nhanh hơn và đủ tốt cho hầu hết người dùng hiện đại — trừ khi bạn là một thương nhân Tây Ban Nha từ thế kỷ 16 hoặc đang quản lý danh mục đầu tư cổ phiếu phân số từ những năm 90.

Cuối cùng, câu chuyện này là một lời nhắc nhở thú vị rằng các quyết định thiết kế phần mềm ngày nay đôi khi vẫn chịu ảnh hưởng bởi những thói quen nhỏ nhặt của con người từ hàng trăm năm trước.