প্রতিটি কলামের জন্য পূর্বনির্ধারিত ডেটা টাইপ সেট করে রিলেশনাল ডাটাবেসগুলি কী লাভ করে?

44

আমি এই মুহূর্তে একটি এসকিউএল ডাটাবেস নিয়ে কাজ করছি এবং এটি আমাকে সর্বদা আগ্রহী করে তুলেছে, তবে গুগল অনুসন্ধানগুলি তেমন পরিবর্তন করে না: কঠোর ডেটা কেন?

আমি বুঝতে পারছি কেন আপনার কাছে কয়েকটি পৃথক ডেটা প্রকার থাকবে, উদাহরণস্বরূপ, বাইনারি এবং সরল পাঠ্য ডেটার মধ্যে পার্থক্য কীভাবে গুরুত্বপূর্ণ । বাইনারি ডেটা 1 এবং 0 এর দশকে প্লেইন টেক্সট হিসাবে সংরক্ষণ করার পরিবর্তে, আমি এখন বুঝতে পারি যে বাইনারি ডেটাটিকে তার নিজস্ব ফর্ম্যাট হিসাবে সংরক্ষণ করা আরও দক্ষ।

কিন্তু আমি না বুঝতে কি লাভ থাকার হয় তাই অনেক বিভিন্ন ধরনের তথ্য:

কেন mediumtext, longtextএবং text?
কেন decimal, floatএবং int?
প্রভৃতি

ডাটাবেসটি বলার সুবিধা কী "এই কলামে প্রবেশের ক্ষেত্রে কেবল 256 বাইট প্লেইন ডেটা থাকবে" " বা "এই কলামটিতে 16,777,215 বাইট অবধি পাঠ্য প্রবেশিকা থাকতে পারে"?

এটি কি পারফরম্যান্সের সুবিধা? যদি তা হয় তবে হাতের পারফরম্যান্সের আগে প্রবেশের আকারটি কেন জেনে রাখা উচিত? না বরং একেবারে অন্য কিছু?

— জন দো
সূত্র

2

আমি ভেবেছিলাম এই প্রশ্নটি ইতিমধ্যে এখানে উপস্থিত থাকা উচিত, তবে আমি সাইটটি অনুসন্ধান করেছি এবং কোনও কার্যকর খুঁজে পাইনি।

— জন

1

খুব প্রাসঙ্গিক: joelonsoftware.com/2001/12/11/back-to-basics

— বিট্রি

6

আপনার যদি স্বতন্ত্র decimal, floatএবং intপ্রকারগুলি না থাকে তবে আপনি কী করবেন বলে আশা 1 / 3করবেন? কি হবে 1.0 / 3.0? আপনি কি আত্মবিশ্বাসী হতে পারেন যে এর columnAদ্বারা ভাগ করলে columnBআপনি প্রত্যাশিত ফলাফল পাবেন?

— অ্যান্ড্রু বলেছেন মিনিকা পুনরায়

2

@ জোহান্দো আমি কখনই এটি প্রয়োজনীয় হবে বলে মনে করি না তবে এটি খুব সুবিধাজনক হতে পারে। ধরা যাক আপনি কোনও সীমাবদ্ধতা প্রয়োগ করতে চান যে কোনও স্টোরের ইনভেন্টরিগুলি তাদের মাসিক প্রত্যাশিত বিক্রয়ের 5% এর চেয়ে কম হতে পারে না। অথবা আপনি নিশ্চিত করতে চান যে প্রতিটি বিভাগের মোট বাজেট মোট বাজেটের 20% এর বেশি নয়। এটি একই ডেটাবেস ব্যবহার করে বিভিন্ন অ্যাপ্লিকেশনগুলিতে একইভাবে গণনা করতে চান এমন গণিত কলামগুলিতেও আসতে পারে।

— অ্যান্ড্রু বলছেন

2

