เหตุใด SQL จึงไม่สามารถปรับโครงสร้างได้อีก [ปิด]

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

ป้อน SQL ใช่วิธีคิด SQL เกี่ยวกับโค้ดนั้นแตกต่างจากวิธีคิดขั้นตอนเกี่ยวกับโค้ด แต่หลักการนี้ดูเหมือนว่าใช้ได้

สมมติว่าฉันมีแบบสอบถามที่ใช้แบบฟอร์ม:

select * from subQuery1 inner join subQuerry2 left join subquerry3 left join join subQuery4 

ใช้ ID หรือวันที่เป็นต้น

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

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

ฉันคิดถึงคำตอบที่เป็นไปได้สามข้อ:

1. นี่เป็นเรื่องปกติอยู่แล้วและฉันกำลังทำงานกับคนที่ไม่มีประสบการณ์

2. โปรแกรมเมอร์ที่มีประสบการณ์ไม่ได้เขียน SQL ที่ซับซ้อนเพราะพวกเขาต้องการที่จะแก้ปัญหาการประมวลผลข้อมูลอย่างหนักด้วยรหัสขั้นตอน

3. อื่น ๆ อีก

ฉันคิดว่าปัญหาหลักคือฐานข้อมูลบางส่วนไม่สนับสนุน Common Table Expressions

นายจ้างของฉันใช้ DB / 2 เพื่อหลายสิ่งหลายอย่าง เวอร์ชันล่าสุดรองรับ CTE เช่นที่ฉันสามารถทำสิ่งต่าง ๆ เช่น:

with custs as (
    select acct# as accountNumber, cfname as firstName, clname as lastName,
    from wrdCsts
    where -- various criteria
)
, accounts as (
    select acct# as accountNumber, crBal as currentBalance
    from crzyAcctTbl
)
select firstName, lastName, currentBalance
from custs
inner join accounts on custs.accountNumber = accounts.accountNumber

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

สามารถทำได้ด้วย:

• DB / 2
• PostgreSQL
• คำพยากรณ์
• เซิร์ฟเวอร์ MS SQL
• MySQL (เวอร์ชั่นล่าสุดยังค่อนข้างใหม่)
• อาจอื่น ๆ

แต่มันเป็นวิธีที่ยาวไปสู่การทำความสะอาดโค้ดอ่านง่ายและแห้งมากขึ้น

ฉันได้พัฒนา "ไลบรารีมาตรฐาน" ของ CTEs ที่ฉันสามารถปลั๊กอินไปยังคิวรีต่าง ๆ ทำให้ฉันเริ่มการค้นหาใหม่ได้ทันที บางส่วนของพวกเขาเริ่มที่จะกอดโดย devs อื่น ๆ ในองค์กรของฉันเช่นกัน

ในบางครั้งอาจทำให้การเปลี่ยนบางส่วนเป็นมุมมองเช่น "ไลบรารี่มาตรฐาน" นี้พร้อมใช้งานโดยไม่จำเป็นต้องคัดลอก / วาง แต่ CTE ของฉันได้รับการปรับแต่งเล็กน้อยดังนั้นสำหรับความต้องการต่าง ๆ ที่ฉันไม่สามารถใช้ CTE เดียวได้ใช้ SO WIDELY โดยไม่มี mods ซึ่งอาจคุ้มค่าในการสร้างมุมมอง

ดูเหมือนว่าส่วนหนึ่งของมือจับของคุณคือ "ทำไมฉันถึงไม่รู้เกี่ยวกับ CTEs" หรือ "ทำไมฐานข้อมูลของฉันไม่รองรับ CTE"

สำหรับการอัปเดต ... ใช่คุณสามารถใช้ CTEs ได้ แต่จากประสบการณ์ของฉันคุณต้องใช้มันในส่วนคำสั่งชุดและในส่วนคำสั่งที่ มันจะดีถ้าคุณสามารถกำหนดหนึ่งหรือมากกว่าข้างหน้าของคำสั่งการปรับปรุงทั้งหมดแล้วเพียงแค่มีส่วน "หลักแบบสอบถาม" ในชุด / สถานที่ที่คำสั่ง แต่มันไม่ทำงานอย่างนั้น และไม่มีการหลีกเลี่ยงชื่อตาราง / ฟิลด์ที่คลุมเครือบนตารางที่คุณกำลังอัปเดต

