รูปแบบการต่อต้าน SQL ที่พบมากที่สุดคืออะไร [ปิด]

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

ฉันผิดหวังอย่างต่อเนื่องโดยโปรแกรมเมอร์ส่วนใหญ่มีแนวโน้มที่จะผสม UI- ตรรกะของพวกเขาในชั้นการเข้าถึงข้อมูล:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

โดยปกติโปรแกรมเมอร์ทำเช่นนี้เพราะพวกเขาตั้งใจที่จะผูกชุดข้อมูลของพวกเขาโดยตรงกับกริดและมันก็สะดวกที่จะมีรูปแบบเซิร์ฟเวอร์ SQL Server ฝั่งเซิร์ฟเวอร์กว่ารูปแบบลูกค้า

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

นี่คือ 3 อันดับแรกของฉัน

หมายเลข 1 ความล้มเหลวในการระบุรายการเขตข้อมูล (แก้ไข: เพื่อป้องกันความสับสน: นี่เป็นกฎรหัสการผลิตมันไม่ได้ใช้กับสคริปต์การวิเคราะห์แบบใช้ครั้งเดียว - ยกเว้นว่าฉันเป็นผู้เขียน)

SELECT *
Insert Into blah SELECT *

ควรจะเป็น

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

หมายเลข 2 การใช้เคอร์เซอร์และ while loop เมื่อ a ขณะที่ loop กับตัวแปร loop จะทำ

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

หมายเลข 3 DateLogic ผ่านชนิดสตริง

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

ควรจะเป็น

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

ฉันเคยเห็น "ล่าสุดหนึ่งคำค้นหาดีกว่าสองคำ,

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

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

• ฟิลด์รหัสผ่านที่มนุษย์สามารถอ่านได้เช่น eg อธิบายตนเอง

• ใช้LIKE กับ คอลัมน์ที่มีการจัดทำดัชนีและฉันเกือบถูกล่อลวงเพียงแค่พูดว่า LIKE โดยทั่วไป

• รีไซเคิลค่า PK ที่สร้างโดย SQL

• ไม่มีใครแปลกใจที่กล่าวถึงพระเจ้าโต๊ะเลย ไม่มีอะไรบอกว่า "อินทรีย์" เช่น 100 คอลัมน์ของค่าสถานะบิตสตริงขนาดใหญ่และจำนวนเต็ม

• จากนั้นก็มีรูปแบบ "ฉันคิดถึงไฟล์. ini" : การจัดเก็บ CSVs สตริงที่คั่นด้วยไพพ์หรือการแยกวิเคราะห์ข้อมูลอื่น ๆ ที่จำเป็นในฟิลด์ข้อความขนาดใหญ่

• และสำหรับเซิร์ฟเวอร์ MS SQL การใช้งานของเคอร์เซอร์ที่ทั้งหมด มีวิธีที่ดีกว่าในการทำภารกิจเคอร์เซอร์ใด ๆ

แก้ไขเพราะมีมากมาย!

ไม่ต้องขุดลึกลงไป: ไม่ใช้คำสั่งที่เตรียมไว้

ใช้นามแฝงตารางที่ไม่มีความหมาย:

from employee t1,
department t2,
job t3,
...

ทำให้การอ่านคำสั่ง SQL ที่มีขนาดใหญ่นั้นยากกว่าที่ควรจะเป็น

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. การป้อนข้อมูลผู้ใช้ที่เชื่อถือได้แบบสุ่ม
2. ไม่ได้ใช้ สืบค้นแบบมีพารามิเตอร์
3. รหัสผ่านที่ชัดเจน

Bugbears ของฉันคือตาราง Access 450 คอลัมน์ที่ได้รับการรวบรวมโดยลูกชายวัย 8 ขวบของ Dog Groomer เพื่อนที่ดีที่สุดของกรรมการผู้จัดการและตารางการค้นหาแบบหลบซึ่งมีอยู่เพราะใครบางคนไม่ทราบวิธีทำให้โครงสร้างข้อมูลเป็นปกติ

โดยทั่วไปตารางการค้นหานี้จะมีลักษณะดังนี้:

ID INT
ชื่อ NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
วันที่ 1 DATETIME
วันที่ 2 DATETIME

ฉันสูญเสียจำนวนลูกค้าที่ฉันเห็นว่ามีระบบที่พึ่งพาสิ่งที่น่ารังเกียจเช่นนี้

สิ่งที่ฉันไม่ชอบมากที่สุดคือ

1. การใช้ช่องว่างเมื่อสร้างตาราง, sprocs ฯลฯ ฉันสบายดีกับ CamelCase หรือ under_scores และเอกพจน์หรือพหูพจน์และ UPPERCASE หรือตัวพิมพ์เล็ก แต่ต้องอ้างถึงตารางหรือคอลัมน์ [กับช่องว่าง] โดยเฉพาะอย่างยิ่งถ้ามีระยะห่างแปลก ๆ (ใช่ ฉันเจอสิ่งนี้) ทำให้ฉันรำคาญจริงๆ

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

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

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