এটি লক্ষণীয় যে এসকিউএলাইট প্রতিটি কলামে পূর্বনির্ধারিত প্রকার সেট করে না : "এসকিউএলাইট" টাইপলেস "This এর অর্থ হল যে কলামের ঘোষিত ডেটাটাইপ নির্বিশেষে আপনি যে কোনও ধরণের ডেটা যে কোনও টেবিলের যে কোনও সারণীতে রাখতে পারবেন। "

— প্রাইম

50

এসকিউএল একটি স্ট্যাটিক্যালি টাইপ করা ভাষা। এর অর্থ এটি একটি ভেরিয়েবল (বা ক্ষেত্র, এই ক্ষেত্রে) ব্যবহার করার আগে আপনাকে কী টাইপ করতে হবে তা জানতে হবে। এটি গতিশীল-টাইপযুক্ত ভাষার বিপরীত, যেখানে এটি অগত্যা হয় না।

এর মূল অংশে, এসকিউএল একটি সম্পর্কিত সম্পর্কিত ডাটাবেস ইঞ্জিনে ডেটা ( ডিডিএল ) এবং অ্যাক্সেস ডেটা ( ডিএমএল ) সংজ্ঞায়িত করতে ডিজাইন করা হয়েছে । স্ট্যাটিক টাইপিং এই ধরণের সিস্টেমে ডায়নামিক টাইপিংয়ের বিভিন্ন সুবিধা উপস্থাপন করে।

নির্দিষ্ট রেকর্ডগুলি দ্রুত অ্যাক্সেসের জন্য ব্যবহৃত সূচকগুলি , আকারটি স্থির হয়ে গেলে সত্যই ভাল কাজ করে। এমন একটি ক্যোয়ারী বিবেচনা করুন যা সম্ভবত একাধিক ক্ষেত্রের সাথে একটি সূচককে ব্যবহার করে: যদি ডেটা টাইপ এবং আকারগুলি সময়ের আগে জানা থাকে তবে আমি খুব দ্রুত আমার সূচকটির (যেখানে ক্লজ বা যোগিনের মানদণ্ড) সূচকের মানগুলির সাথে তুলনা করতে এবং পছন্দসই রেকর্ডগুলি দ্রুত খুঁজে পেতে পারি ।
দুটি পূর্ণসংখ্যার মান বিবেচনা করুন । ডায়নামিক টাইপ সিস্টেমে এগুলি পরিবর্তনশীল আকারের হতে পারে (ভাবেন জাভা BigInteger, বা পাইথনের বিল্ট-ইন স্বেচ্ছাচারিতা-যথার্থ পূর্ণসংখ্যা)। আমি যদি পূর্ণসংখ্যার তুলনা করতে চাই তবে প্রথমে তাদের বিট দৈর্ঘ্যটি আমার জানা উচিত। এটি পূর্ণসংখ্যার তুলনার একটি দিক যা মূলত আধুনিক ভাষাগুলি দ্বারা লুকানো থাকে তবে সিপিইউ স্তরে এটি খুব বাস্তব। মাপগুলি স্থির এবং সময়ের আগে জানা থাকলে, প্রক্রিয়া থেকে একটি সম্পূর্ণ পদক্ষেপ সরানো হবে। আবার, ডাটাবেসগুলি যত তাড়াতাড়ি সম্ভব লক্ষ লক্ষ লেনদেন প্রক্রিয়া করতে সক্ষম হবে বলে মনে করা হচ্ছে। গতি রাজা।
এসকিউএল 1970 এর দশকে ফিরে ডিজাইন করা হয়েছিল। মাইক্রোকম্পিউটিংয়ের আগের দিনগুলিতে স্মৃতি ছিল একটি প্রিমিয়ামে। সীমিত ডেটা স্টোরেজ প্রয়োজনীয়তাগুলি পরীক্ষা করে রাখতে সহায়তা করে। যদি কোনও পূর্ণসংখ্যা কখনই এক বাইটের চেয়ে বড় হয় না, তবে কেন এটির জন্য আরও সঞ্চয়স্থান বরাদ্দ করা হবে? সীমিত স্মৃতির যুগে জায়গাটি নষ্ট হয়। এমনকি আধুনিক সময়েও, এই অতিরিক্ত নষ্ট হওয়া বাইটগুলি সিপিইউ'র ক্যাশের কর্মক্ষমতা যুক্ত করতে এবং হত্যা করতে পারে। মনে রাখবেন, এগুলি হ'ল ডাটাবেস ইঞ্জিনগুলি যা কেবল আপনার সামান্য বিকাশের পরিবেশ নয়, প্রতি সেকেন্ডে কয়েক শত লেনদেন পরিবেশন করছে।
সীমিত স্টোরেজের লাইনের পাশাপাশি, স্মৃতিতে একক পৃষ্ঠায় একটি একক রেকর্ড ফিট করতে এটি সহায়ক। একবার আপনি একটি পৃষ্ঠার ওপরে গেলে, আরও পৃষ্ঠা মিস এবং আরও ধীর মেমরি অ্যাক্সেস থাকে। নতুন ইঞ্জিনগুলির এটিকে কম ইস্যু করার জন্য অপ্টিমাইজেশন রয়েছে, তবে এটি এখনও রয়েছে। যথাযথভাবে ডেটা মাপার মাধ্যমে, আপনি এই ঝুঁকি হ্রাস করতে পারেন।
Moreso আধুনিক সময়ের মধ্যে, এসকিউএল মাধ্যমে অন্যান্য ভাষায় করার জন্য প্লাগ ব্যবহার করা হয় ORM বা ODBC অথবা অন্য কোনো স্তর। এর মধ্যে কয়েকটি ভাষার শক্তিশালী, স্থির প্রকারের প্রয়োজন সম্পর্কে নিয়ম রয়েছে। আরও কঠোর প্রয়োজনীয়তার সাথে সামঞ্জস্য করা সবচেয়ে ভাল, কারণ গতিশীলভাবে-টাইপ করা ভাষাগুলি স্থির প্রকারের সাথে অন্য চারপাশের চেয়ে সহজ আচরণ করতে পারে।
এসকিউএল স্থিতিশীল টাইপিংকে সমর্থন করে কারণ উপরের চিত্রের মতো কার্য সম্পাদনের জন্য ডাটাবেস ইঞ্জিনগুলির এটির প্রয়োজন।

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

