যে ক্ষেত্রগুলি শূন্য হতে পারে না তার জন্য পোস্টগ্রিজ এসকিউএল-এ নাল না উল্লেখ করার পরিণতিগুলি কী?

Question

আমার একটি অ্যাপ্লিকেশন রয়েছে (ডেটা পোস্টগ্রিএসকিউএল এ সংরক্ষণ করা হয়), যেখানে সারণীর ক্ষেত্রগুলির বেশিরভাগ ক্ষেত্র সর্বদা নাল নয়, তবে এই টেবিলগুলির জন্য স্কিমা এটি প্রয়োগ করে না। উদাহরণস্বরূপ এই জাল টেবিলটি দেখুন:

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

এছাড়াও name, num, timeস্পষ্টভাবে যেমন বিবৃত করা হয় না NOT NULL, বাস্তবে তারা, কারণ প্রয়োগকারী আবেদন পাশ ঘটবে।

---

আমার অনুভূতি হ'ল এটি পরিবর্তন করা উচিত, তবে পাল্টা পয়েন্টটি হ'ল অ্যাপ্লিকেশন স্তরটি নিশ্চিত করে যে নাল মানগুলি এখানে উপস্থিত হতে পারে না এবং অন্য কেউ ম্যানুয়ালি টেবিলটি সংশোধন করে না।

আমার প্রশ্নটি হল : কী কী সুবিধা (পারফরম্যান্স, স্টোরেজ, ধারাবাহিকতা, অন্য কিছু) এবং ত্রুটিগুলি (ধরে নিচ্ছি যে আমি ইতিমধ্যে যাচাই করেছি যে এই মুহুর্তে কোনও নাল নেই, এবং ব্যবসার যুক্তি থেকে কোনও নাল নেই) সুস্পষ্ট NOT NULLবাধা?

আমাদের কাছে একটি ভাল কোড পর্যালোচনা প্রক্রিয়া এবং যুক্তিসঙ্গতভাবে একটি ভাল ডকুমেন্টেশন রয়েছে, সুতরাং কিছু নতুন ব্যক্তি এই প্রতিবন্ধকতাটি ভঙ্গ করে এমন কিছু করার সম্ভাবনা সম্ভবত পরিবর্তনের ন্যায্যতার পক্ষে যথেষ্ট নয়।

এটি আমার সিদ্ধান্ত নয়, সুতরাং এই কারণেই আমি অন্য ন্যায্যতার সন্ধান করছি। আমার মতে, যদি কিছু শূন্য না হতে পারে এবং একটি ডাটাবেস আপনাকে নির্দিষ্ট করে দেয় যে কোনও কিছু নাল নয় - তবে কেবল এটি করুন। বিশেষত যদি পরিবর্তনটি অতি সাধারণ হয়।

Comments

নালস এবং ডিস্ক স্থান বিবেচনার জন্য এই উত্তরটি দেখুন: স্ট্যাকওভারফ্লো / প্রশ্নগুলি / 5008753/… সংক্ষেপে, যদি আপনার টেবিলটিতে 8 টিরও বেশি কলাম এবং কমপক্ষে 1 টি কলাম কলাম থাকে, সমস্ত কলামগুলি সারণীতে সারণীতে আরও বাইটের প্রয়োজন হবে সংজ্ঞায়িত নাল।

— ypercubeᵀᴹ

@ ypercubeᵀᴹ: সুনির্দিষ্ট হওয়ার উদ্দেশ্যে নাল বিটম্যাপ শুধুমাত্র যোগ করা হয় সারি প্রতি : যদি সেখানে সারিতে প্রকৃত নাল মান stackoverflow.com/a/7654497/939860 । সুতরাং, NOT NULLসীমাবদ্ধতার স্টোরেজ আকারে কোনও সরাসরি প্রভাব ফেলবে না। অবশ্যই, সমস্ত কলাম সংজ্ঞায়িত হওয়ার NOT NULLসাথে সাথে শুরু করার জন্য কোনও নাল বিটম্যাপ থাকতে পারে না। অন্যদিকে: আপনি যদি সত্যিকার মান ব্যতীত কলামগুলির জন্য "খালি" বা ডামি মানগুলির পরিবর্তে NULL ব্যবহার করেন তবে স্টোরেজ আকারটি অনেক কম হয় কারণ নাল বিটম্যাপ তুলনামূলকভাবে অনেক ছোট (বিরল প্রান্তের ক্ষেত্রেগুলি বাদে)।

— এরউইন ব্র্যান্ডসেটেটার