ใช้ SP เป็นคำนำหน้าของชื่อขั้นตอนการจัดเก็บเพราะจะค้นหาในตำแหน่งขั้นตอนระบบแทนการใช้แบบกำหนดเอง

การใช้ตารางและเคอร์เซอร์ชั่วคราวมากเกินไป

สำหรับการเก็บค่าเวลาควรใช้เขตเวลา UTC เท่านั้น ไม่ควรใช้เวลาท้องถิ่น

ใช้ @@ IDENTITYแทน SCOPE_IDENTITY ()

อ้างจากคำตอบนี้ :

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

การใช้ฟิลด์ 'ตาย' อีกครั้งสำหรับบางสิ่งที่ไม่ได้มีไว้สำหรับ (เช่นการจัดเก็บข้อมูลผู้ใช้ในฟิลด์ 'แฟกซ์') - ดึงดูดอย่างมากว่าเป็นการแก้ไขอย่างรวดเร็ว!

select some_column, ...
from some_table
group by some_column

และสมมติว่าผลลัพธ์จะถูกจัดเรียงตาม some_column ฉันได้เห็นสิ่งนี้เล็กน้อยกับ Sybase ซึ่งมีการสันนิษฐาน (ตอนนี้)

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

หรืออัดทุกอย่างไว้ในบรรทัดเดียว

• FROM TableA, TableB WHEREไวยากรณ์สำหรับจับมากกว่าFROM TableA INNER JOIN TableB ON

• การตั้งสมมติฐานว่าแบบสอบถามจะถูกส่งกลับเรียงลำดับบางวิธีโดยไม่ต้องใส่คำสั่ง ORDER BY เพียงเพราะนั่นเป็นวิธีที่ปรากฏในระหว่างการทดสอบในเครื่องมือคิวรี

การเรียนรู้ SQL ในช่วงหกเดือนแรกของอาชีพของพวกเขาและไม่เคยเรียนรู้อะไรเลยในอีก 10 ปีข้างหน้า โดยเฉพาะอย่างยิ่งไม่ได้เรียนรู้หรือใช้งานอย่างมีประสิทธิภาพโดยใช้ฟีเจอร์ SQL ของ Window / วิเคราะห์ โดยเฉพาะอย่างยิ่งการใช้เกิน () และพาร์ทิชันโดย

ฟังก์ชั่นหน้าต่างเช่นฟังก์ชั่นรวมดำเนินการรวมในชุดที่กำหนดไว้ (กลุ่ม) ของแถว แต่แทนที่จะส่งกลับค่าหนึ่งค่าต่อกลุ่มฟังก์ชั่นหน้าต่างสามารถคืนค่าหลายค่าสำหรับแต่ละกลุ่ม

ดูO'Reilly SQL Cookbook ภาคผนวก Aสำหรับภาพรวมที่ดีของฟังก์ชั่นหน้าต่าง

ฉันต้องการทำให้รายการโปรดปัจจุบันของฉันอยู่ที่นี่เพื่อทำให้รายการสมบูรณ์ antipattern ที่ฉันชอบคือไม่ได้ทดสอบการค้นหาของคุณ

สิ่งนี้ใช้เมื่อ:

1. แบบสอบถามของคุณเกี่ยวข้องกับมากกว่าหนึ่งตาราง
2. คุณคิดว่าคุณมีการออกแบบที่ดีที่สุดสำหรับการสืบค้น แต่อย่ากังวลที่จะทดสอบสมมติฐานของคุณ
3. คุณยอมรับข้อความค้นหาแรกที่ใช้งานได้โดยไม่มีเงื่อนงำว่าจะใกล้เคียงกับการเพิ่มประสิทธิภาพหรือไม่

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

การละเมิดตารางชั่วคราว

สิ่งเหล่านี้โดยเฉพาะ:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

อย่าสร้างตารางชั่วคราวจากแบบสอบถามเพียงเพื่อลบแถวที่คุณไม่ต้องการ

และใช่ฉันเห็นหน้ารหัสในรูปแบบนี้ในฐานข้อมูลการผลิต

มุมมองที่แตก: ครอบงำจิตใจด้วยการทำให้เป็นมาตรฐาน

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

ฉันพบว่าระบบที่ใช้งานเกินปกติมักจะปรับให้เหมาะสมก่อนเวลาอันควรโดยเฉพาะในช่วงเริ่มต้นของการพัฒนา

(คิดเพิ่มเติมเกี่ยวกับมัน ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

ฉันเพิ่งรวมมันเข้าด้วยกันโดยอิงจากการตอบสนองของ SQL ที่นี่ใน SO

มันเป็นปฏิปักษ์ร้ายแรงที่จะคิดว่าทริกเกอร์ที่มีต่อฐานข้อมูลเป็นตัวจัดการเหตุการณ์เพื่อ OOP มีการรับรู้ว่ามีเพียงตรรกะเก่า ๆ เท่านั้นที่สามารถนำไปสู่ทริกเกอร์ที่จะถูกไล่ออกเมื่อธุรกรรม (เหตุการณ์) เกิดขึ้นบนโต๊ะ

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

ขั้นตอนหรือฟังก์ชันที่เก็บไว้โดยไม่มีความคิดเห็นใด ๆ ...

1) ฉันไม่รู้ว่ามันเป็นรูปแบบต่อต้าน "เป็นทางการ" แต่ฉันไม่ชอบและพยายามหลีกเลี่ยงการใช้ตัวอักษรสตริงเป็นค่าเวทมนต์ในคอลัมน์ฐานข้อมูล