— gruszczy
সূত্র

এসকিউএলাইটে ডেটাটাইপ রয়েছে যা সংখ্যাসূচক এবং পাঠ্য উপাত্তের মধ্যে পার্থক্য রাখে, তবে কেবলমাত্র ডেটা স্টোরেজের 5 টি "শ্রেণি" রয়েছে: sqlite.org/datatype3.html

— হতাশ

1

@ ফ্রাস্ট্রেটড উইথফর্মস ডিজাইনার আমি জানি, তবে এটি এখনও এসকিউএল সার্ভার, ওরাকল বা পোস্টগ্রিসকিউএল এর মতো ইঞ্জিনগুলির মতো কঠোর নয়।

এসকিউএল কেবল স্থিতিযুক্ত টাইপই নয় - চেক সীমাবদ্ধতার উপস্থিতির কারণে এটি কার্যকরভাবে পরিশোধন প্রকারকে সমর্থন করে।

— উদ্যানক্ষেত্র

4

যদিও প্রথম বুলেটে অন্তর্ভুক্ত করা হয়েছে Indexes, আরও মূলত বলা হয়েছে: একটি ডাটা টাইপ থাকার ফলে ডাটাবেস ইঞ্জিনটি ডেটা বোধ করতে পারে, তুলনা করে (বড় / ছোট সংখ্যা, আগের / পরে তারিখের সময়, বর্ণমালার আগে / পরে), এবং তাই বাছাই এবং জিজ্ঞাসা সক্ষম করে ।

— বাসিল বাউরেক

সুতরাং যদি আকারগুলি গুরুত্বপূর্ণ হয় ... এবং স্কুএলটির আগে জানা দরকার ... "জিলিয়ন" লেনদেনের সঠিক আকারটি কী?

