發票模型推薦

我剛開始開發發票應用程序。我想聽聽你對這種困境的意見和建議。發票模型推薦

該發票有一個客戶部分。客戶端可以從下拉選擇菜單中選擇，也可以直接輸入到文本字段中。假設這只是一次購買，客戶永遠不會回來。我應該有這兩列：client_id和client_field，這兩者中的哪一個都可以填寫？消極的一面是很多client_field都是空的。或者我應該不使用client_field，只是添加一個新的客戶端，即使認爲客戶端只能使用一次？

來源

2011-10-04 leonel

即使對於只出現一次的客戶端，也要保持一致並使用單獨的客戶端模式並使用client_id。如果你有兩個client_id和client_model你將有額外的複雜性：

你確認必須同時檢查並確保一切是一致的。
你將不得不到o.client.try(:name) || o.client_field等遍佈整個地方纔能顯示數據。
如果您將來更改客戶記錄的結構，您將不得不重新格式化表格中的「表格」client_field kludge。
任何基於數據庫的報表都將從簡單的SQL轉換爲LEFT JOIN和CASE語句的龐然大物。

而這些只是我頭頂上的幾件事情。

如果你擔心有有很多條目—的下拉菜單，你應該擔心任何下拉超過約20項—然後用只是一個自動填充文本輸入去或限制下拉列表頂端〜 20個客戶端，併爲其餘的（或者甚至是基於JavaScript的組合框）使用自動完成的文本輸入;很有可能這些下拉菜單甚至不會被用戶，會計師和其他人使用，這些人會進行大量數據輸入，而且開發商通常不願意使用鼠標。

來源

2011-10-04 16:49:44

客戶可以是個人或客戶可以是組織。我應該分開模型嗎？或者建立一個模型關聯？例如：客戶belongs_to組織（或公司） – leonel

@leonel：取決於他們有多不同。你可以讓客戶開始，也許是一個「是公司」的標誌。 –

有一個自動完成的字段，如果提交時沒有匹配的ID，你會創建客戶端並鏈接它們有什麼問題嗎？

從用戶的角度來看，這就是我們所期望的，這也是QuickBooks這樣的應用程序多年以來的工作原理。

來源

2011-10-04 15:37:37 tadman

是的，但讓我們說客戶端它不是一個反覆出現的客戶端，這只是一次購買，客戶端永遠不會再回來。現在讓我們說有成百上千的客戶或者這樣的客戶。客戶列表中會有很多未使用的客戶端。 – leonel

這是一個很大的推測，他們永遠不會回來。什麼是存儲成本與方便客戶的名字已經輸入的可能性，他們返回的成本是多少？可能很小。您可以隨時在您的客戶列表中添加一個標記，例如「重複」，以表明他們爲報告目的已經多次做生意等。 – tadman

發票模型推薦

回答

相關問題