ทิศทางใหม่ของ MySQL

By: Conductor

on 8 August 2008 - 19:49 Tags:

Topics:

เมื่อปลายเดือนที่แล้ว 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

Hiring! บริษัทที่น่าสนใจ

SCB Securities

บริษัทหลักทรัพย์ ไทยพาณิชย์ จำกัด (SCBS) มุ่งมั่นนำเสนอผลิตภัณฑ์ทางการเงินด้วยมาตรฐานระดับสากล

Taamkru Ltd.

ถามครู ผู้นำสื่อการเรียนการสอน และระบบบริหารจัดการในโรงเรียน ให้การเรียนรู้เป็นเรื่องสนุก วัดผลได้

Fillgoods Technology Co., Ltd.

Thailand's E-commerce Solution Platform with Operations and Logistics Services for Online Stores.

Comments

By: jane

on 8 August 2008 - 23:07 #60819

- PostgreSQL - DB2 Free Edition - MaxDB - Firebird

By: Ford AntiTrust

on 8 August 2008 - 23:24 #60821

ส่วนใหญ่ Store procedures, Views กับ Triggers นี่ไม่ค่อยได้ใช้เลย อาจจะเพราะ Views มันทำ Cache ไม่ได้ Store procedures กับ Triggers ที่ debug ยาก เลยไม่ได้ใช้สรุปมีหรือไม่มีก็ไม่มีผลเท่าไหร่ ;)

Ford AntiTrust’s Blog | PHP Hoffman Framework

By: sugree

on 8 August 2008 - 23:27 #60822 Reply to:60821

อืม จริงด้วย พวกโอเพนซอร์สไม่ค่อยใช้ ออกแบบ db ให้มันแบนๆ ดีกว่า จะได้หนีไปใช้ BigTable

By: crucifier

on 8 August 2008 - 23:43 #60823 Reply to:60822

โดยส่วนตัวก็ไม่ค่อยได้ใช้ (จะใช้บน sql-server) เหตุเพราะไม่อยากฝังโปรแกรมแยกไว้หลายที่ ไหนๆ จะประมวลผลยอมช้าลงนิดหนึ่ง แล้วให้มันอยู่ที่เดียวกันในโปรแกรมเลยดีกว่า

แต่ถ้าในมุมมองสำหรับ business model ใหญ่ๆ จะมีผลอะไรหรือไม่ จะถอยหลังลงคลองหรือเปล่า ตรงนี้ผมมองไม่ขาด รอผู้รู้มาช่วยให้ความเห็น

By: นายขโมย on 9 August 2008 - 12:13 #60864 Reply to:60823

ส่วนใหญ่ผมจะแนะนำให้แยก business logic ออกจาก db เพราะเราอุตส่าห์แยกเป็น 3 - 4 tier แล้วดันจะเอาไปรวมกันอีก

By: pittaya

on 9 August 2008 - 12:30 #60866 Reply to:60822

ส่วนตัว ผมก็ไม่ชอบใช้ stored procedure กับ trigger นะ
มี business logic หลายๆ ที่แล้วมันงง

pittaya.com

By: kaze

on 9 August 2008 - 16:31 #60878 Reply to:60866

ส่วนตัวผมก็ไม่ใช้ 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 มองในการนำข้อมูลไปใช้ ^_^

By: crucifier

on 9 August 2008 - 19:07 #60883 Reply to:60878

เรื่อง query นี่ถ้า advance มากๆ มันก็ไม่ใช่หน้าที่โปรแกรมเมอร์อยู่แล้วนะ โปรแกรมเมอร์ก็เขียนโปรแกรมไป ให้ db specialist ออกแบบ query ให้โปรแกรมเมอร์เรียกใช้จากที่อื่นอีกที อันนี้น่าจะเกี่ยวกับ sql-mapper หลายๆ เจ้า

By: kaze

on 10 August 2008 - 04:34 #60936 Reply to:60883

จริงๆ มันก็ไม่ได้ advance มากนะครับ (ยุ่ง 8-9 ตารางเอง) logic ไม่ได้ยากอะไร ก็คำนวณทางการเงิน ตามสูตรแล้วมี condition บ้าง เพียงแต่ข้อมูลที่มาใช้ในการแสดงผล ถ้าดึงมาแต่ละตาราง แล้วมาทำที่ app มันจะส่งข้อมูลกันเยอะมาก SP ช่วยตรงนี้มาก db specialist ก็สนใจแต่ query เท่านั้น แล้วหาทางทำให้มันเร็วที่สุด

อีกอย่างการที่ไม่ใช่หน้าที่ของโปรแกรมเมอร์ ถ้าแบ่ง Business logic ของการดึงข้อมูล ให้ db specialist กับ Business logic ของ app ออกจากกัน น่าจะทำให้แบ่งง่ายขึ้น เราไม่ต้องสนใจว่าจะไปดึงข้่อมูลจากไหนบ้าง มี condition อะไร แค่รู้ว่าข้อมูลที่จะได้มีอะไร แล้วเอาไปทำอะไร

เลยน่าเสียดายจริงๆ ถ้าคิดจะตัด SP ออก

By: lew