ใช้ทำเว็บแนวไหนครับ จะได้แนะนำถูก
่joomla ก็ใช้ง่าย
ตามความเห็นส่วนตัวผมนะ
อาจจะเอียงไปทาง Joomla บ้างเพราะผมถนัด Joomla มากกว่า Drupal ถ้าเรื่องใหนที่ไม่ถูกต้องขอให้ท่านที่เก่ง Drupal ช่วยอธิบายให้กระจ่างแจ้งด้วย
Joomla 2.5 เทียบกับ Drupal 7
เรื่อง Menu
Drupal ใช้ menu แบบธรรมดา ไม่มี menu option เพิ่ม อยากไ้ด้ option เพิ่มใส่ path เพิ่มเอา
Joomla เป็นแบบ Menu Item Type เลือก Menu Item Type แล้วมี option เพิ่ม
ตัวอย่างระบบร้านหนังสือ
ถ้าใช้ Drupal ตรง path ใส่
bookstore\bookstype\34 แสดงประเภทหนังสือ id 34
bookstore\bookstype\34\1 แสดงประเภทหนังสือ id 34 และเลือก layout ประเภทที่ 1
bookstore\bookstype\34\1\ฺB แสดงประเภทหนังสือ id 34 และเลือก layout ประเภทที่ 1 และ แสดงราคาเป็นเงินบาท
bookstore\bookstype\34\1\ฺB\3 แสดงประเภทหนังสือ id 34 และเลือก layout ประเภทที่ 1 และ แสดงราคาเป็นเงินบาท และ แสดงจำนวน 3 เล่มต่อ 1 แถว
ถ้าอยากให้ปรับแต่งเพิ่มได้ ก็เพิ่ม path option ไปเรื่อย ๆ ถ้ามันมี option เป็นสิบละ
bookstore\bookstype\34\1\ฺB\3\14\blue\top\left\234\ คุณรู้หรือไม่มันหมายถึง อะไร ?
ถ้าใช้ Joomla ละ
คุณก็แค่เลือก Menu Item Type ของ bookstore และเลือก bookstype กดเลือกเสร็จแล้ว จะมี menu option เพิ่มด้านขวา
มีคำอธิยายให้พร้อม user friendly มาก ๆ ไม่ต้องมากนั้งจำนั้งจด path option แบบ Drupal
จุดนี้ Joomla ชนะ
ออกตัวก่อนนะครับไม่ได้เก่งดรูปัล
ส่วน Joomla ผมก็ใช้อยู่ครับ ง่ายดี ^__^
ตัวอย่างระบบร้านหนังสือ
path ลึกแค่นี้ก็พอครับ ใช้ Taxonomy
/ร้านหนังสือ/ประเภทหนังสือ หรือ
/ร้านหนังสือ/34 หรือ
/สำนักพิมพ์/ประเภทหนังสือ หรือ
/สำนักพิมพ์ หรือ
/ประเภทหนังสือ
แสดงประเภทหนังสือ id 34
ส่วน layout จะจัดแบบ table , grid หรืออื่นๆ จะแสดง กี่เล่มต่อแถว ก็ได้ครับ ใช้ Views
ใช้ Content type แยกประเภทหนังสือ ก็ได้
เมื่อคลิกดูหนังสือแต่ละเล่ม path
/node/1 หรือ
/node/[nid] หรือ
/ประเภทหนังสือ/ชื่อหนังสือ หรือ
/คอมพิวเตอร์/ความลับของไทยเสียว
แล้วแต่เราจะตั้ง
เรื่อง path ก็มี URL aliases กับ Path Auto ช่วยครับ
เรื่องความสะดวกในการจัดการเมนู ก็อยู่ในระดับใช้ได้นะครับ
ไม่รู้ว่าตอบตรงคำถามรึปล่าวนะครับ เดี๋ยวรอผู้รู้ท่านอื่นมาตอบอีกที
จะว่าไป cck ของ drupal ก็คล้ายกับ table เหมือนกัน
content type = table
แต่ละ field ของ content type เหมือนกับ แต่ละ field ของ table
งั้นหมายความว่าถ้าเรามี table books ก็สามารถแปลงเป็น content type books ได้นะซิ
จากนั้นเราสามารถใช้ view ดึงข้อมูล content type books ให้เป็น layout แบบ table , grid ก็ได้ไม่ต้องเขียน code สบายดีแท้
แต่มันจะ สบายจริง ๆ หรือ ?
แล้ว drupal จัดเก็บข้อมูลแบบ cck โดยวิธีแบบใหนละ ?
ตามไปดูที่
http://drupal.org/node/82661 
(เป็นของ drupal 6 แต่ก็คล้าย ๆ กับ drupal 7 เพียงแต่ drupal 7 เปลี่ยนชื่อ table แต่หลักการคล้าย ๆ กันอยู่)
ถ้าเราต้องการสร้างระบบร้านหนังสือขึ้นมา เอาแบบเต็มสูบเลยนะมีอะไรครบ ๆ อย่างต่ำน่าจะ 200 table ขึ้น
ให้ทดลองสร้าง content type ชื่อว่า books จากนั้นเพิ่ม fields ดังนี้
-price (ราคา)
-page_number (จำนวนหน้า)
-author (ผู้เขึยน)
-publishing_house (สำนักพิมพ์)
-front_cover (ภาพหน้าปก)
-weigh (น้ำหนัก)
คราว ๆ นะ
จากนั้นลองเข้าที่ดูที่ฐานข้อมูล drupal
จะมี table เพิ่มขึ้นมาใหน ดังนี้
- field_data_field_price
- field_data_field_page_number
- field_data_field_author
- field_data_field_publishing_house
- field_data_field_front_cover
- field_data_field_weigh
- field_revision_field_price
- field_revision_field_page_number
- field_revision_field_anthor
- field_revision_field_publishing_house
- field_revision_field_front_cover
- field_revision_field_weigh
จะเห็นว่าถ้าเราเพิ่ม field ใน content type 1 field จะมี table เพิ่มขึ้นมา 2 table
ในที่นี้ content type ชื่อว่า books มี 6 field ก็จะมี table เพิ่มขึ้นมา 12 table
จะเห็นว่ามีข้อเสียดังนี้
1 จำนวน table ที่ต้องจัดการมากขึ้นหลายเท่า
ระบบร้านหนังสือมี 200 table สมมุติว่าเฉลี่ยแล้ว table ใหน มี 20 field เมื่อแปลงเป็น content type จะทำให้ในฐานข้อมูล drupal
มี table เพิ่มขึ้นมาเป็น 200 x 20 = 4,000 oh no !!! ใช่แล้ว 4,000 table
2 ช้า ช้า ช้า และ ช้า
สาเหตุสำคัญที่ทำให้ query ข้อมูลช้าคือจำนวน record กับ จำนวน table ที่ต้อง join กัน
อย่างข้อมูล books ข้างบนถ้าเก็บเป็น table ปกติ ดึงข้อมูลจาก table แค่อันเดียว
แต่ ถ้าเป็น content type ต้อง join table อย่างน้อย 6 table ขึ้นไป ทีนี้ถ้าอยากได้สรุปยอดขายประจำวัน คิดว่าต้อง join เท่าไหร่ table กัน ?
A: งั้นก็ใช้ cache ซะซี
ฺB: การใช้ cache เหมาะสำหรับงานที่มีการเรียกดูข้อมูลบ่อย ๆ จากฐานข้อมูลนั้นที่ไม่ค่อยมีการเปลี่ยนแปลงข้อมูลมากนัก เช่น อันดับหนังทำเงินประจำสัปดาห์ , อันดับเพลงประจำเดือน
ที่สำคัญส่วนใหญ่ใช้ กับหน้าเว็บหรือ front end ไม่ใช่ หลังบ้าน หรือ back end ถ้านำไปใช้กับ back end จะได้งงกันพอดิว่าข้อมูลนี้มันเป็นข้อมูล สด หรือ cache กันแน่ ?
ผมเห็นหนังสือ Packtpub.Drupal.7.Business.Solutions กับ Packtpub.Drupal.7.Development.by.Example.Beginners.Guide
ใช้ cck ทำเป็น web app ได้หลายระบบ เช่น นัดหมาย, หางาน, แจ้งเตือน แต่มันก็ไม่ใช่ระบบ full อะไรมากมายนัก เป็นแค่ระบบตัวอย่างเล็ก ๆ เท่านั้น
มันจะดีจริง ๆ หรือ? เมื่อคิดว่า 1 field ที่เพิ่มเข้าไปใน content type จะทำมี table เพิ่มอีก 2 table เสมอ
จากระบบร้านหนังสือออกแบบวิธีการเก็บข้อมูลโดยใช้ table ปกติใช้ 200 table แต่เมื่อจัดเก็บแบบ cck ทำให้กลายไปเป็น 4,000 table
ถ้าทำเป็น web app ออกแบบวิธีการเก็บข้อมูลโดยใช้ table ปกติไม่ดีกว่าหรือ ? ส่วน cck ใช้จัดเก็บข้อมูลพวกข่าวสารต่าง ๆ เอา
ก็อีกนั้นแหละ cck กับ view ใน drupal เป็นของคู่กัน และ module เกินครึ่งของ drupal เกี่ยวข้องกับ 2 ตัวนี้เสมอ ถ้าไม่เก็บข้อมูลโดยใช้ cck ก็จะทำให้ใช้ความสามารถของ drupal ได้ไม่เต็ม 100
อย่าง หนังสือสอนเขียน drupal module มันจะวนไปเวียนมากับ cck ตลอด
ผมเองก็อยากถามผู้รู้หน่อยถ้าทำระบบหนึ่ง มีจำนวน table เป็น 100 ขึ้นไป ถ้าใช้ drupal พัฒนาควรใช้แนวทางแบบใหนดี ?
พัฒนาเว็บไซต์