@ এরউইন ব্র্যান্ডসটেটার আমার খারাপ তখন, অংশটি বুঝতে পারে না। সুতরাং যে কলামগুলির নাল মান নেই, সেখানে স্টোরেজটিতে কোনও আসল পার্থক্য নেই, আপনি সেগুলি NULL হিসাবে নির্ধারণ করেন বা না নাল, সঠিক? সূচক স্টোরেজ স্পেসের জন্যও কি এটি একই?

— ypercubeᵀᴹ

"অ্যাপ্লিকেশন স্তরটি নিশ্চিত করে যে নাল মানগুলি এখানে প্রদর্শিত হতে পারে না" না, এটি হয় না। এটি নিশ্চিত হতে পারে যে একটি অ্যাপ্লিকেশন নাল .োকায় না। তবে আমার কাছে পিএসকিএল রয়েছে (উদাহরণস্বরূপ), এবং আমি আপনার অ্যাপ্লিকেশনটি না জেনে ইচ্ছাকৃত এবং দুর্ঘটনাক্রমে নালগুলি canোকাতে পারি।

— মাইক শেরিল 'বিড়াল পুনরুদ্ধার'

একমাত্র অ্যাপ্লিকেশন যা নিশ্চিত করতে পারে যে কেউ নিজেই টেবিলটি ম্যানুয়ালি সংশোধন করে না তা হ'ল ডিবিএম।

— মাইক শেরিল 'ক্যাট রিকল'

Answer 1

যখন কোনও নতুন প্রোগ্রামার উপস্থিত হয় এবং সেই ডিবির বিপরীতে একটি অ্যাপ লিখতে হয় তখন কী হয়? তারা জানে না যে ক্ষেত্র এক্স হয়েছে হতে NOT NULL।

অন্য প্রোগ্রামটি ধরে নিতে পারে যে সমস্ত ফিল্ড এক্সগুলি NOT NULLপারফরম্যান্স গণনা বলার জন্য, তবে কিছু এখন NULLনতুন প্রোগ্রামের কারণে, যা অসঙ্গতিপূর্ণ এবং ত্রুটিগুলি সনাক্ত করতে অসুবিধা সৃষ্টি করে।

আইএমএইচও সর্বদা ডেটা অখণ্ডতার নিয়ম যতটা সম্ভব ডেটার নিকটে, অর্থাৎ ডাটাবেসে প্রয়োগ করা ভাল। এইভাবে, নতুন অ্যাপ্লিকেশন এবং / বা প্রোগ্রামাররা আপনার ডেটা গোলযোগ করতে পারে না।

প্রোগ্রামার, অ্যাপ্লিকেশন, ভাষা এবং ফ্রেমওয়ার্কগুলি এসে যায়। ডেটা এবং ডাটাবেস অবিরত থাকে। অসম্পূর্ণ, সম্ভাব্য ভ্রান্ত ডেটার বিরুদ্ধে ডেটাবেসটি আপনার প্রতিরক্ষার শেষ লাইন।

এমনকি কর্মক্ষমতা ব্যয় করে আপনার ডাটাবেসের সততা সীমাবদ্ধতা প্রয়োগকারী ব্যবস্থার সর্বাধিক ব্যবহার করুন Make একটি ধীর ব্যবস্থা যা সঠিক ফলাফল দেয় তা দ্রুততর ব্যবস্থার চেয়ে সীমাহীন is

Comments

IMHO it is always best to enforce data integrity rules as near to the data as possibleএটি আসলে আমি অন্ত্রে অনুভূতি সম্পর্কে লিখেছিলাম হিসাবে একই। এবং ঠিক এই কারণেই আমি প্রকৃত ন্যায্যতার সন্ধান করছি। আমাদের জায়গায় কোড পর্যালোচনা এবং ভাল ডকুমেন্টেশন রয়েছে, সুতরাং নতুন বিকাশকারীকে কিছু না জানার বিষয়ে উদ্বেগগুলি পরিবর্তনকে ন্যায়সঙ্গত করার পক্ষে যথেষ্ট নয়।

— সালভাদোর ডালি

কোড পর্যালোচনা এবং ভাল ডকুমেন্টেশন আপনাকে (প্রোগ্রামিং বা অন্যান্য) ত্রুটির বিরুদ্ধে গ্যারান্টি দেয় না।

— ypercubeᵀᴹ

এবং কতজন ডকুমেন্টেশনের সমস্ত (বা এমনকি কোনও) REAL PROGRAMMERSপড়ার আগে কোনও প্রজেক্টে আটকে যাওয়ার আগে যেখানে তারা একটি শক্ত সময়সীমাতে আছেন?

