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

CREATE TABLE "tbl" (
    "id" serial,
    "name" varchar(40),
    "num" int,
    "time" timestamp
    PRIMARY KEY ("id"),
    UNIQUE ("id")
);

นอกจากนี้ยังname, num, timeไม่ได้ระบุไว้อย่างชัดเจนว่าNOT NULLในความเป็นจริงพวกเขาเป็นเพราะการบังคับใช้ที่เกิดขึ้นในด้านการประยุกต์ใช้

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

คำถามของฉันคืออะไรประโยชน์ (ประสิทธิภาพการจัดเก็บความสอดคล้องอย่างอื่น) และข้อเสีย (สมมติว่าฉันได้ตรวจสอบแล้วว่าไม่มีโมฆะในปัจจุบันและจากตรรกะทางธุรกิจควรไม่มีโมฆะ) โดยการตั้งค่าNOT NULLข้อ จำกัด ที่ชัดเจน?

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

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

จะเกิดอะไรขึ้นเมื่อโปรแกรมเมอร์ใหม่มาถึงและต้องเขียนแอปกับฐานข้อมูลนั้น พวกเขาไม่ทราบว่าสนาม x มีNOT NULLจะเป็น

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

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

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

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

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

เหตุผลก็คือเพิ่มประสิทธิภาพการค้นหาที่รู้ว่าคอลัมน์ไม่สามารถมีNULLค่าสามารถยกเว้นการทดสอบพิเศษสำหรับค่าดังกล่าวเช่นในNOT INเมื่อเทียบกับNOT EXISTSกรณีที่ คุณสามารถเห็นอินสแตนซ์ของบล็อกนี้ซึ่งจะแสดงให้เห็นว่าไม่ได้ประกาศเขตข้อมูลNOT NULL(เมื่อตารางมีค่าที่ไม่เป็นศูนย์เสมอ) ด้วยแบบสอบถามที่แน่นอนจะเพิ่มระยะเวลาดำเนินการ 500% ผลลัพธ์จะแสดงสำหรับ SQL Server แต่อาจมีพฤติกรรมที่คล้ายคลึงกันใน DBMS เชิงสัมพันธ์อื่น ๆ เช่นเดียวกับคุณ (ไม่ต้องพูดถึงความจริงที่ว่าฐานข้อมูลของคุณสามารถส่งไปยังระบบอื่นได้) กฎทั่วไปที่คุณสามารถสันนิษฐานได้คือเมื่อข้อมูลเพิ่มเติมพร้อมใช้งานกับเครื่องมือเพิ่มประสิทธิภาพคิวรีจึงสามารถสร้างแผนเข้าถึงที่มีประสิทธิภาพมากขึ้น

ความหมายของอวกาศ

ความหมายของพื้นที่ถูกพูดถึงในโพสต์นี้โดย @Erwin Brandstetter

ในระยะสั้นคุณจะบันทึกหนึ่งtotalColumns - 8บิตที่ปัดเศษขึ้นเป็นไบต์ที่ใกล้ที่สุด (หรือMAXALIGN) หากฐานข้อมูลของคุณมี

1. มากกว่า 8 คอลัมน์
2. คอลัมน์ทั้งหมดในตารางคือNOT NULL

ความหมายของประสิทธิภาพ

อย่างไรก็ตามในโพสต์นี้บน SE โดย @Erwin Brandstetterเขากล่าว

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

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

CREATE TABLE foo (
  a int,
  b int NOT NULL,
  x float,
  y float NOT NULL
);

INSERT INTO foo ( a, b, x, y )
SELECT x, x, x, x
FROM generate_series(1,1E7) AS X(x);

EXPLAIN ANALYZE SELECT 1/a FROM foo;
EXPLAIN ANALYZE SELECT 1/b FROM foo;
EXPLAIN ANALYZE SELECT 1/x FROM foo;
EXPLAIN ANALYZE SELECT 1/y FROM foo;

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

CREATE TABLE foo ( a int );
CREATE TABLE bar ( a int NOT NULL );
INSERT INTO foo
  SELECT null FROM generate_series(1,1e5) AS x
  UNION ALL
  SELECT 10
  UNION ALL
  SELECT null FROM generate_series(1,1e5) AS x
;
INSERT INTO bar
  SELECT 0 FROM generate_series(1,1e5) AS x
  UNION ALL
  SELECT 10
  UNION ALL
  SELECT 0 FROM generate_series(1,1e5) AS x
;

ตอนนี้ฉันสร้างดัชนี

CREATE INDEX foobar ON foo(a) WHERE a IS NOT NULL;
CREATE INDEX barbar ON bar(a) WHERE a <> 0;

ในทั้งสองกรณีนี้ผู้วางแผนสามารถใช้ดัชนีเมื่อเลือก= 10และใช้การสแกน seq เมื่อค้นหา NULL หรือ 0 ตามลำดับ ดัชนีบางส่วนทั้งสองมีขนาดเท่ากัน และดัชนีแบบเต็ม (ไม่แสดง) มีขนาดเท่ากัน ต่อไปนี้วิธีเดียวกับผมโหลดขึ้นตารางที่มีลำดับหนึ่ง1..1e5และเป็นคน null / 0 1..1e5ค่าและลำดับของผู้อื่น ทั้งสองวิธีสามารถหาค่า null / 0 พร้อมดัชนีที่ครอบคลุมทั้งตาราง

TLDR; สรุป

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