PTT數位生活區 / Python

Re: [問題] 如何連結資料庫

看板Python作者wawawa (哇哇哇○(￣﹏￣)○)時間16年前 (2009/08/06 00:34)推噓6(6推 0噓 4→)

留言10則, 5人參與討論串3/3 (看更多)

※ 引述《StubbornLin (Victor)》之銘言： ※ 引述《wil771126 (雨的印記)》之銘言： (恕刪) -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.170.171.45

推

wawawa

07/31 20:57,

07/31 20:57

→

StubbornLin

08/02 15:06,

08/02 15:06

→

StubbornLin

08/02 15:06,

08/02 15:06

推

huggie

08/03 16:27,

08/03 16:27

推

qrtt1

08/04 15:17,

08/04 15:17

藉這個機會來說說我對 orm 的看法有錯誤或是不正確的地方歡迎各位大大指正... Orz 首先我想說的是， Python 有訂定 DB 存取的介面： PEP 249 -- Python Database API Specification v2.0 所以介面上的存取其實不太需要像是 Perl / Ruby / Php 還需要導入一層 DBI / PDO 來介接，這也意味著要換資料庫其實修改的部分已經可以降到最低，所以 "我覺得" 在 Python 的世界裡，"引入 orm 可以讓轉換 DB 更容易" 其實不是說服人導入 orm 的理由。再來，仔細想一下 orm 的優勢到底在哪裡？何時適用呢？現在各個 web framework 都內建了各式的 orm，為什麼它們都要用 orm 來做為存取資料庫的介面？因為 web app "在本質上" 就是一個接收要求 -> 存取資料庫的行為，也就是說 web app 一般來說都會 "頻繁的存取資料庫"。因此何時需要導入 orm，那就是你的專案本質上就是會非常頻繁的和資料庫溝通，這時候如果撰寫 sql，對程式開發人員來說，會讓程式碼變的很骯髒，sql 和程式碼混雜在一起。此時引入 orm，可以有效降低 sql 出現在程式碼當中的機率，私以為專案有這樣的屬性，才需要考慮使用 orm。 ---- 但是引入 orm 會有什麼問題呢？ 1. 首先是穩定性的問題，我所說的不是單單指該 orm 套件有沒有 bug的穩定性，還包含了API 的穩定性。基本上引用了一個外部的函式庫，我覺得在某種程度上來說，等於是將程式的穩定性外包給別人。如果該函式庫維護者很有經驗，很注重向後相容，也許真的就能符合 DRY 原則，讓你可以將時間拿去做別的事... 這點我覺得 Python 社群的函式庫都還頗穩定的，不過這點仍然需要納入考量。在最好的情況下就是該函式庫很穩定，你都可以不用理會這塊，那 DRY 原則就是 Don't Repeat Yourself. 反之呢，就是第三方函式庫有大大小小的問題，你花在 patch 的時間大於自己重寫的時間，這時我戲稱 DRY 原則是 DO Repeat Yourself. 某程式語言的第三方函式庫這點我覺得有點嚴重... (以下抱怨省略三千字) 2. 學習此函式庫的時間。複雜的函式庫就是要花時間去學習。而且你得花時間精熟。有人也許認為幹麻精熟，能用就好啦。這時就要引經據典 (XD)：人月神話有提到在團隊中最好要有所謂的工具專家。所以如果你的團隊中有此 orm 專家，那好，問題還不大。如果大家都不是很熟，那遇到問題或地雷或 scaling 的問題那就要燒香拜拜了... 3. 適用度。 orm 到底適不適用你的專案，你得仔細評估。如果未來你的專案會一直長大，導致DB 存取頻繁，這時用 orm 會雪上加霜... 當然現在大部分的 orm 都有可以直接用 raw sql 的方式，不過一但你用了 raw sql... 那用 orm 的意義...? 的確是可以減少 sql 數量，但是此時你的程式碼會混雜 orm 邏輯以及 raw sql，對後面接手的人來說真的比較好維護？這需要思考。再來，如果你專案未來可能會用到各個資料庫的 store procedure、或是一些特殊的功能，那 orm 也不太適用... ---- 簡單來說，我個人是覺得 orm 有其適用性，而且它帶來益處的同時，也會帶來壞處，需要評估的地方不少就是...以上是小弟的心得... 有錯請鞭小力一點... Q_Q -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.166.114.249

推

rellik

08/06 00:45, , 1^F

08/06 00:45, 1^F

→

wawawa

08/06 00:48, , 2^F

08/06 00:48, 2^F

→

wawawa

08/06 00:49, , 3^F

08/06 00:49, 3^F