— WernerCD

24

প্রথম: সরল পাঠ্যটি বাইনারি (এটি এমনকি ইউটিএফ 8 বা এএসসিআইআই অক্ষর "0" এবং "1" নয় তবে প্রকৃত অন / অফ বিট)

যা বলেছিল, এর কয়েকটি কারণ হ'ল:

ব্যবসায় / নকশার সীমাবদ্ধতা: পার্সন টেবিলের উচ্চতা কলামে 7626355112 সংখ্যাটি মঞ্জুরি দেওয়া ভুল হবে। একটি ইনভয়েসের তারিখ কলামে "হাওয়ার" অনুমতি দেওয়া ভুল হবে।
কম ত্রুটিযুক্ত প্রোন কোড: একটি তারিখ কলাম থেকে প্রাপ্ত ডেটা সত্যই একটি তারিখ তা নিশ্চিত করার জন্য আপনাকে কোড লিখতে হবে না। কলামের প্রকারগুলি যদি গতিশীল হয় তবে সেগুলি পড়ার সময় আপনাকে প্রচুর ধরণের চেক করতে হবে।
কম্পিউটিং দক্ষতা: যদি কোনও কলাম INTEGER প্রকারের হয় এবং আপনি এটি সুম () করেন তবে আরডিবিএমএসকে ভাসমান পয়েন্ট গাণিতিক প্রয়োগ করতে হবে না।
স্টোরেজ দক্ষতা: উল্লেখ করে যে একটি কলাম VARCHAR (10), আরডিবিএমএসকে আরও সুনির্দিষ্টভাবে স্থান বরাদ্দ করতে দেয়।
রেফারেনশিয়াল অখণ্ডতা এবং ইউনিটিসিটি: কোনও টেবিলের পিকে (বা এফকে) ভাসা চলতে দেওয়া উচিত নয়, যেহেতু ভাসমান পয়েন্ট সমতা তাত্পর্যপূর্ণ, তাই আপনাকে অবশ্যই অক্ষর বা পূর্ণসংখ্যার মতো একটি নন-ফ্লোট টাইপের মধ্যে তাদের ঘোষণা করতে হবে।
গতিশীল (কঠোর নয়) কলামের ধরণের (এসকিউলাইট) সাথে আরডিবিএমএস রয়েছে । এটি "টাইপ অ্যাফিনিটি" ধারণাটি ব্যবহার করে এখনও আপনাকে কোনও অভিযোগ ছাড়াই যে কোনও কলামে কার্যত কিছু sertোকানোর অনুমতি দেয়। এখানে ট্রেড-অফ রয়েছে যা এখানে আলোচনা করা হবে না। এই প্রশ্নটি দেখুন ।

— তুলিনেস কর্ডোভা
সূত্র

8

এটি তাই যে ডাটাবেসে লিখিত অন্তর্নিহিত কোডটি নির্দিষ্ট আকারের রেকর্ডগুলি বরাদ্দ করতে এবং ব্যবহার করতে পারে, যদি এটি জানে যে কোনও নির্দিষ্ট ক্ষেত্রে 0 থেকে 256 টি পাঠ্যের অক্ষর থাকতে পারে তবে এটি এটি সংরক্ষণ করতে 256 বাইটের একটি ব্লক বরাদ্দ করতে পারে।

এটি জিনিসগুলিকে আরও দ্রুত করে তোলে, যেমন আপনাকে ব্যবহারকারীর হিসাবে অতিরিক্ত স্টোরেজ বরাদ্দ করতে হবে না, যেহেতু প্রদত্ত ক্ষেত্রটি সর্বদা রেকর্ডের মধ্যে এক্স বাইটগুলি অনুসন্ধান শুরু করে বা সেই ক্ষেত্রটিতে নির্বাচন করে প্রতিটি রেকর্ডে সর্বদা এক্স বাইট চেক করতে জানে etc.

— স্টিভ বার্নেস
সূত্র

