公司目前都比較習慣用sql處理業務邏輯,就是在dao層寫很長的sql陳述句,基本不大用java寫業務邏輯,但這樣資料庫服務器壓力較大,處理性能較低,而且SQL優化起來也比較的復雜,現在想用JAVA處理業務邏輯,但跨表較多情況下 關聯7、8張表以上,業務代碼也會相當復雜,一般好的做法是什么呢?有沒有什么標準做法?
uj5u.com熱心網友回復:
主流是java寫業務,現在有些小公司也采用sql寫業務uj5u.com熱心網友回復:
我覺得能交給SQL的就交給SQL,這樣你的業務邏輯就比較清晰與簡單。uj5u.com熱心網友回復:
比較傾向于Java處理業務邏輯uj5u.com熱心網友回復:
業務邏輯一般都是java這邊出了的 sql主要是管理你資料的存盤的uj5u.com熱心網友回復:
大多數系統的瓶頸都是資料庫,業務邏輯清晰?你只是轉移了業務邏輯到sql罷了
應用層可以輕松的擴展,你資料庫可不容易
uj5u.com熱心網友回復:
沒什么標準不標準的我們就要求sql不承擔業務邏輯,多表關聯能少用就少用,只在串列查詢用一下,其他時候都是單表查詢
資料庫只承擔增刪改查的職責,業務邏輯都應用層處理,雖然sql有時候會讓你代碼變得簡單,但濫用sql會造成更嚴重的問題
具體怎么做,你可以用jpa,或者mybatis的逆向工程,這樣你可以簡單的代碼去查詢資料,但這個并不能禁止你寫復雜sql
你得制定規范
uj5u.com熱心網友回復:
業務邏輯給java呀,有關操作資料庫的用sqluj5u.com熱心網友回復:
比較反感一戳長長的SQL,我的做法是一張表封裝成一個業務物件,并提供相關介面供其他模塊呼叫。uj5u.com熱心網友回復:
我記得以前一位大佬說過的話:資料庫只是作為存放資料的工具,僅此而已。uj5u.com熱心網友回復:
前面各位兄弟都說了,1, 大公司 正規, java寫業務, 用單表查詢, 比如: 你關聯 7-8張表, 最后結算還是只到 1-200個ID用來查資料, 那就找出ID 用 IN來單表查,
性能與7-8張表關聯肯定要快.
我們有個省級專案測驗過, 客戶表 約2千萬, 其它資料表也是上千萬的, 資料表約 50億行, 有些資料表 有400億行. 關聯查詢幾分鐘才出結果,
如果單表用 IN 3秒左右.
所以這情況, 業務應在java中處理, 讓查詢SQL盡量是單表, 條件是主鍵, 或者是索引.
2, 如果專案不正規, 要求速度快, 盡量結束合同, 就想怎么玩就怎么玩, 沒辦法解決性能問題, 合同才是最重要的, 公司領導想怎么玩你就怎么玩.
3, 等到公司想優化的時候, 再說吧. 中國軟體做不好, 就是與整個環境有關的, 所以一個人做到自己的事就行, 我們改變不了環境.
(因此你想用什么標準模式, 介面, 范式, 是需要時間的, 除非公司有積累)
4, 我們公司的做法:
首先dao: 把每張表操作都做成服務/微服務/或才jar包都可以, 規范對每張表的操作, 但是api必須完整, 作業量大非常大(可代碼生成).
然后biz : 把服務封裝成業務層服務, 比如: 微信介面中[統一下單業務服務], 業務層的服務可以用事務來操控, 也可以用硬編碼 if之類控制, 業務層是呼叫dao層各表的基本服務來實作的, 是根據業務組合了對表的操作.
最后展現層: action之類, jsp之類呼叫 主要是業務層服務, 部分也呼叫dao層基本服務.來最終完成功能.
uj5u.com熱心網友回復:
java 處理比較好點,可以吧邏輯分的細點,然后資料庫壓力會小很多,而且sql耦合也會降低很多的。uj5u.com熱心網友回復:
如果公司要求,那就按要求的來,標準不標準你能改變嗎?如果能改變,當然是按MVC的模式來最好。除非你能一切皆存盤程序,這樣連java代碼里的sql都不用處理,直接處理存盤程序就行。
正常的模式應該是:
java處理業務邏輯,sql只處理跟資料有關的增刪改查具體操作。
uj5u.com熱心網友回復:
看情況,不過我覺得如果用Java來寫邏輯的話,sql能被更好的復用。同一條sql回傳一樣的結果,可能到了不同呼叫的地方需要顯示的結果不相同,這樣用Java來處理邏輯更好。
uj5u.com熱心網友回復:
資料庫更多的是用來存盤資料,業務處理這塊主要還是交給java代碼來處理。見過一個作業七八年的,身份證中間星號隱藏在資料庫處理,那個用java代碼處理起來更方便更快捷,諸如此類,java處理起來更快捷為什么要用sql呢?uj5u.com熱心網友回復:
Java處理業務邏輯uj5u.com熱心網友回復:
除非領導刀架在脖子上,不然還是java處理吧,看到一坨sql都頭疼,優化到你懷疑人生uj5u.com熱心網友回復:
業務邏輯交給代碼,資料庫負責少部分資料存放的邏輯。uj5u.com熱心網友回復:
這選擇要根據實際情況選擇,選擇因數很多,沒有絕對寫在java中好,也沒有絕對的寫在sql中好,只有最合適,只有適合的才是最好的,搞技術的也不要那么偏激一定要用啥,同一套方案不能打遍天下,不同公司環境同樣的決定可能產生不一樣的結果,更多在于根據自己公司當前實際情況因地制宜抉擇。簡單舉幾個例子
比如跟你公司型別有關,互聯網公司和傳統企業肯定是不一樣的,傳統企業的業務系統經過多年發展業務非常復雜而且平臺比較老,不是你一般的增刪改查這么簡單,基本上是已經形成生態全部重構成本非常非常高,且沒有一定要重構的必要性,可能大部分的業務都不在java中都是寫在存盤程序,這種情況業務邏輯寫在存盤程序sql中肯定是最合適選擇,而且方便運維,如果是互聯網公司特別是新創業公司業務基本上很簡單,用的技術也是目前最新的,處理業務場景相對傳統企業來說簡單多了,多表關聯也較少,基本上會寫在java中。
比如還跟平臺有關,現在技術發展這么快,相信很少有幾年的公司平臺只有一個,老的平臺業務很多寫在sql中偏多,新的平臺寫在java中偏多,老的平臺也不可能一刀切到新平臺。
比如還跟專案有關,有的平臺適合如果是你老平臺專案優化原來就是用的存盤程序與sql,足夠相信公司不會讓你花很大成本去改成java,除非吃飽了撐著了讓你浪費成本做無用功,新的平臺一般會做新業務開發寫在java中一般比較多,也有從老系統遷移過來的,新的開發人員一般不理解業務會進行折中選擇。
比如還有跟應用場景有關,有的場景適合寫在java中,有的場景適合寫在SQL中,比如同一個庫大批量或很頻繁的操作資料從一張表插入另一張表,這種情況就不需要把資料查詢到應用層再從應用層寫入資料庫,直接寫在SQL中是最好了沒有網路開銷,如果是跨資料庫讀寫,肯定寫在java中處理是最好的
還有跟公司、客戶的管理政策、網路安全也有關的,可能很多時候公司政策決定了你的技術選型
反正我們新的平臺最開始嘗試創新全部把老業務改造寫在java中有失敗的案例也有,投入過成本遠遠超出預期效益頗微,最終結果就是你們部門口碑掉下去了,還有你懂的。。。復雜業務處理寫存盤程序SQL中沒有優化好反復讀寫資料導致性能瓶頸、系統回應慢、故障問題引起客戶投訴的的也很多,最終結果就是可能要向客戶檢討、批評等等,也會有你懂的。。
還有系統回應體驗不僅僅是跟開發有關,跟最開始系統軟硬體架構、部署硬體設備性能、部署方式、部署容器、系統鏈路、網路等都有關系
最后還是那句根據實際情況因地制宜抉擇,當前環境、業務場景下哪個適合選哪個,技術最終目的是服務人的,不是人被技術憋死的。
uj5u.com熱心網友回復:
比較傾向于Java處理業務邏輯uj5u.com熱心網友回復:
復雜的業務邏輯建議用java代碼去處理,SQL處理的話,要是到時候資料庫升級或者遷移了,那就很可能要重新寫uj5u.com熱心網友回復:
Java處理業務邏輯是正規、正常的處理方式,通過Java處理業務邏輯可以做負載均衡、性能調優、分布式等提供高系統處理能力的方法,而且理論成熟、工具完整。在專案中要具體問題具體解決,看你要解決的問題是什么,如果性能已經達到或者接近要求,僅SQL因為復雜,建議還是攻克一下技術難關;如果性能要求更高,那就花時間重構。
重構的復雜度比較高,要有充分準備。
uj5u.com熱心網友回復:
SQL寫業務邏輯必然沒有java好。客戶后期需求來的時候改SQL陳述句是十分麻煩的。而業務邏輯代碼在JAVA中是比較好處理的。再說服務器端的業務邏輯處理能力并不比資料庫慢。uj5u.com熱心網友回復:
sql出了問題沒法排查,會哭的老鐵uj5u.com熱心網友回復:
我見過一個上市公司的營銷系統, 50%是用存盤程序, 這個看公司而定uj5u.com熱心網友回復:
個人觀點,java處理的話,看起來會清晰一點,業務邏輯看起來好一點。sql處理的話,性能會更好一點,但看起來就不清晰了uj5u.com熱心網友回復:
這個沒有標準,還是要看實際情況吧uj5u.com熱心網友回復:
簡單的邏輯,sql也容易看懂的,那么sql就好了。如果比較復雜,從維護角度,放代碼更好。
實際情況中,并沒有區分那么明顯,要平衡性能和可讀性以及開發量。
uj5u.com熱心網友回復:
你兩能不能給個聯系方式
uj5u.com熱心網友回復:
我覺得能交給SQL的就交給SQL,這樣你的業務邏輯就比較清晰與簡單。
大多數系統的瓶頸都是資料庫,業務邏輯清晰?你只是轉移了業務邏輯到sql罷了
應用層可以輕松的擴展,你資料庫可不容易
你兩能不能給個聯系方式
?
uj5u.com熱心網友回復:
前面各位兄弟都說了,
1, 大公司 正規, java寫業務, 用單表查詢, 比如: 你關聯 7-8張表, 最后結算還是只到 1-200個ID用來查資料, 那就找出ID 用 IN來單表查,
性能與7-8張表關聯肯定要快.
我們有個省級專案測驗過, 客戶表 約2千萬, 其它資料表也是上千萬的, 資料表約 50億行, 有些資料表 有400億行. 關聯查詢幾分鐘才出結果,
如果單表用 IN 3秒左右.
所以這情況, 業務應在java中處理, 讓查詢SQL盡量是單表, 條件是主鍵, 或者是索引.
2, 如果專案不正規, 要求速度快, 盡量結束合同, 就想怎么玩就怎么玩, 沒辦法解決性能問題, 合同才是最重要的, 公司領導想怎么玩你就怎么玩.
3, 等到公司想優化的時候, 再說吧. 中國軟體做不好, 就是與整個環境有關的, 所以一個人做到自己的事就行, 我們改變不了環境.
(因此你想用什么標準模式, 介面, 范式, 是需要時間的, 除非公司有積累)
4, 我們公司的做法:
首先dao: 把每張表操作都做成服務/微服務/或才jar包都可以, 規范對每張表的操作, 但是api必須完整, 作業量大非常大(可代碼生成).
然后biz : 把服務封裝成業務層服務, 比如: 微信介面中[統一下單業務服務], 業務層的服務可以用事務來操控, 也可以用硬編碼 if之類控制, 業務層是呼叫dao層各表的基本服務來實作的, 是根據業務組合了對表的操作.
最后展現層: action之類, jsp之類呼叫 主要是業務層服務, 部分也呼叫dao層基本服務.來最終完成功能.
400億是什么鬼?
uj5u.com熱心網友回復:
我覺得你習慣用哪種就用哪種,相信自己,個人覺得JAVA寫業務就七,八張表比較麻煩,還是建議用業務SQL好一點uj5u.com熱心網友回復:
400億是什么鬼?
一張表 400億行記錄.
uj5u.com熱心網友回復:
我遇到過業務邏輯基本用sql實作的,是那種統計型別的業務,資料庫也是幾千萬級的,而且多表關聯,我覺得像這種業務,要么用搜索引擎,要么分表,不然效率真的低。而其實放到代碼中,邏輯是清晰了,但效率也差不多,比如先關聯兩張表得得結果再去寫一個方法去關聯另外的表,效率一個樣,除非你用異步呼叫,好很多轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/100486.html
標籤:Web 開發
下一篇:JTA分布式事務