— ভেরেস

আমি একবার একটি ব্যাঙ্কে একটি পর্যালোচনা করেছি যা তাদের ডেটা গুদামের জন্য একই মনোভাব ছিল। তাদের ক্ষেত্রে - কোনও রেফারেন্সিয়াল অখণ্ডতা নেই। ঠিক আছে, 40% পুরানো ডেটা আবর্জনা ছিল কারণ কেউ দস্তাবেজগুলি পড়েনি এবং অনুসন্ধান সারণিতে ডেটা মুছে ফেলেছে। আপনি ডেটা অখণ্ডতার সাথে কোড পর্যালোচনা এবং ডকুমেন্টেশন বিশ্বাস করেন না - আপনি এটি ডাটাবেসে স্পষ্ট করে তুলেছেন।

— টমটম

Answer 2

অন্যদের দ্বারা ইতিমধ্যে মন্তব্যে উদ্ধৃত হিসাবে, NOT NULLআপনার টেবিলের স্পেসিফিকেশনে যুক্ত করা আপনার প্রশ্নের পারফরমেন্সগুলি (অন্য উত্তরে বর্ণিত খুব ভাল পদ্ধতিগত কারণ ছাড়াও) উল্লেখযোগ্য উপায়ে উন্নতি করতে পারে ।

কারণ যে প্রশ্নের সাথে অপটিমাইজার, বুদ্ধিমান যে একটি কলামটি একটি থাকতে পারে না হয় NULLমান, যেমন মানের জন্য বিশেষ পরীক্ষা বাদ পারেন, মত NOT INবনাম NOT EXISTSক্ষেত্রে। উদাহরণস্বরূপ আপনি এই ব্লগটি দেখতে পাচ্ছেন , যেখানে এটি দেখানো হয়েছে যে NOT NULLকোনও নির্দিষ্ট ক্যোয়ারির সাথে ক্ষেত্রটি (যখন টেবিলটিতে সর্বদা নাল মান থাকে) ঘোষণা না করা কার্যকর করার সময়কাল 500% বৃদ্ধি করে। ফলাফলটি এসকিউএল সার্ভারের জন্য দেখানো হয়েছে, তবে অনুরূপ আচরণটি আপনার মতো অন্যান্য রিলেশনাল ডিবিএমএসে উপস্থিত থাকতে পারে (আপনার ডাটাবেসটি অন্য সিস্টেমে পোর্ট করা যেতে পারে তা উল্লেখ করার জন্য নয়)। একটি সাধারণ নিয়ম যা আপনি ধরে নিতে পারেন তা হ'ল যখন ক্যোয়ারী অপ্টিমাইজারটিতে আরও তথ্য পাওয়া যায়, তখন আরও কার্যকর অ্যাক্সেস পরিকল্পনা তৈরি করা যায়।

Comments

ধন্যবাদ. আমি যে উত্তরটির সন্ধান করছিলাম এটি এটি।

— সালভাদোর ডালি

যে কলামগুলিতে কখনই NULL থাকে না, সেগুলি NOT NULLএকাধিক কারণে সংজ্ঞায়িত করা উচিত , এটি সম্পর্কে কোনও যুক্তি নেই। তবে এসকিউএল সার্ভার সম্পর্কে ব্লগের লিঙ্কটি পোস্টগ্রিসের জন্য প্রযোজ্য নয় এবং আপনি উল্লেখ করেছেন এমন কোনও পারফরম্যান্সের প্রভাবের প্রমাণ দেয় না। কোনও নেই বলে বলছি না, তবে আমি প্রকৃত প্রমাণ দেখতে পছন্দ করব ।

— এরউইন ব্র্যান্ডসেটেটার

