เมื่อใดควรที่จะลดการทำงานของ RDBMS แทนที่จะทำในโค้ด?

12

โอเคฉันจะจัดการกับมัน: ฉันเป็นผู้เขียนโค้ดที่ดีกว่าฉันที่ฐานข้อมูลและฉันสงสัยว่าความคิดเกี่ยวกับ "วิธีปฏิบัติที่ดีที่สุด" อยู่ที่เรื่องของการคำนวณแบบ "ง่าย" ในแบบสอบถาม SQL เทียบกับ รหัสเช่นตัวอย่าง MySQL นี้ (ฉันไม่ได้เขียนฉันแค่ต้องรักษามัน!) - นี่จะส่งคืนชื่อผู้ใช้และอายุของผู้ใช้ในเหตุการณ์ครั้งสุดท้าย

SELECT u.username as user, 
       IF ((DAY(max(e.date)) - DAY(u.DOB)) &lt; 0 ,   
       TRUNCATE(((((YEAR(max(e.date))*12)+MONTH(max(e.date)))
       -((YEAR(u.DOB)*12)+MONTH(u.DOB)))-1)/12, 0),  
       TRUNCATE((((YEAR(max(e.date))*12)+MONTH(max(e.date))) -            
       ((YEAR(u.DOB)*12)+MONTH(u.DOB)))/12, 0)) AS age   
FROM users as u
JOIN events as e ON u.id = e.uid
...

เปรียบเทียบกับการยกรหัส "หนัก":

ค้นหา:

SELECT u.username, u.DOB as dob, e.event_date as edate
FROM users as u
JOIN events as e ON u.id = e.uid

รหัส:

function ageAsOfDate($birth, $aod)
{    //expects dates in mysql Y-m-d format...
     list($by,$bm,$bd) = explode('-',$birth);
     list($ay,$am,$ad) = explode('-',$aod);

     //Insert Calculations here 
     ...
     return $Dy; //Difference in years
}

echo "Hey! ". $row['user'] ." was ". ageAsOfDate($row['dob'], $row['edate']) . " when we last saw him.";

ฉันค่อนข้างมั่นใจในกรณีง่าย ๆ เช่นนี้มันจะไม่สร้างความแตกต่างมากนัก (นอกเหนือจากความรู้สึกสยองขวัญที่คืบคลานไปเมื่อฉันต้องทำการเปลี่ยนแปลงคำค้นหาอย่างแรก) แต่ฉันคิดว่ามันทำให้ชัดเจนว่าฉันเป็นอย่างไร กำลังมองหา

ขอบคุณ!

php mysql

— GeminiDomino
แหล่งที่มา

1

นี่เป็นคำถามที่ดี - ฉันเจอปัญหาเดียวกันแล้ว

— Michael K

นี่เป็นตัวอย่างที่ดีว่าเมื่อใดที่ไม่ควรทำ: calendar.sql (ใช่นั่นคือความน่าประหลาดใจของฉันใช่มันเป็นความคิดที่ไม่ดีและไม่มันไม่ช้าเลย)

— greyfade

เจ้าพลิกทวยเทพ ... ฉันเดิมพัน MD5 สำหรับสิ่งนั้นออกมาเป็น "CthulhuFhtagn"

— GeminiDomino

13

คุณต้องการดำเนินการตามการตั้งค่าทั้งหมดในฐานข้อมูลด้วยเหตุผลด้านประสิทธิภาพ ดังนั้นฟังก์ชั่นการรวมฟังก์ชั่นการเรียงลำดับเข้าร่วม ฯลฯ

การคำนวณอายุนี่ฉันทำในโค้ด เหตุผลเดียวที่ฉันอาจทำอะไรเช่นนี้ในการสืบค้นฐานข้อมูลคือถ้ามันต้องการคอลัมน์จำนวนมากที่ฉันไม่ได้เลือกมิฉะนั้นอาจเป็นจำนวนมากพอที่จะทำให้ข้อมูลของฉันช้าลงอย่างมีความหมาย การเลือกค่าจำนวนเต็มสองสามค่าจะไม่ทำให้ประสิทธิภาพที่แตกต่างมีความหมาย และแม้ว่ามันจะสร้างความแตกต่างในระดับปานกลางฉันก็จะลำเอียงในการรักษาตรรกะนี้ในรหัสแอปพลิเคชัน

— เจเรมี
แหล่งที่มา

ฉันเห็นด้วย. รหัสที่ประกอบไปด้วยค่าเพื่อการแสดงผลควรอยู่ในรหัสแอปของคุณ

— TehShrike

4

แต่ละกรณีจะแตกต่างกัน

เป็นตรรกะ ...