คุณสามารถใช้ CTE เพื่อลบได้ อาจใช้หลาย CTE เพื่อกำหนดค่า PK / FK สำหรับบันทึกที่คุณต้องการลบจากตารางนั้น อีกครั้งคุณไม่สามารถหลีกเลี่ยงการปิดบังชื่อตาราง / ฟิลด์บนตารางที่คุณกำลังแก้ไข

ตราบเท่าที่คุณสามารถเลือกลงในส่วนแทรกคุณสามารถใช้ CTEs สำหรับส่วนแทรกได้ เช่นเคยคุณอาจต้องเผชิญกับชื่อตาราง / ฟิลด์ที่ไม่ชัดเจนบนตารางที่คุณกำลังแก้ไข

SQL ไม่อนุญาตให้คุณสร้างรายการเทียบเท่าของวัตถุโดเมน, ตัดตาราง, ด้วย getters / setters สำหรับสิ่งนั้นคุณจะต้องใช้ ORM บางชนิดพร้อมกับภาษาโปรแกรม / OO ขั้นตอนเพิ่มเติม ฉันเขียนสิ่งนี้ใน Java / Hibernate

การล็อคการสร้างมุมมองฐานข้อมูลมักกระทำโดยองค์กรที่มีปัญหาเรื่องประสิทธิภาพในฐานข้อมูล นี่เป็นปัญหาวัฒนธรรมองค์กรไม่ใช่ปัญหาทางเทคนิคกับ SQL

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

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

มันเป็นสิ่งที่เป็นนามธรรมที่รหัสกลายเป็นเรื่องง่ายที่จะ refactor เพราะนามธรรมซ่อนรายละเอียดการดำเนินการจากผู้บริโภคของสิ่งที่เป็นนามธรรม Straight SQL ไม่ได้มีการแยกดังกล่าวแม้ว่าส่วนขยายเชิงดำเนินการไปยัง SQL เช่น PL / SQL สำหรับ Oracle หรือ Transact-SQL สำหรับ SQL Server เริ่มทำให้เบลอเล็กน้อย

สิ่งที่ฉันคิดว่าคุณอาจหายไปจากคำถาม / มุมมองของคุณคือ SQL ดำเนินการในชุด (ใช้การดำเนินการตั้งค่า ฯลฯ )

เมื่อคุณทำงานในระดับนั้นคุณย่อมยอมแพ้กับการควบคุมเครื่องยนต์ คุณยังคงสามารถบังคับให้ใช้สไตล์โค้ดบางอย่างโดยใช้เคอร์เซอร์ แต่เมื่อประสบการณ์แสดง 99/100 ครั้งคุณไม่ควรทำเช่นนั้น

Refactoring SQL นั้นเป็นไปได้ แต่มันไม่ได้ใช้หลักการ refactoring รหัสเดียวกันกับที่เราคุ้นเคยในโค้ดระดับแอปพลิเคชัน แต่คุณปรับวิธีการใช้โปรแกรม SQL ของตัวเอง

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

ในกรณีของการแยกรหัสออกเป็นโมดูลขนาดเล็กตามที่ @ greg-burghardt กล่าวถึง SQL โดยทั่วไปจะเป็นรหัสที่สร้างขึ้นเพื่อวัตถุประสงค์และเป็นผล มันเป็นสิ่งหนึ่งที่คุณต้องการให้ทำและไม่มีอะไรอื่น มันเป็นไปตาม S ใน SOLID มีเพียงเหตุผลเดียวที่จะเปลี่ยน / รับผลกระทบและนั่นคือเมื่อคุณต้องการให้แบบสอบถามทำอย่างอื่น ส่วนที่เหลือของตัวย่อ (OLID) ใช้ไม่ได้ที่นี่ (AFAIK ไม่มีการพึ่งพาการเชื่อมต่ออินเทอร์เฟซหรือการพึ่งพาเช่นใน SQL) ขึ้นอยู่กับรสชาติของ SQL ที่คุณใช้ ในฟังก์ชันโพรซีเดอร์ / ตารางที่เก็บไว้หรือใช้เป็นคิวรีย่อยดังนั้นฉันจึงบอกว่าหลักการแบบเปิดยังคงมีผลอยู่ แต่ฉันเชือนแช

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

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

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

ฉันหวังว่านี่จะช่วยได้.

ฉันจะมุ่งเน้นไปที่ "แบบสอบถามย่อย" ในตัวอย่างของคุณ