@ আরউইন ব্র্যান্ডসটেটার, পোস্টগ্র্রেএসকিউএল অপ্টিমাইজার সম্পর্কে আমার অনেক বেশি প্রত্যাশা ছিল :( বেশ কয়েকটি পরীক্ষার পরেও আমি পোস্টগ্র্রেএসকিউএল-তে ব্লগের উপস্থাপন করা নন-ইন প্রশ্নের সাথে উল্লেখযোগ্য পার্থক্য খুঁজে পাইনি, তাই আমি উত্তরটি পরিবর্তন করেছি। , এবং আপনাকে জিজ্ঞাসা করছি যে আপনি কি ভাবেন যে আমার এটি পুরোপুরি মুছে ফেলা উচিত

— রেনজো

না, আমি মনে করি এটি মুছে ফেলা উচিত। এর একটিতে 5 + ভোট এবং কোনও ডাউনভোট নেই।

— ypercubeᵀᴹ

not inনালামযোগ্য কলামগুলির শব্দার্থতত্ত্ব আলাদা তবে যদিও উভয়ের মধ্যে পরিকল্পনার কিছুটা পার্থক্য থাকতে হবে ?

— মার্টিন স্মিথ

Answer 3

স্থান জড়িত

এই স্থানটিতে স্থানটি সম্পর্কে ইমরিন ব্র্যান্ডস্টেটরের কথা বলা হয়েছে

সংক্ষেপে, আপনার ডাটাবেসটি থাকলে আপনি totalColumns - 8নিকটতম বাইট (বা MAXALIGN) পর্যন্ত এক বিটগুলি সংরক্ষণ করতে পারবেন

1. 8 টিরও বেশি কলাম
2. টেবিলের সমস্ত কলাম রয়েছেNOT NULL

পারফরম্যান্স জড়িত

যাইহোক, এসই এর পোস্টে এ্যারউইন ব্র্যান্ডসেটেটার লিখেছেন , তিনি বলেছেন

1. "পারফরম্যান্সে নূন সিলেটিংয়ের কোনও প্রভাব নেই has চেকটির জন্য কয়েকটি চক্র - অপ্রাসঙ্গিক।"
2. "... প্রকৃতপক্ষে ডামি মানের পরিবর্তে NULL ব্যবহার করার মাধ্যমে data

@ রেঞ্জোর একটি উত্তর রয়েছে যা পারফরম্যান্সের প্রভাব সম্পর্কে আলোচনা করে - আমি ধরে নিব যে এর কোনওটি পোস্টগ্র্রেএসকিউএল এর জন্য প্রযোজ্য নয় । আমি কিছু খুঁজে পেতে পারে সত্যতা কোনো যে পোস্টগ্রি প্রাসঙ্গিক মাত্র। চক্র যা কিছু রক্ষা পেয়েছে তা এমনকি সবচেয়ে প্রাথমিক প্রশ্নের মধ্যেও পরিমাণমতো করা যায় না।

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;

এছাড়াও আমি এনওএলএল-সূচকগুলি আরও দ্রুততর ছিল কিনা তা দেখার জন্য আমি কয়েকটি পরীক্ষা চালিয়েছি এবং আমি তা প্রমাণ করতে পারি না। স্কট মার্লোয়ের মেলিং তালিকাগুলিতে আপনি এই দুর্দান্ত ব্যবহারের থ্রেডটি খুঁজে পেতে পারেন যা কোয়েরি পরিকল্পনাকারী সম্পর্কে 9.1 তে আলোচনা করেছে যেখানে পৃথক পৃথক দফায় আংশিক সূচক ব্যবহার করতে সক্ষম হবে। আমি নিম্নলিখিতটি চালিয়ে পরীক্ষা করেছি

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যথাক্রমে NULL বা 0 অনুসন্ধান করার সময় সেক স্ক্যানের জন্য নির্বাচন করার সময় সূচীটি ব্যবহার করতে সক্ষম হন । উভয় আংশিক সূচক একই আকার ছিল। এবং, পূর্ণ সূচকগুলি (দেখানো হয়নি) একই আকার ছিল। একই পদ্ধতি অনুসরণ করে আমি একটি ক্রম 1..1e5, এবং একটি নাল / 0 মান এবং অন্য ক্রম সহ টেবিলটি লোড করেছি 1..1e5। উভয় পদ্ধতিই পুরো টেবিলটি coveringেকে একটি সূচক সহ নাল / 0 খুঁজে পেতে সক্ষম হয়েছিল।

TLDR; সারসংক্ষেপ

পরিকল্পনাকারী অপ্রত্যাশিততা অন্তর্ভুক্ত করার জন্য যে পারফরম্যান্স উদ্বেগকে আমি পরীক্ষামূলক বলে মনে করেছি তার বেশিরভাগ ক্ষেত্রেই আমি একভাবে বা অন্য কোনও কিছুকে প্রমাণ করতে পারি না। র‌্যাম বাঁচাতে নাল ব্যবহার করার সুবিধাটি আসল। নাল ব্যবহার না করে সংরক্ষণ করা ডিস্কের স্থান নগণ্য, এবং এটি একটি কলামযুক্ত টেবিলগুলিতে NULLABLEবা 8 টিরও কম কলামের তুলনায় অত্যধিক পর্যায়ক্রমে । এই ক্ষেত্রে কোনও ডিস্কের স্থান সংরক্ষিত নেই।