การบันทึกคำสั่ง SQL ในตารางสำหรับเรียกใช้งานภายหลังเป็นความคิดที่ไม่ดีหรือไม่?

21

การบันทึกคำสั่ง SQL ในตาราง MySQL สำหรับการเรียกใช้ภายหลังเป็นความคิดที่ไม่ดีหรือไม่? งบ SQL DELETE FROM users WHERE id=1จะพร้อมสำหรับการดำเนินการคือจะมีพารามิเตอร์เพื่อแลกเปลี่ยนหรืออะไรเช่นไม่มี

ฉันคิดว่าฉันขี้เกียจ แต่ฉันคิดถึงความคิดนี้เพราะฉันกำลังทำงานในโครงการที่ต้องการงาน cron จำนวนเล็กน้อยที่จะเรียกใช้งานคำสั่ง SQL เป็นระยะ ๆ

mysql

— แก้ไข Rustom แล้ว
แหล่งที่มา

คุณควรชี้แจงว่าถ้าคุณตั้งใจจะรันคำสั่ง SQL เหล่านี้หนึ่งครั้งหรือถ้าคุณต้องการรันชุดคำสั่งเดียวกันซ้ำ ๆ

— GrandmasterB

10

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

— Erick Robertson

46

ปลอดภัยถ้านั่นคือสิ่งที่คุณถาม ตราบใดที่คุณระมัดระวังเกี่ยวกับความปลอดภัยเช่นเดียวกับความปลอดภัยของข้อมูล

แต่อย่ารวมล้อเลื่อนกระบวนงานที่เก็บไว้เป็นบิตของ SQL ที่เก็บไว้ในตาราง และพวกเขาสนับสนุนไม่สนับสนุนพารามิเตอร์

นอกจากนี้โปรดทราบว่าคุณสามารถทำให้การรักษาความปลอดภัยของคุณง่ายขึ้นและลดจำนวนจุดที่ล้มเหลวและลดการสื่อสารเครือข่ายโดยใช้ MySql Event Schedulerแทน cron

ฐานข้อมูลอื่นมีความเท่าเทียมกับฐานข้อมูลเหล่านี้ด้วยเหตุผลที่ดี คุณไม่ใช่คนแรกที่ต้องการฟังก์ชั่นนี้

— สาธารณรัฐประชาธิปไตยประชาชนลาว
แหล่งที่มา

1

+1 เมื่อใช้ตัวกำหนดตารางเวลา การ จำกัด การเข้าถึงตัวกำหนดตารางเวลาของการเข้าถึง procs นั้นดีกว่าการเข้าถึงตาราง

— JeffO

แต่ถ้าคุณต้องการสร้างคิวรีเหล่านี้แบบไดนามิกให้พูดจาก UI ตัวอย่างเช่นหากคุณอนุญาตให้ผู้ใช้ผู้ดูแลระบบสามารถตั้งกฎการเข้าถึงเนื้อหาเว็บแบบไดนามิกโดยยึดตามการสืบค้นที่ซับซ้อน คุณไม่ต้องการให้ UI สร้าง proc ใหม่ในฐานข้อมูล ฉันคิดว่าในบางสถานการณ์การค้นหาที่จัดเก็บจะดีกว่า procs

— DiscipleMichael

32

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

— Mason Wheeler
แหล่งที่มา

2

ดังนั้นงาน cron จะไม่เก็บรายการของขั้นตอนการจัดเก็บที่จะเรียกใช้?

— JeffO

1

นี่อาจเป็นประโยชน์สำหรับstackoverflow.com/questions/6560639/…แม้ว่าจะไม่ได้ใช้ cron

— MetaFight

ไม่รู้ว่าฉันคิดอะไรอยู่ รายการของ procs ทั้งหมดสามารถดำเนินการจาก proc เดียวดังนั้นงาน cron เพียงต้องการที่จะดำเนินการอย่างใดอย่างหนึ่ง

— JeffO

11

ไม่ฉันจะบอกว่าไม่ใช่ความคิดที่ดี

