หากเป็น ORM หรือ ActiveRecord ผมเข้าใจว่ามันช่วยให้เร็วขึ้นสำหรับงาน CRUD อย่างน้อยก็ไม่ต้อง query เองทั้งหมด ลดโค้ดยาว 3 บรรทัดเหลือครึ่งบรรทัด
แต่ query builder นี่มันมีดีอะไรนอกจากรองรับ db หลายยี่ห้อ กับเรื่อง sql injection? ผมขอตัดประเด็นเรื่องรองรับ db หลายยี่ห้อออกไปก่อนนะ เพราะอันนั้นเหตุผลมันชัดเจนอยู่แล้ว และ query builder ช่วยได้จริงๆ
ประเด็นที่ผมสนใจคือ query builder สามารถจัดการเรื่อง sql injection ได้ดีกว่า raw query อย่างมีนัยสำคัญเลยหรือไม่ เพราะจริงๆ เราน่าจะจัดการกับ sql injection ได้ในไม่กี่ขั้นตอน เช่น PHP ก็มี mysqli_real_escape_string ไว้ให้ใช้อยู่แล้ว
บีบคำถามให้แคบเข้ามาหน่อยก็คือหากเราไม่ได้สนใจเรื่องการต้องรองรับ db หลายยี่ห้อแล้ว มีเหตุผลอะไรที่เราต้องเสียเวลากับ query builder และระบบต้องทำงานช้าลงอีกนิดเพราะมี layer นี้มาซ้อนอยู่อีกชั้น
ใครที่มีประสบการณ์ใช้ query builder อย่างเป็นจริงเป็นจัง รบกวนเปิดโลกทัศน์ให้หน่อยครับ :)
best practices
tekkasit Thu, 04/09/2014 - 17:59
best practices เค้าคงไม่ได้มากันลอยๆครับ ถ้าระบบคำนึงเรื่องความปลอดภัยของข้อมูลเป็นหลัก การใช้ parametrized query น่าจะปลอดภัยกว่า SQL เขียนมือพร้อมกับ escape ครับ เพราะถ้าทางฝั่งโน้นพยายามอีกนิด อาจจะส่งค่าที่ทำให้เมื่อ escape แล้วรั่วก็เป็นได้ (สองชั้น)
อย่าเอาข้อมูลลูกค้าไปเสี่ยงเลยครับ ถ้ามันรั่วออกมา เราจะบอกว่าไง อ้อ ผมรู้แล้ว แต่ไม่ใช้เอง มันชักช้า ไม่ทันใจ!?! (รั่วได้ก็ช่าง งั้นรึ?!)
ทราบครับว่า best practices
crucifier Fri, 05/09/2014 - 10:34
In reply to best practices by tekkasit
ทราบครับว่า best practices เค้าไม่ได้กันมาลอยๆ นั่นล่ะครับจึงเป็นที่มาของความใคร่รู้ถึงเหตุผลเหล่านั้น เพื่อให้เข้าใจจุดประสงค์ของการออกแบบระบบพวกนี้มากขึ้น ไม่ใช่ว่าจะมักง่ายหรือสักแต่ว่านำมาใช้อย่างเดียว
รู้ว่ามันดีแต่อยากรู้ให้ชัดๆ
crucifier Fri, 05/09/2014 - 10:34
รู้ว่ามันดีแต่อยากรู้ให้ชัดๆ จากคนที่มีประสบการณ์มากกว่าผมซึ่งรู้จักแค่ "นำมาใช้" เท่านั้น คืออยากประจักษ์ในข้อดีข้อเสียต่างๆ ให้ลึกซึ้งนั่นเอง เพราะจริงๆ แล้วการ parametrized query ไม่จำเป็นต้องใช้ query builder ก็ได้
ตอนนี้กำลังไล่แกะ WordPress อยู่ ไล่ดูคร่าวๆ เห็นว่าไม่ได้ใช้ query builder ใดๆ แต่มีการ parametrized query ที่ parameter โดยตรงแทน
หลักๆ ก็ช่วยกรณี simple CRUD
luckyman Thu, 04/09/2014 - 19:47
หลักๆ ก็ช่วยกรณี simple CRUD นั่นแหละครับ ลดโค้ดได้เยอะเลย ถ้างานซับซ้อนขึ้นก็ใช้ parametrized query ครับ
sql injection นี่ ผมว่า parametrized ดีกว่านิดๆ แฮะ เพราะ ORM ไม่ได้ทำ parametrized query ทุกครั้ง
อีกอย่างที่นึกออกคือทำให้เป็น idiomatic ตามภาษาที่ใช้ อย่างเช่น squeryl
อันนี้อาจจะไม่เกี่ยว แต่ความเห็นของคุณ Gavin King (gavinaking) ในนี้ก็น่าสนใจครับ - What ORMs have taught me: just learn SQL
ขอบคุณครับ
crucifier Thu, 04/09/2014 - 19:59
In reply to หลักๆ ก็ช่วยกรณี simple CRUD by luckyman
ขอบคุณครับ เดี๋ยวไปตามอ่านดูก่อน :)
ผมเล่นง่ายๆ แบบเขียน class
PandaBaka Fri, 05/09/2014 - 03:04
ผมเล่นง่ายๆ แบบเขียน class มาซักตัว (เลียนแบบการป้อน parameter ของ zend framework)
แล้วเพิ่มการตรวจประเภทข้อมูลไปในตัว (จับ htmlspecialchars string รายตัว)
มันก็สะดวกกว่าใช้พวก query builder นะเพราะเราออกแบบเอง
ผมก็ว่าอย่างนั้นครับ
crucifier Fri, 05/09/2014 - 10:38
In reply to ผมเล่นง่ายๆ แบบเขียน class by PandaBaka
ผมก็ว่าอย่างนั้นครับ ตอนนี้จากที่ศึกษา framework และ CMS หลายตัว คะเนว่าจุดประสงค์หลักของ query builder น่าจะอยู่ที่การรองรับ db หลายชนิด ไม่ใช่เรื่องการป้องกัน sql injection เป็นหลัก
เพราะการป้องกัน sql injection สามารถสร้าง library แยกออกมาสำหรับงานนี้โดยเฉพาะและนำไปใช้กับ raw query ได้ง่ายๆ โดยไม่จำเป็นต้องใช้ query builder ให้เปลืองหน่วยความจำและต้องเขียนโค้ดยุ่งยากขึ้น เปลือง key stroke เยอะขึ้น
//parametrized แบบ WordPress
$db->query('SELECT * FROM table WHERE name=?', $name);
//query builder แบบ Joomla! และ PHP Framework อื่นๆ
$db->select('*')->from('table')->where('name=?', $name);
แบบนี้ยังง่ายอยู่และไม่ค่อยเห็นความแตกต่าง แต่หากเป็น query ที่ค่อนข้างซับซ้อน ผมว่าหากเราไม่ได้สนใจเรื่องการรองรับ db หลายยี่ห้อแล้วละก็ query builder เป็นเรื่องเกินความจำเป็น
จะเห็นว่า blog software อย่าง WordPress จะรองรับได้แค่ MySQL ในขณะที่ Joomla! ที่ทำตัวเป็น framwork และ PHP framework อื่นๆ จะรองรับ db ให้หลายชนิดให้สมกับจุดประสงค์ของการเป็น frameowrk
เหตุผลที่สนใจเรื่องนี้คืออยากศึกษาจุดมุ่งหมายของ query builder ให้ชัดเจน เพื่อจะนำแนวคิดมาใช้ในการออกแบบระบบของตัวเองด้วย
จริงๆ
luckyman Fri, 05/09/2014 - 12:23
In reply to ผมก็ว่าอย่างนั้นครับ by crucifier
จริงๆ เป้าหมายน่าจะเป็นเพื่อลดโค้ดใน Data Access Layer มากกว่านะครับ ตัดโค้ดที่แมพออปเจคกลับไปกลับมา
รองรับหลาย db ไม่น่าจะเป็นเป้าหมายหลัก ถ้างานต้องใช้ analytic functions ด้วยนี่ แทบจะหมดประโยชน์เลย
เป้าหมายเพื่อลดโค้ดไม่น่าจะใช
crucifier Fri, 05/09/2014 - 13:18
In reply to ผมก็ว่าอย่างนั้นครับ by crucifier
เป้าหมายเพื่อลดโค้ดไม่น่าจะใช่นะครับ เพราะ query builder ก็มีการ escape string ด้วย parametrized คือมีการ map data กลับไปกลับมาเหมือนกัน แถมยังเพิ่มขั้นตอนการจัดเรียง statement อีกด้วย (select, from bla bla bla)
ผมใช้ query builder
benjifx Sat, 06/09/2014 - 17:01
ผมใช้ query builder ในกรณีไม่อยากเขียน sql เองครับ หลีกเลี่ยงการเขียนผิด syntax แล้วก็สามารถนำข้อมูลออกมาในรูปแบบที่ต้องการได้เลย ไม่ต้องอ่านทีละ record แต่ถ้าเป็นงานเน้น performance เขียน query เองจะทำงานได้เร็วกว่าครับ
แนะนำให้ลองไปดู query builder ของ laravel ดูครับ เขาเขียนมาค่อนข้างใช้ง่าย เช่น
DB::table('users')->where('id', 1)->first(); // อันนี้จะได้ออกมาเป็น object เลย
DB::table('users')->insertGetId(
array('email' => 'john@example.com', 'votes' => 0)
); //อันนี้จะ insert แล้วได้ id กลับออกมา
อันนี้มันน่าจเป็น
crucifier Sat, 06/09/2014 - 19:55
In reply to ผมใช้ query builder by benjifx
อันนี้มันน่าจเป็น ActiveRecord มากกว่านะครับซึ่งมีประโยชน์มากๆ เร็วในการโค้ดในจำนวนโค้ดที่สั้นลงกว่า 6 เท่า ผมก็สร้าง library แบบนี้ไว้ใช้ใน oss project เช่นกัน แต่รูปแบบจะเป็น User::model()->loadByPk(1);
แต่ query builder ที่ผมว่าจะเป็นแบบที่โพสต์ไว้ข้างบนครับ $db->select('name')->from('user')->where->('id=?', $param); แบบนี้ ซึ่งมันดูเยิ่นเย้อเกินไปสำหรับงานที่ไม่ได้สนใจรองรับหลาย db