যদি কেবল সমস্ত উত্তরই এই সংক্ষিপ্ত এবং পয়েন্ট হতে পারে ...

— ড্যারেন রিঞ্জার

6

যখন একটি ডাটাবেসের কলামগুলি সংজ্ঞায়িত প্রকারগুলি দেওয়া হয়, তখন সাধারণত বিটগুলিতে একটি নির্দিষ্ট আকারের জন্য তাদের টাইপগুলি সাধারণত সংজ্ঞায়িত করা হয়। ফলস্বরূপ:

1) যখন ডাটাবেস ইঞ্জিনটি একটি সারণীতে সারিগুলি অতিক্রম করছে তখন প্রতিটি রেকর্ডটি কোথায় শেষ হয় তা নির্ধারণের জন্য কোনও অভিনব পার্সিং করতে হবে না, এটি কেবল জানতে পারে যে প্রতিটি সারিটি 32 বাইট নিয়ে থাকে এবং তাই পেতে পরবর্তী রেকর্ড এটি বর্তমান রেকর্ড অবস্থান 32 বাইট যোগ করার জন্য যথেষ্ট।

২) সারিবদ্ধের মধ্যে কোনও ক্ষেত্র সন্ধান করার সময়, কোনও কিছুর পার্সিং না করেই আবার সেই ক্ষেত্রটির জন্য একটি নিখুঁত অফসেট জানা সম্ভব হয়, সুতরাং কলামের অনুসন্ধানগুলি সম্ভাব্য ব্যয়বহুল ডেটা প্রসেসিংয়ের পরিবর্তে একটি সাধারণ গাণিতিক অপারেশন।

— ব্যবহারকারী খুঁজে পাওয়া যায় না
সূত্র

স্থির দৈর্ঘ্যের ক্ষেত্রগুলি ধারাবাহিক রেকর্ড দৈর্ঘ্য এবং ফিল্ড অফসেটগুলির কারণে প্রক্রিয়াজাতকরণকে আরও দক্ষ করে তুলতে পারে তবে পরিবর্তনশীল দৈর্ঘ্যের ক্ষেত্রগুলি সেই সুবিধাগুলি বাতিল করতে পারে কারণ রেকর্ড দৈর্ঘ্য এবং ক্ষেত্রের অফসেট পৃথক হতে পারে। একইভাবে, রেকর্ড-স্তরের সংকোচনের ফলে ভেরিয়েবল-দৈর্ঘ্যের রেকর্ডগুলি আসবে, সুতরাং প্রদত্ত রেকর্ডের অবস্থানটি সহজেই গণনা করা যায় না।

— জেনিলোগিক্স

এটি সত্য, এবং ঠিক সেই কারণেই পরিবর্তনশীল দৈর্ঘ্যের ক্ষেত্রগুলি এড়াতে এটি দীর্ঘ সময়ের জন্য সাধারণ পরামর্শ ছিল। আমি জানি না যে বড় খেলোয়াড়েরা এটি কী করে তবে মনে হয় আপনি সম্ভবত কোনও ব্যবহারকারী-দৃশ্যমান সারণী বা মেমরি ব্লকের ইঞ্জিন স্টোর ভেরিয়েবল প্রস্থের ক্ষেত্রগুলি রেখে নির্দিষ্ট দৈর্ঘ্যের কিছু সুবিধা পুনরুদ্ধার করতে সক্ষম হতে পারেন এই ক্ষেত্রগুলির প্রাথমিক টেবিলগুলি এতে একটি (নির্দিষ্ট প্রস্থ) 'পয়েন্টার' হতে পারে। বিবেচনা করে আপনি প্রথমে স্থায়ী দৈর্ঘ্যের ক্ষেত্রগুলির নিয়মিত পুরো স্ক্যান করা উচিত ind

— ব্যবহারকারীর নটফাউন্ড

3

আপনি জিজ্ঞাসা করেছেন কেন ডিবিএমএসের স্থির ডেটা ধরণের থাকে।