ทำไมจึงใช้บ่อย เพราะพวกเขาใช้วิธีคิดตามธรรมชาติของบุคคล: ฉันมีชุดข้อมูลนี้และต้องการที่จะดำเนินการกับชุดย่อยของมันและเข้าร่วมกับชุดย่อยของข้อมูลอื่น ๆ 9 จาก 10 ครั้งที่ฉันเห็นข้อความค้นหามันใช้ผิด เรื่องตลกที่ฉันทำเกี่ยวกับเคียวรีย่อยคือ: คนที่กลัวที่จะเข้าร่วมใช้เคียวรีย่อย

หากคุณเห็นข้อความค้นหาย่อยดังกล่าวมักเป็นสัญญาณของการออกแบบฐานข้อมูลที่ไม่เหมาะสม

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

การปรับโครงสร้างใหม่ใน SQL มักจะมีเป้าหมายที่แตกต่างกัน: รับประสิทธิภาพมากขึ้นเวลาสอบถามที่ดีกว่า สิ่งเหล่านั้นอาจทำให้โค้ดอ่านน้อยลง แต่มีค่ามาก

เหตุใดคุณจึงเห็นข้อความค้นหาที่ไม่ได้รับการปรับปรุงใหม่ขนาดใหญ่มากมาย

• SQL ในหลาย ๆ ทางไม่ใช่ภาษาโปรแกรม
• การออกแบบฐานข้อมูลไม่ดี
• ผู้คนไม่ค่อยคล่องแคล่วใน SQL
• ไม่มีอำนาจเหนือฐานข้อมูล (ตัวอย่างเช่นไม่ได้รับอนุญาตให้ใช้มุมมอง)
• เป้าหมายที่แตกต่างกับการเปลี่ยนโครงสร้าง

(สำหรับฉันยิ่งฉันได้รับประสบการณ์มากขึ้นด้วย SQL ยิ่งฉันยิ่งมีคำสั่งน้อยลง SQL ก็มีวิธีสำหรับคนทุกระดับทักษะในการทำงานให้สำเร็จไม่ว่าอะไรจะเกิดขึ้น)

การแบ่งแยกหน้าที่

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

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

ทั้งหมดนี้อธิบายว่าทำไม DBA ไม่ชอบเพิ่มการดูที่มีไว้สำหรับรหัสของแอปพลิเคชันบางตัวเท่านั้น

การออกแบบ SQL

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

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

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

ส่วนขยายที่เป็นกรรมสิทธิ์

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

แต่ปัญหาคืออะไรในที่สุด?

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

ดังนั้นเพื่อให้การรีแฟคเตอร์ประสบความสำเร็จ:

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

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

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

คะแนน 1 และ 3: จำนวนการดูไม่ใช่วิธีเดียว นอกจากนี้ยังมีตารางชั่วคราว, มาร์ท, ตัวแปรตาราง, คอลัมน์รวม, CTE, ฟังก์ชั่น, ขั้นตอนการจัดเก็บและโครงสร้างอื่น ๆ อาจขึ้นอยู่กับ RDBMS

DBAs (และฉันกำลังพูดว่าเป็นคนที่มีทั้ง DBA และผู้พัฒนา) มีแนวโน้มที่จะมองโลกในแบบไบนารีที่ค่อนข้างดีดังนั้นมักจะขัดกับสิ่งต่าง ๆ เช่นมุมมองและฟังก์ชั่นเนื่องจากการรับรู้ประสิทธิภาพ

ต่อมาความจำเป็นในการรวมที่ซับซ้อนได้ลดลงด้วยการรับรู้ว่าโต๊ะที่มีความผิดปกติแม้จะถูกย่อยได้ดีที่สุดจากมุมมองNFแต่ก็มีประสิทธิภาพสูง

นอกจากนี้ยังมีแนวโน้มในการทำแบบสอบถามด้านลูกค้าด้วยเทคโนโลยีเช่นLINQที่คุณเพิ่มในจุดที่ 2

ในขณะที่ฉันยอมรับว่า SQL เป็นสิ่งที่ท้าทายในการทำให้เป็นโมดูล แต่ก็มีความก้าวหน้าที่ยิ่งใหญ่แม้ว่าจะมีการแบ่งแยกระหว่างรหัสฝั่งไคลเอ็นต์กับ SQL เสมอ - แม้ว่า4GLจะทำให้เส้นเบลอบ้างก็ตาม

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