หมายถึงแบบสอบถาม / อัปเดต "จริง" ทุกรายการจะต้องมี 2 Hit ในฐานข้อมูล - รายการหนึ่งเพื่อรับแบบสอบถาม / อัปเดต "ของจริง" และอีกรายการหนึ่งเพื่อดำเนินการ

นี่อาจไม่ใช่ปัญหาใหญ่ในระบบขนาดเล็ก แต่ยิ่งมีผู้ใช้ / ธุรกรรมของคุณมากขึ้นเท่าไหร่ระบบก็ยิ่งน้อยลงเท่านั้น

ฉันเดาว่าสิ่งนี้มาจากการมองหาทางเลือกอื่นในการฝัง SQL ลงในโค้ดของคุณ?

Encapsulating SQL ในกระบวนงานที่เก็บไว้ตามที่ Mason Wheeler แนะนำจะเป็นวิธีหนึ่งที่ดีกว่าความคิดนี้มาก

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

+1 นี่คือเหตุผลหลักว่าทำไมโซลูชั่น @Mason Wheeler เป็นวิธีที่ถูกต้อง - เขาเพิ่งพลาดที่จะเน้นว่า แม้ว่า IMHO จะไม่ใช่ปัญหาด้านประสิทธิภาพที่ฉันเห็นที่นี่สำคัญที่สุด - ไม่จำเป็นต้องทำให้ซับซ้อนโดยการแยกคำสั่ง SQL ออกจากฐานข้อมูลแล้วส่งกลับไปเพื่อการเอาชนะ

— Doc Brown

ทำไมรายการของคำสั่ง sql จึงต้องถูกจัดเก็บในฐานข้อมูล / เซิร์ฟเวอร์เดียวกัน ฯลฯ

— JeffO

1

OP เป็นหนึ่งในการเสนอ 2 ครั้งบนฐานข้อมูล ฉันบอกว่าเขาไม่ควรทำ จากนั้นคุณถามว่าทำไมต้องเป็นฐานข้อมูล / เซิร์ฟเวอร์เดียวกัน ฉันถามใครบอกว่ามันทำ? จากนั้นคุณถามว่าคุณได้รับความนิยม 2 ครั้งในฐานข้อมูลได้อย่างไร ทำไมคุณไม่ระบุคำถามจริงแทนที่จะทำสิ่งนี้

— ozz

1

@JeffO แม้ว่ามันจะเป็นฐานข้อมูลที่แตกต่างกันก็ยังคงมี 2 แบบสอบถามฐานข้อมูลสำหรับสิ่งที่ควรจะเป็น 1 แบบสอบถามซึ่งจะชะลอตัวที่ไม่จำเป็น

— Izkata

1

@Ozz: คุณให้น้ำหนักด้านประสิทธิภาพที่มากเกินไปสำหรับคำตอบของคุณ - ประสิทธิภาพนั้นอาจละเลยได้ในสถานการณ์ส่วนใหญ่ในโลกแห่งความเป็นจริง แต่ความต้องการสองการกระทำ (การกระทำแรกเพื่อรับการสอบถาม / การปรับปรุง "จริง" การกระทำที่สองเพื่อดำเนินการ) ทำให้สิ่งต่าง ๆ ซับซ้อนเกินความจำเป็น

— Doc Brown

4

ขออภัยฉันไม่คิดว่าเป็นความคิดที่ดี

พิจารณากรณีที่ตารางในคำถามเปลี่ยนไป สมมติว่าคุณIDคอลัมน์ได้รับการเปลี่ยนชื่อเป็นnew_id

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