দেখার গতি। কোনও ডিবিএমএসের সম্পূর্ণ পয়েন্ট হ'ল আপনি কোনও প্রোগ্রামে সম্ভবত লোড করতে পারার চেয়ে অনেক বেশি ডেটা সঞ্চয় করা। "গত দশ বছরে বিশ্বে উত্পন্ন সমস্ত ক্রেডিট কার্ড স্লিপ" ভাবেন। এই জাতীয় ডেটা দক্ষতার সাথে অনুসন্ধান করার জন্য, নির্দিষ্ট দৈর্ঘ্যের ডেটা প্রকারগুলি সহায়ক। এটি বিশেষত কাঠামোগত ডেটার জন্য যেমন তারিখ স্ট্যাম্প এবং অ্যাকাউন্ট নম্বরগুলির ক্ষেত্রে সত্য। আপনি যদি জানেন যে আপনি আগে যা করছেন তার সাথে আগে, দক্ষ সূচকগুলিতে লোড করা সহজ।
নিখুঁততা এবং সীমাবদ্ধতা। এটিতে নির্দিষ্ট ধরণের ডেটা থাকলে ডেটা পরিষ্কার রাখা আরও সহজ।
ইতিহাস। আরডিবিএমএস শুরু হয়েছিল যখন কম্পিউটারগুলি কয়েক মেগাবাইট র‌্যাম ছিল, এবং টেরাবাইট-স্কেল স্টোরেজটি অত্যন্ত ব্যয়বহুল ছিল। কোনও টেবিলের প্রতিটি সারিতে এক ডজন বাইট সংরক্ষণ করা সেই পরিস্থিতিতে হাজার হাজার ডলার এবং ঘন্টা সময় সাশ্রয় করতে পারে।
গ্রাহক বেস এর অভিশাপ। আরডিবিএমএস আজ খুব জটিল, উচ্চতর অনুকূলিত, সফ্টওয়্যার প্যাকেজগুলি এবং তারা তথ্য সংগ্রহের জন্য কয়েক দশক ধরে ব্যবহৃত হয়ে আসছে। তারা পরিণত। তারা কাজ করে. একটি আরডিবিএমএস ক্র্যাশ, যার ফলে বড় আকারের ডেটা হারাতে পারে এই দিনগুলিতে খুব বিরল। বেশিরভাগ সংস্থার কাছে আরও নমনীয় ডেটা টাইপিং সিস্টেমের সাথে কিছুতে স্যুইচ করা ব্যয় বা ঝুঁকির পক্ষে মূল্য নয়।

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

— ও জোনস
সূত্র

3

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

মিডিয়াম টেক্সট, লম্বটেক্সট এবং পাঠ্য কেন?

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

কেন দশমিক, ভাসা এবং ইনট?

নির্ভুলতার বিভিন্ন স্তরের বিভিন্ন পরিমাণের স্টোরেজ প্রয়োজন এবং প্রতিটি ব্যবহারের ক্ষেত্রে সর্বোচ্চ ডিগ্রি নির্ভুলতার প্রয়োজন হয় না। উদাহরণস্বরূপ, এখানে দেখুন: https://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF50950

ওরাকল বিভিন্ন সংখ্যার বিভিন্ন সংখ্যার সাথে বিভিন্ন স্টোরেজ প্রয়োজনীয়তা এবং সংক্ষিপ্ততার স্তরের এবং সংখ্যার আকারের আকারের ক্ষেত্রে বিভিন্ন ক্ষমতা সহ বিভিন্ন সংখ্যা রয়েছে।

— FrustratedWithFormsDesigner
সূত্র

2

কিছুটা হলেও, এটি .তিহাসিক।

একসময়, পূর্বনির্ধারিত ক্ষেত্রগুলির সমন্বয়ে স্থির দৈর্ঘ্যের রেকর্ডগুলি সমন্বিত ফাইলগুলিতে টেবুলার ডেটা সংরক্ষণ করা হত যেমন প্রদত্ত ক্ষেত্রটি সর্বদা একই রকম এবং প্রতিটি রেকর্ডে একই জায়গায় থাকে। এটি প্রসেসিং দক্ষ করে তোলে এবং কোডিংয়ের জটিলতা সীমিত করে তোলে।

