আপনি যখন "ব্যবহারকারীর সংজ্ঞায়িত ক্ষেত্রগুলি" পেতে শুরু করেন যা প্রায়শই বাগ ট্র্যাকার, গ্রাহক সংস্থান ব্যবস্থাপনা এবং একই ধরণের ব্যবসায়ের সরঞ্জামগুলিতে পাওয়া যায় তা হ'ল এগুলিতে বাজিলিয়ান ক্ষেত্রগুলি সহ কোনও টেবিলের সাহায্যে ব্যাক করা হয় না (যদি তারা থাকে তবে সম্ভবত সমস্যাটির সমস্যা আছে) নিজস্ব).
পরিবর্তে আপনি যা সন্ধান করেন তা হ'ল বৈধ বৈশিষ্ট্যগুলি পরিচালনা করার জন্য এন্টি অ্যাট্রিবিউট মান সারণি ডিজাইন এবং সম্পর্কিত প্রশাসন সরঞ্জাম।
নিম্নলিখিত টেবিলটি বিবেচনা করুন:
+ + -------------- + +
| জিনিস |
| -------------- |
| আইডি |
| প্রকার |
| desc |
| attr1 |
| attr2 |
| attr3 |
| attr4 |
| attr5 |
+ + -------------- + +
আপনি কয়েকটি অ্যাট্রিবিউট যুক্ত করার পরে এটি। বদলে attr1সাজা এটি সার্চ artistবা tracksবা genreবা যাই হোক না কেন বৈশিষ্ট্যাবলী জিনিস হয়েছে। এবং 5 এর পরিবর্তে, এটি 50 হলে কী হবে ly স্পষ্টতই এটি নিয়ন্ত্রণহীন। একটি নতুন ক্ষেত্র পরিচালনা করতে এটির জন্য মডেলটির একটি আপডেট এবং অ্যাপ্লিকেশনটির পুনরায় নিয়োগের প্রয়োজন requires আদর্শ নয়।
এখন নিম্নলিখিত টেবিল কাঠামো বিবেচনা করুন:
+ -------------- + + --------------- + + ------------- +
| জিনিস | | জিনিস_আত্র | | attr |
| -------------- | | --------------- | | ------------- |
| আইডি | <--- + | | জিনিস_আইডি (এফকে) | + +> | আইডি |
| প্রকার | | attr_id (fk) | + - + | নাম |
| desc | | মান | | |
+ -------------- + + --------------- + + ------------- +
আপনি আপনার জিনিসটিকে এর প্রাথমিক ক্ষেত্রগুলি দিয়ে পেয়েছেন। আপনার আরও দুটি টেবিল রয়েছে। বৈশিষ্ট্য সহ একটি। প্রতিটি ক্ষেত্র attrসারণীতে একটি সারি । এবং তারপরে টেবিলে এবং টেবিলের thing_attrসাথে সম্পর্কিত একজোড়া বিদেশী কী রয়েছে। এবং এরপরে এটির একটি মান ক্ষেত্র রয়েছে যেখানে আপনি সেই সত্তার জন্য ক্ষেত্রের মানটি যা কিছু সঞ্চয় করেন।thingattr
এবং এখন আপনি একটি কাঠামো পেয়েছেন যেখানে রানটাইমের সময় অ্যাটর টেবিল আপডেট করা যায় এবং সামগ্রিক প্রয়োগের উল্লেখযোগ্য প্রভাব ছাড়াই ফ্লাইতে নতুন ক্ষেত্রগুলি যুক্ত করা (বা অপসারণ) করা যেতে পারে।
অনুসন্ধানগুলি কিছুটা জটিল এবং বৈধতা খুব জটিল হয়ে ওঠে (হয় মজাদার সঞ্চিত পদ্ধতি বা সমস্ত ক্লায়েন্টের পক্ষ)। এটি ডিজাইনের একটি বাণিজ্য।
পরিস্থিতিটিও বিবেচনা করুন যেখানে কোনও দিন আপনাকে মাইগ্রেশন করতে হবে এবং আপনি আবেদনে ফিরে আসেন যে আপনি যে স্কিমার মূলত বিতরণ করেছেন তার চেয়ে এখন অর্ধ ডজন বা আরও বেশি বৈশিষ্ট্য রয়েছে। এটি কুৎসিত স্থানান্তর এবং আপগ্রেডগুলির জন্য তৈরি করে যেখানে সত্তা গুণাবলীর মান সারণী, যখন সঠিকভাবে ব্যবহৃত হয়, পরিষ্কার হতে পারে। (সর্বদা নয়, তবে হতে পারে))
রানটাইমে স্কিমা পরিবর্তন করার জন্য কি কোনও ডাউনসাইড রয়েছে? ব্যবহারকারী যদি মনে করেন যে কোনও জিনিসের কোনও নতুন বৈশিষ্ট্য প্রয়োজন, কেবল গতিশীলভাবে টেবিলটিতে একটি কলাম যুক্ত করতে চান?
আপনি যদি নসকিএল ডাটাবেসের উপযুক্ত স্বাদের সাথে কাজ করছেন, আপনি সম্ভবত এটি করতে পারেন (নোট করুন যে এটির জন্য নোসকিএলের উপযুক্ত গন্ধটি সম্ভবত একটি মূল-মূল স্টোর হতে পারে যা ভাল বর্ণিত, সম্পর্কিত বর্ণিত সম্পর্কিত EAV টেবিল) খুব বেশি ঝামেলা ছাড়াই তবে এটি এনওএসকিএলের সমস্ত সমঝোতার সাথে আসে যা অন্য কোথাও দুর্দান্তভাবে বর্ণনা করা হয়।
আপনি যদি পরিবর্তে কোনও সম্পর্কিত ডেটাবেসে কাজ করছেন - আপনার স্কিমা থাকা দরকার। কলামটি গতিশীলভাবে যুক্ত করার অর্থ নিম্নলিখিত জিনিসগুলির কিছু উপসেট সত্য:
- আপনি মেটা-ডাটাবেস প্রোগ্রামিং করছেন। এই কলামটি একটি দুর্দান্ত ওআরএম দিয়ে পরিষ্কারভাবে সেই ক্ষেত্রটিতে ম্যাপ করার সুযোগ না দিয়ে আপনি সম্ভবত
select *ডেটা আসলে কী তা জানার জন্য কিছু জটিল কোড করছেন এবং তারপরে ( জাভার রেজাল্টসেটমেটাডেটা দেখুন ) এবং তারপরে একটি মানচিত্রে সংরক্ষণ করছেন ( বা অন্য কিছু ডেটাটাইপ - তবে কোডে ভাল ক্ষেত্র নয় )। এটির পরে প্রথাগত পদ্ধতির সাথে আপনার টাইপ এবং সুরক্ষার মোটামুটি কিছু ছুঁড়ে যায়।
- আপনি সম্ভবত ORM পরিত্যাগ করেছেন। এর অর্থ আপনি সিস্টেমে আপনার জন্য কাজটি না করার পরিবর্তে সমস্ত কোডের জন্য কাঁচা এসকিএল লিখছেন।
- আপনি ক্লিন আপগ্রেড করা ছেড়ে দিয়েছেন। যখন গ্রাহক আপনার পরবর্তী সংস্করণটিও ব্যবহার করে এমন একটি নাম যুক্ত একটি ক্ষেত্র যুক্ত করে তখন কী ঘটে? ম্যাচমেকিং সাইটটিতে
hasdateএকটি টাইমস্ট্যাম্প সংরক্ষণের জন্য একটি ক্ষেত্র যুক্ত করতে চায় এমন আপগ্রেডটিকে ইতিমধ্যে hasdateএকটি সফল ম্যাচের জন্য বুলিয়ান হিসাবে সংজ্ঞায়িত করা হয়েছে ... এবং আপনার আপগ্রেড ব্রেক।
- আপনি বিশ্বাস করছেন যে গ্রাহক এমন কিছু সংরক্ষিত শব্দ ব্যবহার করে সিস্টেমটি ভাঙ্গেন না যা আপনার কোয়েরিও ভেঙে দেয় ... কোথাও।
- আপনি নিজেকে একটি ডাটাবেস ব্র্যান্ডের সাথে আবদ্ধ করেছেন। DDL বিভিন্ন ডেটাবেসের ভিন্ন। ডাটাবেস টাইপগুলি এটির সবচেয়ে সহজ উদাহরণ।
varchar2বনাম textএবং মত। কলামটি যুক্ত করার কোডটি মাইএসকিউএলে কাজ করবে তবে পোস্টগ্রিস বা ওরাকল বা এসকিউএল সার্ভার নয়।
- আপনি কি গ্রাহকে আসলে ডেটাটি ভালভাবে যুক্ত করতে বিশ্বাস করেন ? অবশ্যই, EAV আদর্শ থেকে অনেক দূরে তবে এখন আপনি এমন কিছু ভয়াবহ অস্পষ্ট টেবিলের নাম পেয়েছেন যা আপনি বিকাশকারী যুক্ত করেন নি, ভুল ধরণের সূচক (যদি থাকে) সহ কোডটিতে কোনও বাধা যুক্ত করা হয়নি যেখানে প্রয়োজন রয়েছে হতে হবে এবং তাই।
- আপনি অ্যাপ্লিকেশনটি চালিত ব্যবহারকারীর জন্য স্কিমা পরিবর্তনের সুযোগসুবিধা দিয়েছেন। লিটল ববি ড্রপ টেবিলগুলি যখন আপনি ডিডিএল এর পরিবর্তে এসকিউএল-তে সীমাবদ্ধ থাকেন তখন সম্ভব হয় না (এটির পরিবর্তে আপনি এটি করতে পারেন তা নিশ্চিত
delete * from students, তবে আপনি খারাপ উপায়ে ডাটাবেসটিকে জগাখিচু করতে পারবেন না)। কোনও দুর্ঘটনা বা দূষিত ক্রিয়াকলাপের স্ক্রোককেট থেকে স্কিমা অ্যাক্সেসের সাথে যে জিনিসগুলি ভুল হতে পারে তার সংখ্যা।
এটি সত্যিই "এটি করবেন না" এ ফোটে। আপনি যদি সত্যিই এটি চান তবে EAV টেবিল কাঠামোর একটি পরিচিত প্যাটার্ন বা পুরোপুরি এই কাঠামোর জন্য উত্সর্গীকৃত একটি ডেটাবেস সহ যান। লোককে কোনও সারণীতে স্বেচ্ছাসেবী ক্ষেত্র তৈরি করতে দেবেন না। মাথাব্যথা ঠিক এটি মূল্যহীন।