যে ওয়েব অ্যাপ্লিকেশনটিতে আমি কাজ করছি তার মধ্যে, সমস্ত ডাটাবেস ক্রিয়াকলাপ সত্তা ফ্রেমওয়ার্ক ওআরএম এর উপরে সংজ্ঞায়িত কিছু জেনেরিক রিপোজিটরিগুলি ব্যবহার করে বিমূর্ত করা হয়।
তবে জেনেরিক সংগ্রহস্থলের জন্য একটি সাধারণ নকশা তৈরি করতে, সমস্ত জড়িত সারণীগুলির একটি অনন্য পূর্ণসংখ্যা ( Int32
সি # তে, int
এসকিউএল মধ্যে) অবশ্যই সংজ্ঞায়িত করতে হবে । এখন অবধি, এটি সর্বদা টেবিলের পিকে এবং এছাড়াও ছিলIDENTITY
।
বিদেশী কীগুলি ভারী ব্যবহৃত হয় এবং তারা এই পূর্ণসংখ্যা কলামগুলি উল্লেখ করে। এগুলি উভয় ধারাবাহিকতার জন্য এবং ওআরএম দ্বারা নেভিগেশনাল সম্পত্তি তৈরির জন্য প্রয়োজনীয়।
অ্যাপ্লিকেশন স্তরটি সাধারণত নিম্নলিখিত ক্রিয়াকলাপগুলি করে:
- সারণী (*) থেকে প্রাথমিক ডেটা লোড -
SELECT * FROM table
- আপডেট -
UPDATE table SET Col1 = Val1 WHERE Id = IdVal
- মুছুন -
DELETE FROM table WHERE Id = IdVal
- সন্নিবেশ -
INSERT INTO table (cols) VALUES (...)
কম ঘন ঘন অপারেশন:
- বাল্ক সন্নিবেশ -
BULK INSERT ... into table
সমস্ত ডেটা লোড (উত্পন্ন সনাক্তকারী পুনরুদ্ধার করতে) অনুসরণ করে (*) - বাল্ক মুছুন - এটি একটি সাধারণ মুছে ফেলা অপারেশন, তবে ওআরএমের দৃষ্টিকোণ থেকে "বাল্কি":
DELETE FROM table where OtherThanIdCol = SomeValue
- বাল্ক আপডেট - এটি একটি সাধারণ আপডেট অপারেশন, তবে ওআরএমের দৃষ্টিকোণ থেকে "বাল্কি":
UPDATE table SET SomeCol = SomeVal WHERE OtherThanIdCol = OtherValue
* সমস্ত ছোট টেবিল অ্যাপ্লিকেশন পর্যায়ে ক্যাশে করা হয় এবং প্রায় সবগুলি SELECTs
ডাটাবেসে পৌঁছায় না। একটি সাধারণ প্যাটার্ন হ'ল প্রাথমিক লোড এবং প্রচুর INSERT
এস, UPDATE
এস এবং DELETE
এস।
বর্তমান অ্যাপ্লিকেশন ব্যবহারের ভিত্তিতে, যে কোনও সারণীতে 100 এম রেকর্ডে পৌঁছানোর খুব কম সম্ভাবনা রয়েছে।
প্রশ্ন: ডিবিএর দৃষ্টিকোণ থেকে, এই টেবিল ডিজাইনের সীমাবদ্ধতা রেখে আমি যে উল্লেখযোগ্য সমস্যাগুলি চালাতে পারি?
[Edit]
উত্তরগুলি (দুর্দান্ত প্রতিক্রিয়াটির জন্য ধন্যবাদ) এবং রেফারেন্স করা নিবন্ধগুলি পড়ার পরে আমার মনে হচ্ছে আমাকে আরও বিশদ যুক্ত করতে হবে:
বর্তমান অ্যাপ্লিকেশন সুনির্দিষ্ট - আমি বর্তমান ওয়েব অ্যাপ্লিকেশন সম্পর্কে উল্লেখ করিনি, কারণ আমি বুঝতে চাই যে অন্যান্য অ্যাপ্লিকেশনগুলির জন্যও মডেলটি পুনরায় ব্যবহার করা যেতে পারে। তবে, আমার বিশেষ কেসটি এমন একটি অ্যাপ্লিকেশন যা একটি ডিডাব্লুএইচ থেকে প্রচুর মেটাডেটা বের করে। উত্স ডেটাটি বেশ অগোছালো (একটি অদ্ভুত উপায়ে অস্বীকৃত, কিছু ক্ষেত্রে অসঙ্গতি রয়েছে, অনেক ক্ষেত্রে কোনও প্রাকৃতিক শনাক্তকারী ইত্যাদি নেই) এবং আমার অ্যাপ্লিকেশনটি পৃথক পৃথক সত্তা উত্পন্ন করছে। এছাড়াও, উত্পাদিত অনেক শনাক্তকারী (
IDENTITY
) প্রদর্শিত হয়, যাতে ব্যবহারকারী তাদের ব্যবসায়ের কী হিসাবে ব্যবহার করতে পারেন। এটি একটি বিশাল কোড রিফ্যাক্টরিংয়ের পাশাপাশি জিইউইডি ব্যবহার বাদ দেয় ।"সারি আলাদা আলাদাভাবে চিহ্নিত করার একমাত্র উপায় তাদের হওয়া উচিত নয়" (অ্যারন বারট্র্যান্ড ♦) - এটি খুব ভাল পরামর্শ। আমার সমস্ত টেবিলগুলি ব্যবসায়ের সদৃশ মঞ্জুরিপ্রাপ্ত নয় তা নিশ্চিত করার জন্য একটি অনন্য চুক্তিও সংজ্ঞায়িত করে।
ফ্রন্ট-এন্ড অ্যাপ্লিকেশন চালিত ডিজাইন বনাম ডাটাবেস চালিত ডিজাইন - নকশার পছন্দটি এই কারণগুলির কারণে ঘটে
সত্তা ফ্রেমওয়ার্ক সীমাবদ্ধতা - একাধিক কলাম পিকে অনুমোদিত, তবে তাদের মান আপডেট করা যায় না
কাস্টম সীমাবদ্ধতা - একটি একক পূর্ণসংখ্যা কী থাকা তথ্য স্ট্রাকচার এবং নন- এসকিউএল কোডকে বিস্তৃত করে। উদাহরণস্বরূপ: মানগুলির সমস্ত তালিকার একটি পূর্ণসংখ্যা কী এবং প্রদর্শিত মান রয়েছে। আরও গুরুত্বপূর্ণ, এটি গ্যারান্টি দেয় যে ক্যাশে করার জন্য চিহ্নিত কোনও টেবিল একটি
Unique int key -> value
মানচিত্রে রাখতে সক্ষম হবে ।
জটিল নির্বাচন জিজ্ঞাসা - এটি প্রায় কখনও ঘটবে না কারণ সমস্ত ছোট (<20-30K রেকর্ড) সারণী ডেটা অ্যাপ্লিকেশন স্তরে ক্যাশে করা হয়। অ্যাপ্লিকেশন কোড লেখার সময় এটি জীবনকে আরও শক্ত করে তোলে (লিনকুই লিখতে কষ্টকর), তবে ডাটাবেসটি খুব সুন্দর হয়েছে:
তালিকাগুলি দর্শন -
SELECT
লোডের উপর কোনও প্রশ্ন উত্পন্ন করবে না (সমস্ত কিছু ক্যাশে করা হয়েছে) বা এর মতো দেখতে কোয়েরিগুলি:SELECT allcolumns FROM BigTable WHERE filter1 IN (val1, val2) AND filter2 IN (val11, val12)
অন্যান্য সমস্ত প্রয়োজনীয় মানগুলি ক্যাশে লকআপের (ও (1)) মাধ্যমে আনা হয়েছে, সুতরাং কোনও জটিল কোয়েরি তৈরি করা হবে না।
দর্শনগুলি সম্পাদনা করুন - এ জাতীয়
SELECT
বিবৃতি উত্পন্ন করবে :SELECT allcolumns FROM BigTable WHERE PKId = value1
(সমস্ত ফিল্টার এবং মানগুলি int
হ'ল)