এই জাতীয় কোনও ফাইলে কিছু সূচী যুক্ত করুন এবং আপনার একটি সম্পর্কিত ডেটাবেসের সূচনা রয়েছে।

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

কখনও কখনও কিছু যুক্তিযুক্ত যুক্তি প্রয়োগ করতে ক্ষেত্রের জন্য একটি নির্দিষ্ট আকার নির্ধারণ করা দরকারী - উত্তর আমেরিকার ফোন নম্বরটির জন্য 10 সংখ্যা বলুন। বেশিরভাগ সময় এটি কেবল সামান্য গণনার উত্তরাধিকার মাত্র।

— Zenilogix
সূত্র

1

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

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

— supercat
সূত্র

1

ওয়েব বিকাশকারী হিসাবে আপনি যা কিছু করেন তার জন্য "হুডের নীচে" কী হচ্ছে তা বোঝার দরকার নেই। এমন সময় রয়েছে যখন এটি সাহায্য করে।

ডাটাবেসটি বলার সুবিধা কী "এই কলামে প্রবেশের ক্ষেত্রে কেবল 256 বাইট প্লেইন ডেটা থাকবে" " বা "এই কলামটিতে 16,777,215 বাইট অবধি পাঠ্য প্রবেশিকা থাকতে পারে"?

আপনার সন্দেহ হিসাবে, কারণটি দক্ষতার সাথে করা। বিমূর্ততা ফুটো । SELECT author FROM booksটেবিলের সমস্ত ক্ষেত্রের আকার জানা গেলে এই জাতীয় একটি কোয়েরিটি খুব দ্রুত চলতে পারে।

যেমন জোয়েল বলেছেন,

কীভাবে একটি রিলেশনাল ডাটাবেস বাস্তবায়ন করে SELECT author FROM books? রিলেশনাল ডেটাবেজে, টেবিলের প্রতিটি সারি (যেমন বইয়ের টেবিল) বাইটে হুবহু একই দৈর্ঘ্য এবং প্রতিটি ক্ষেত্র সর্বদা সারির শুরু থেকে একটি নির্দিষ্ট অফসেটে থাকে। সুতরাং, উদাহরণস্বরূপ, বইয়ের টেবিলের প্রতিটি রেকর্ড যদি 100 বাইট লম্বা হয় এবং লেখক ক্ষেত্রটি অফসেট 23 এ থাকে তবে সেখানে 23, 123, 223, 323 ইত্যাদি বাইটে লেখক সংরক্ষণ করা আছে to এই ক্যোয়ারির ফলাফলের পরবর্তী রেকর্ড? মূলত, এটি:

pointer += 100;

একটি সিপিইউ নির্দেশনা। Faaaaaaaaaast।

অনেক সময়, আপনি যে কৌতুকপূর্ণ কৌতুকপূর্ণ নীতির দিক থেকে আপনার যত্ন নেওয়ার দরকার নেই সেগুলি থেকে অনেক দূরে কাজ করছেন। পিএইচপি-ভিত্তিক ওয়েব দেব হিসাবে, আপনার কোডটি কতটি সিপিইউ নির্দেশনা ব্যবহার করে সে সম্পর্কে যত্নশীল ? বেশিরভাগ সময়, না, সত্যই নয়। তবে কখনও কখনও এটি দুটি কারণে জেনে রাখা দরকারী: এটি আপনার গ্রন্থাগারগুলির দ্বারা নেওয়া সিদ্ধান্তগুলি ব্যাখ্যা করতে পারে; এবং কখনও কখনও আপনার নিজের কোডে গতি সম্পর্কে যত্ন নেওয়া প্রয়োজন।

— পরিষ্কার-পরিচ্ছন্ন
সূত্র