ต้องการโดยลูกค้ารายอื่น? แห้ง: ในฐานข้อมูล
ใช้สำหรับการประมวลผลเพิ่มเติมหรือไม่ เช่นเรียงตามอายุจากมากไปน้อย: ในฐานข้อมูล
ต้องการการตั้งค่าภูมิภาคหรือไม่ dd / mm / yyyy หรือ mm / dd / yyyy: ในไคลเอ็นต์
ใช้บ่อยไหม? เหตุใดจึงต้องคำนวณซ้ำแล้วซ้ำอีก: ใช้คอลัมน์ที่คำนวณและคงอยู่ในฐานข้อมูล

ในกรณีนี้ฉันอาจใช้คอลัมน์ที่คำนวณและคงอยู่ในฐานข้อมูล

มันอาจจะแย่กว่านี้: คุณอาจมีสิ่งนี้ในฐานข้อมูล:

"Hey! ". u.username." was ". <datecalc>. " when we last saw him."

— GBN
แหล่งที่มา

3

โดยทั่วไปคุณควรพิจารณาสองสิ่ง: การใช้งาน CPU และปริมาณการใช้เครือข่าย คุณไม่ควรสร้างการตอบสนองอย่างมหาศาลโอนไปยังเครือข่ายแล้วสรุปในส่วนหน้าเนื่องจากฐานข้อมูลสามารถทำได้ดีกว่านี้มาก

สำหรับการจัดการข้อมูลมันเป็นการแลกเปลี่ยน หากฐานข้อมูลใช้ปริมาณ cpu วนเท่า ๆ กันกับโค้ดส่วนหน้าของคุณทำสิ่งเดียวกัน - เนื่องจากปริมาณข้อมูลที่ถ่ายโอนนั้นเทียบเท่ากันโดยประมาณ) ดังนั้นมันจึงไม่สำคัญว่าจะอยู่ตรงไหน จากนั้นทำสิ่งที่คุณมีความเชี่ยวชาญด้านการเขียนโปรแกรมจำนวนมากที่สุด บ่อยครั้งที่คุณจะได้รับทางเลือกที่ดีและอาจมีประโยชน์มาก

1

คุณพูดถึงหนึ่ง: พื้นที่ของความเชี่ยวชาญ บางทีโครงสร้างของฐานข้อมูลอาจไม่เข้มข้นเกินไปดังนั้นคุณตัดสินใจที่จะลดการพัฒนาตรรกะบางอย่างให้กับสมาชิกในทีมที่มีฐานข้อมูลเป็นศูนย์กลางมากขึ้น อาจไม่เหมาะ แต่ถ้าคุณกำลังกระทืบเวลา ...

ฮาร์ดแวร์ฐานข้อมูลมีทรัพยากรมากกว่าเซิร์ฟเวอร์อื่นและคุณไม่สามารถเปลี่ยนแปลงได้ สิ่งนี้อาจไม่ใช้กับสถานการณ์เฉพาะนี้ แต่อาจต้องพิจารณา

มีแอปพลิเคชันอื่น ๆ ที่อาจต้องใช้ตรรกะนอกรหัสของคุณ เครื่องมือการเขียนรายงานบางอย่างอาจไม่สามารถใช้บริการเว็บหรือ API คุณสามารถทำซ้ำตรรกะหรือถ้าคุณรู้สึกว่าข้อกำหนดอาจแตกต่างกัน

— JeffO
แหล่งที่มา

"ฮาร์ดแวร์ฐานข้อมูลมีทรัพยากรมากกว่าเซิร์ฟเวอร์อื่นและคุณไม่สามารถเปลี่ยนแปลงได้" - เอ๊ะ สองประโยคนี้มาจากไหน?

— Peter Boughton

ฉันคิดว่า Jeff อาจพูดถึงเซิร์ฟเวอร์ฐานข้อมูลแบบสแตนด์อโลน ฉันควรระบุว่าฉันทำงานส่วนใหญ่ในการตั้งค่า LA [MP] P

— GeminiDomino

1

การตั้งค่า LAMP นั้นไม่มีเหตุผลที่จะไม่มีเซิร์ฟเวอร์ฐานข้อมูลแบบสแตนด์อโลนและและไม่เป็นเซิร์ฟเวอร์ฐานข้อมูลแบบสแตนด์อะโลนรับประกันทรัพยากรเพิ่มเติมและไม่สามารถเปลี่ยนได้

— Peter Boughton

การบริหารทรัพยากรมนุษย์ ไม่แน่ใจแล้ว

— GeminiDomino

@Peter Boughton, DB และแอปในเซิร์ฟเวอร์เดียวกันมีลำดับความสำคัญน้อยกว่าเวลาสำหรับการเชื่อมต่ออินเตอร์เฟสและขนาดของ IO ที่มากขึ้นตลอดเวลามีเหตุผลที่แท้จริงในการค้นหาทั้งสองเข้าด้วยกัน

— Jé Queue

0

ฉันมักจะทำผิดพลาดในการประมวลผลมากที่ฐานข้อมูล ไวยากรณ์ข้างต้นของคุณสามารถเขียนด้วยฟังก์ชัน DB ที่เป็น IMO ซึ่งเป็นโซลูชั่นที่สะอาดมาก

— เจคิว
แหล่งที่มา