ตัวอย่างจาก 'ภาพ' ตารางของ MediaWiki:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(ฉันเพิ่งสังเกตเห็นปลอกที่แตกต่างกันสิ่งอื่นที่ควรหลีกเลี่ยง)

ฉันออกแบบเคสเช่นการค้นหา int ลงในตาราง ImageMediaType และ ImageMajorMime ด้วยคีย์หลัก int

2) การแปลงวันที่ / สตริงที่ขึ้นอยู่กับการตั้งค่า NLS เฉพาะ

CONVERT(NVARCHAR, GETDATE())

ไม่มีตัวระบุรูปแบบ

แบบสอบถามย่อยที่เหมือนกันในแบบสอบถาม

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

• The! Paramed - แบบสอบถามสามารถมีมากกว่าหนึ่งวัตถุประสงค์ได้หรือไม่ อาจเป็นไปได้ แต่คนต่อไปที่อ่านมันจะไม่รู้จนกระทั่งการทำสมาธิลึก แม้ว่าคุณจะไม่ต้องการโอกาสในตอนนี้คุณก็จะทำได้แม้ว่าจะเป็น "เพียงแค่" ในการดีบัก การเพิ่มพารามิเตอร์จะช่วยลดเวลาในการบำรุงรักษาและทำให้สิ่งต่าง ๆ แห้ง หากคุณมีส่วนคำสั่งที่คุณควรมีพารามิเตอร์

• กรณีที่ไม่มีกรณี -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

ทั้งสองฉันพบมากที่สุดและสามารถมีค่าใช้จ่ายที่สำคัญในแง่ของประสิทธิภาพคือ:

• การใช้เคอร์เซอร์แทนการแสดงออกตามชุด ฉันคิดว่าอันนี้เกิดขึ้นบ่อยครั้งเมื่อโปรแกรมเมอร์คิดอย่างเป็นระเบียบ

• การใช้คิวรีย่อยที่สัมพันธ์กันเมื่อการเข้าร่วมกับตารางที่ได้รับมาสามารถทำงานได้

การวางสิ่งต่าง ๆ ลงในตารางชั่วคราวโดยเฉพาะผู้ที่เปลี่ยนจาก SQL Server เป็น Oracle มีนิสัยที่ใช้ตารางชั่วคราวมากเกินไป เพียงใช้คำสั่ง select ที่ซ้อนกัน

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

• กลยุทธ์การลดขนาด I / O จริงเนื่องจากคอขวดของข้อความค้นหาส่วนใหญ่คือ I / O ไม่ใช่ CPU
• ผลกระทบที่สมบูรณ์แบบจากการเข้าถึงที่เก็บทางกายภาพประเภทต่าง ๆ (เช่น I / O ต่อเนื่องจำนวนมากจะเร็วกว่า I / O สุ่มขนาดเล็กจำนวนมากแม้ว่าจะน้อยกว่าดังนั้นหากที่เก็บข้อมูลทางกายภาพของคุณเป็น SSD!)
• วิธีการปรับแต่งแบบสอบถามถ้า DBMS สร้างแผนแบบสอบถามไม่ดี
• วิธีการวินิจฉัยประสิทธิภาพของฐานข้อมูลที่ไม่ดีวิธี "ดีบัก" แบบสอบถามที่ช้าและวิธีอ่านแผนแบบสอบถาม (หรืออธิบายขึ้นอยู่กับ DBMS ที่คุณเลือก)
• กลยุทธ์การล็อกเพื่อเพิ่มประสิทธิภาพการรับส่งข้อมูลและหลีกเลี่ยงการหยุดชะงักในแอปพลิเคชันที่มีผู้ใช้หลายคน
• ความสำคัญของการแบทช์และเทคนิคอื่น ๆ เพื่อจัดการการประมวลผลของชุดข้อมูล
• การออกแบบตารางและดัชนีเพื่อสร้างสมดุลของพื้นที่และประสิทธิภาพที่ดีที่สุด (เช่นครอบคลุมดัชนีทำให้ดัชนีมีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ลดประเภทข้อมูลให้เหลือขนาดต่ำสุด ฯลฯ )

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

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

โซลูชันที่ถูกต้อง (เกือบตลอดเวลา) คือการรวมสองคำสั่ง SELECT เข้าเป็นหนึ่งเดียว:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

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

นอกจากนี้การเรียงลำดับในแอปพลิเคชันมักเป็นแบบไม่มี

การใช้คีย์หลักเป็นตัวแทนสำหรับที่อยู่บันทึกและใช้กุญแจต่างประเทศเป็นตัวแทนสำหรับตัวชี้ที่ฝังอยู่ในบันทึก