ทิศทางใหม่ของ MySQL
Submitted by Conductor on 8 August, 2008 - 18:49.
tags:
เมื่อปลายเดือนที่แล้ว MySQL ประกาศทิศทางใหม่ ตั้งโครงการที่ใช้โค๊ดเนมว่า Drizzle ซึ่งจะเป็นการเปลี่ยนแปลงทิศทางจาก Enterprise Database ให้กลายเป็น Lightweight Database "อันน่ารัก" เช่นเดิม และเพิ่มคำว่า "Cloud Computing" เข้ามาอย่างเก๋ไก๋
Brian Aker ผู้ซึ่งเป็น Chief Architect ของ MySQL เป็นผู้ประกาศข่าวนี้เอง และเรียก Drizzle ว่า "Databases without business logic" คุณลักษณะที่จะหายไปคือ Store procedures, Views และ Triggers
ที่มา:
- A Lightweight SQL Database for Cloud and Web - เว็บของโครงการที่ Launchpad.com
- MySQL forks: could Drizzle be the next of the new generation of relational database? - O'Reilly
- Drizzle, Clouds, "What If?" - Brian Aker's Blog, [แถม: Patches จาก Ebay กับ Google เรื่อง memory storage engine ที่ดีกว่า engine ที่มากับ MySQL ได้เข้าไปอยู่ใน Drizzle แล้ว]
คิดว่าประเด็นเสี่ยงคือคุณลักษณะที่จะหายไป รวมทั้งพวก user-defined functions และ/หรือ storage engine ที่ใช้คุณลักษณะดังกล่าว โดยเฉพาะอย่างยิ่ง trigger
»
- Conductor's blog
- Login or register to post comments
- PostgreSQL
- DB2 Free Edition
- MaxDB
- Firebird
ส่วนใหญ่ Store procedures, Views กับ Triggers นี่ไม่ค่อยได้ใช้เลย อาจจะเพราะ Views มันทำ Cache ไม่ได้ Store procedures กับ Triggers ที่ debug ยาก เลยไม่ได้ใช้สรุปมีหรือไม่มีก็ไม่มีผลเท่าไหร่ ;)
Ford AntiTrust’s Blog | PHP Hoffman Framework
อืม จริงด้วย พวกโอเพนซอร์สไม่ค่อยใช้ ออกแบบ db ให้มันแบนๆ ดีกว่า จะได้หนีไปใช้ BigTable
โดยส่วนตัวก็ไม่ค่อยได้ใช้ (จะใช้บน sql-server) เหตุเพราะไม่อยากฝังโปรแกรมแยกไว้หลายที่ ไหนๆ จะประมวลผลยอมช้าลงนิดหนึ่ง แล้วให้มันอยู่ที่เดียวกันในโปรแกรมเลยดีกว่า
แต่ถ้าในมุมมองสำหรับ business model ใหญ่ๆ จะมีผลอะไรหรือไม่ จะถอยหลังลงคลองหรือเปล่า ตรงนี้ผมมองไม่ขาด รอผู้รู้มาช่วยให้ความเห็น
ส่วนใหญ่ผมจะแนะนำให้แยก business logic ออกจาก db เพราะเราอุตส่าห์แยกเป็น 3 - 4 tier แล้วดันจะเอาไปรวมกันอีก
ส่วนตัว ผมก็ไม่ชอบใช้ stored procedure กับ trigger นะ
มี business logic หลายๆ ที่แล้วมันงง
pittaya.com
ส่วนตัวผมก็ไม่ใช้ trigger
แต่ store procedure ถ้าไม่มีนี่ กระทบเรื่อง Performance มากเลย
ผมเคยทำงาน บ. นึง ใช้แต่ sp แล้วมี db specialist เขียน query ให้
เราไม่ต้องยุ่งกับ business logic ส่วนนี้เลย ทำให้เบางาน programmer ไปเลย
ซึ่งถ้าไม่ใช้ sp แล้วข้อมูลจะต้องส่งไปมาเยอะมากๆ และทำให้โปรแกรมทำงานช้า
ผมว่าการมี business logic หลายที่
แต่ถ้าแบ่งแยกชนิดของ business logic จะช่วยให้แก้ไขงานได้ง่ายขึ้น
เช่น การคำนวณ performance ของ portfolio ในโปรแกรมพวกการเงิน
ถ้าแก้วิธีคิดคำนวณ เราไม่ต้องแก้โปรแกรม แต่ไป update store procedure ได้เลย
db specialist ก็มอง business logic ให้การดึงข้อมูลจาก table ต่างๆ
ให้ได้ข้อมูลที่ถูก ขณะที่ programmer มองในการนำข้อมูลไปใช้ ^_^
เรื่อง query นี่ถ้า advance มากๆ มันก็ไม่ใช่หน้าที่โปรแกรมเมอร์อยู่แล้วนะ โปรแกรมเมอร์ก็เขียนโปรแกรมไป ให้ db specialist ออกแบบ query ให้โปรแกรมเมอร์เรียกใช้จากที่อื่นอีกที อันนี้น่าจะเกี่ยวกับ sql-mapper หลายๆ เจ้า
จริงๆ มันก็ไม่ได้ advance มากนะครับ (ยุ่ง 8-9 ตารางเอง)
logic ไม่ได้ยากอะไร ก็คำนวณทางการเงิน ตามสูตรแล้วมี condition บ้าง
เพียงแต่ข้อมูลที่มาใช้ในการแสดงผล ถ้าดึงมาแต่ละตาราง
แล้วมาทำที่ app มันจะส่งข้อมูลกันเยอะมาก SP ช่วยตรงนี้มาก
db specialist ก็สนใจแต่ query เท่านั้น แล้วหาทางทำให้มันเร็วที่สุด
อีกอย่างการที่ไม่ใช่หน้าที่ของโปรแกรมเมอร์
ถ้าแบ่ง Business logic ของการดึงข้อมูล ให้ db specialist
กับ Business logic ของ app ออกจากกัน
น่าจะทำให้แบ่งง่ายขึ้น เราไม่ต้องสนใจว่าจะไปดึงข้่อมูลจากไหนบ้าง
มี condition อะไร แค่รู้ว่าข้อมูลที่จะได้มีอะไร แล้วเอาไปทำอะไร
เลยน่าเสียดายจริงๆ ถ้าคิดจะตัด SP ออก
กำลังพยายามไล่อ่านอยู่ว่าตกลงแล้ว Drizzle มันดีกับ Cloud แค่ไหน ถ้า Setup 3-4 เครื่องใช้เองได้ก็เจ๋งเลย
LewCPE
นี่หมายถึงว่าจะเป็นรุ่นของ MySQL ในอนาคต
หรือว่าเป็น database โครงการใหม่ที่แยกออกมาครับ?
เว็บดิกชันนารี online แปลคำศัพท์ ภาษาจีน-ไทย ไทย-จีน
http://www.zhongtai.org
ปกติใ้้ช้กันไหมครับ? พวก SP, Trigger กับงานเวบทั่วๆไปหน่ะ? ถ้าไม่มีแล้วเร็วขึ้น(อย่างมีนัย) ก็น่าสน
Patrickz's web | Patrickz's blog | blog @ G2K | blog @ narisa