我搜索了這個主題,並收集了很多解釋。主要爲a/p和a/r做單獨的表。會計應付賬款/應收賬款數據庫模式
我想從另一種方法將兩個表合併爲1,因爲a/c和a/r是98%相似,只有1或2個屬性(例如a/p:供應商/供應商) 。
問:
是否有可能合併2個表,只是用Transaction_Type
與Acnt_Payable
或acnt_Receivable
值分類每筆交易?
我知道這是可能做的,但這是一個好的做法呢?我的系統在處理Reports
時會遇到什麼情況?
我搜索了這個主題,並收集了很多解釋。主要爲a/p和a/r做單獨的表。會計應付賬款/應收賬款數據庫模式
我想從另一種方法將兩個表合併爲1,因爲a/c和a/r是98%相似,只有1或2個屬性(例如a/p:供應商/供應商) 。
問:
是否有可能合併2個表,只是用Transaction_Type
與Acnt_Payable
或acnt_Receivable
值分類每筆交易?
我知道這是可能做的,但這是一個好的做法呢?我的系統在處理Reports
時會遇到什麼情況?
你的問題是:「另一個表或另一列」。鑑於我已經完成了大量MySql和會計數據庫操作,我會毫不猶豫地將type
作爲額外的列。
與報告的協議是,你需要返工,拉報表的代碼。擁有額外的列意味着更少的連接(如果你現在擁有它們)。您需要加強錯誤檢查,因爲對已經設計好的軟件進行更改似乎總是讓我猝不及防,因爲之前我並沒有認爲這種設計的細微差別突然間就是邏輯的一種模式轉變。
我想說重寫從空白畫布報告的代碼;從「上次」增加的經驗與此次重新審視之間,你可能會做得更好。
恕我直言,出於性能方面,大多數企業和大多數普通程序員都OK用現成的,貨架安裝MySQL或PostgreSQL的。當我觀察超過一秒的查詢時,通常是因爲我需要添加一個索引。鑑於此,你可以有另一張表格,其中代表AR和AP(或任何其他人類術語)的ID,因爲我認爲數字會提高性能。
一旦公司獲得到的表現的確是一個問題,他們將有足夠的資源聘請一個真正的MySql傢伙進來,惹它。 諷刺:除非,當然,你使用QuickBooks的,在這種情況下,一旦你過了20交易每一天夫妻店關節,你暴斂軟件。