สำหรับการเปลี่ยนแปลงเช่นที่ฉันอธิบายฉันมักจะดูไฟล์ SQL แบบสแตนด์อโลนขั้นตอนการจัดเก็บทริกเกอร์ SQL แบบอินไลน์ในรหัสลูกค้า (VB, C #, C ++ ฯลฯ ) แต่สุดท้ายที่ฉันคิดว่าจะมอง อยู่ในตารางฐานข้อมูล แม้ว่าฉันจะทำตอนนี้! :)

— Robbie Dee
แหล่งที่มา

2

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

สำหรับสิ่งที่คุณอธิบาย - "... โครงการที่ต้องการงาน cron ไม่กี่งานที่จะดำเนินการคำสั่ง SQL เป็นระยะ" - คำตอบอื่น ๆอาจถูกต้องในการแนะนำว่าคุณใช้ขั้นตอนการจัดเก็บหรือเทียบเท่าสำหรับ DBMS คุณ ' กำลังใช้งาน

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

— Kenny Evitt
แหล่งที่มา

1

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

— แก้ไข Rustom

2

@ AmadadSuliman - เป็นเรื่องสำคัญที่จะต้องมีการกุศลให้กับทุกคนโดยเฉพาะในเว็บไซต์ SE เป็นเรื่องที่ดีที่จะมีความคิดเห็นที่ดี แต่มันง่ายเกินไปที่จะเทียบเคียงกับรูปแบบที่เราชอบอย่างไม่ย่อท้อ แต่ส่วนหนึ่งของการเป็นกุศลให้ผู้อื่นในเว็บไซต์เหล่านี้มีบริบทเพียงพอ มากเกินไปอาจทำให้คำถามจริงไม่ชัดเจน แต่โดยทั่วไปแล้วการแก้ไขค่อนข้างง่ายโดยการแก้ไขในภายหลัง

— Kenny Evitt

1

วิธีที่ง่ายที่สุดคือการมี. iniหรือไฟล์รสการกำหนดค่าอื่น ๆ เพื่อเก็บคำสั่งด้วยวิธีนี้คุณสามารถมีได้ในที่เดียวเปลี่ยนอะไรก็ได้โดยไม่ต้องเข้าถึงฐานข้อมูลเพื่อทำเช่นนั้นไม่ต้องกดฐานข้อมูลหลายครั้ง และคุณอาจต้องการ / ต้องการในบางจุดเพื่อใช้พารามิเตอร์หรือเพิ่มเงื่อนไขในการสืบค้นของคุณ (เพิ่มพวกเขาด้วยสิ่งที่ซับซ้อนมากขึ้นสำหรับกรณีเฉพาะในรหัสของคุณ)

แน่นอนคุณสามารถเก็บไว้ที่ระดับฐานข้อมูล (ในตารางหรือดีกว่ายังเป็นขั้นตอนการจัดเก็บ) แต่ถ้าคุณขี้เกียจเหมือนฉัน ;-) แต่ยังเกี่ยวข้องกับประสิทธิภาพไฟล์. iniและ PHP วิธีparse_iniอันเป็นที่รักในการอ่านเป็นวิธีที่จะไป (หากคุณกำลังจะใช้ภาษาการเขียนโปรแกรมอื่นคุณกำลังคิดหาวิธีที่คล้ายกัน)! โดยปกติแล้วฉันจะอ่านไฟล์นี้ใน bootloader ของแอปพลิเคชันและเก็บไว้ในวัตถุคงที่ (อาจจะมีเลเยอร์แคชด้านบน) เพื่อเร่งสิ่งที่จริง ๆ ถ้าเราพูดถึงแบบสอบถามที่แตกต่างกันจำนวนมาก

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

1

หากคุณต้องการคำสั่ง SQL เพียงครั้งเดียวตัวอย่างเช่นหากคุณกำลังเข้าคิวการดำเนินการหลายอย่างเพื่อดำเนินการในช่วงนอกเวลาทำงานใช่แล้วการวางคำสั่งเหล่านั้นลงในตารางจะทำงานได้ดี

หากคุณจำเป็นต้องดำเนินการคำสั่ง SQL เดียวกันตามช่วงเวลาที่กำหนดดังนั้นโพรซีเดอร์ที่จัดเก็บเส้นทางอื่น ๆ ที่กล่าวถึงอาจเป็นตัวเลือกที่ดีกว่าสำหรับคุณ

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

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