ডাটাবেস সারণিতে আইডি কলামের নামকরণ

101

আমি ডাটাবেস টেবিলগুলিতে আইডি কলামগুলির নামকরণের বিষয়ে মানুষের মতামতটি অবাক করেছিলাম।

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

যেখানে আমি ওয়ার্কইন্ড বর্তমান, তারা সমস্ত আইডি কলাম আইডি বলেছে।

সুতরাং তারা নিম্নলিখিতগুলি করতে হবে:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

এখন, আমি এখানে কয়েকটি সমস্যা দেখতে পাচ্ছি:
১. আপনার নির্বাচিত
২ টি কলামগুলিতে উপন্যাসের প্রয়োজন হবে ID আইডি = ইনভয়েসিআইডি আমার মস্তিষ্কে ফিট করে না
3.. আপনি যদি টেবিলগুলিকে উরিফ না দিয়ে থাকেন এবং ইনভয়েসআইডি উল্লেখ করেন তবে এটি কোন টেবিলটি স্পষ্ট obvious এটা চালু?

এই বিষয়ে অন্যান্য ব্যক্তিদের চিন্তাভাবনা কী?

sql  naming-conventions 
— অ্যারারি
সূত্র
— পিএইচপিস্ট
— ফিলিপ্সি

উত্তর:

29

আইডি একটি এসকিউএল অ্যান্টিপ্যাটার্ন। Http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a দেখুন

আইডি হিসাবে আইডি সহ যদি আপনার অনেক টেবিল থাকে তবে আপনি রিপোর্টিংকে আরও জটিল করে তুলছেন। এটি অর্থকে অস্পষ্ট করে এবং জটিল প্রশ্নগুলি পড়া আরও শক্ত করে তোলে পাশাপাশি প্রতিবেদনে আলাদা করার জন্য আপনাকে এলিয়াসগুলি ব্যবহার করার প্রয়োজন হয়।

আরও যদি কেউ উপলব্ধ থাকে যে কোনও ডেটাবেজে প্রাকৃতিক যোগদান ব্যবহার করতে যথেষ্ট বোকামি হয় তবে আপনি ভুল রেকর্ডে যোগ দেবেন।

আপনি যদি কিছু ডিবিএসের অনুমতিপ্রাপ্ত ইউএসিং সিনট্যাক্সটি ব্যবহার করতে চান তবে আপনি আইডি ব্যবহার করতে পারবেন না।

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

সুতরাং আপনি এখন আছে

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

যখন আপনি বোঝাতে চেয়েছিলেন

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

আপনি যদি আইডি ক্ষেত্র হিসাবে টেবিলনামআইডি ব্যবহার করেন তবে এই জাতীয় দুর্ঘটনাজনিত ভুল হওয়ার সম্ভাবনা অনেক কম এবং এটি খুঁজে পাওয়া আরও সহজ।

— এইচএলজিইএম
সূত্র
8
@ স্পেনসার 7593, আপনার আইডি পছন্দ করার কারণে এটি কোনও অ্যান্টিপ্যাটার্ন নয়। আপনি যখন টেবিলের নাম আইডি রাখবেন তখন ভুল করে ভুল করা কঠিন কারণ আপনি তত্ক্ষণাত একটি সিনট্যাক্স ত্রুটি পেয়ে যাবেন।
— এইচএলজিইএম
7
সমান্তরাল +1 কলামগুলির একই নাম থাকা উচিত - টেবিলের নাম উপসর্গ ব্যবহার করে আপনার টেবিলে আইডি নামে একটি প্রাথমিক কী কলাম এবং টেবিল 1 আইড নামে অন্য টেবিলে একটি বিদেশী কী কলাম থাকতে পারে - এবং আপনি জানেন যে সেগুলি একই জিনিস। আমাকে এই 20 বছর আগে শেখানো হয়েছিল এবং এটি এমন একটি অনুশীলন যা আপনাকে হতাশ করে না।
— আমেলভিন
10
না! এই স্মুরফ নামকরণের সম্মেলন!
— রস
20
আমি এই কনভেনশনটি পছন্দ করি না কারণ এর অর্থ হ'ল আপনি আপনার সমস্ত টেবিলের ব্যবহারের জন্য জবাবদিহি করতে বাধ্য হন যাতে আপনি অতিরিক্তভাবে টেবিলটির নাম রাখছেন না, আবার টেবিলটির নামকরণ করবেন না এবং আইডি যুক্ত করুন। join table2 on table1.table1id = table2.table1id। আপনার যুক্তি ঠিক আছে যদি আপনি আইডি ব্যবহার করেন তবে টেবিলের নাম আইডির সামনে যাই হোক না কেন। join table2 on table1.id = table2.table1id... যা ঠিক ততই ভার্জোজ এবং অপ্রয়োজনীয় নয়, বা সুনির্দিষ্ট অযৌক্তিকতা রোধ করতে অস্পষ্ট এলিয়াসগুলিকে জোর করে না .. যা আমার মতে বর্গক্ষেত্রের বিকাশ are
— আনথার
15
তারপরে, যদি Nameকোনও টেবিলে আপনার ক্ষেত্র থাকে, তবে Table1Nameসেই ক্ষেত্রের সাথে একই সমস্যা এড়াতে আপনার কি এটি পরিবর্তন করা উচিত ? একই কারণে কি টেবিলের নাম সহ সমস্ত কলামগুলি উপসর্গ করা উচিত? এটি ঠিক শোনাচ্ছে না।
— জোয়ানভো
154

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

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

— kemiller2002
সূত্র
4
আমি একটি পুরানো থ্রেড বুঝতে পারি কিন্তু আমি সম্মত হই। এছাড়াও ডেটা অ্যাক্সেস লেয়ারে ম্যাপিংকে আরও সহজ করে তোলে: যদি সমস্ত "অবজেক্টস" এর আইডি ক্ষেত্র থাকে যা অনন্য হতে হয় তবে ডাটা অ্যাক্সেস লেয়ারে পদ্ধতি তৈরি করার সময় আইটেমগুলি মুছার মতো কাজগুলি করার জন্য আপনি এগুলি জেনেরিক করতে পারেন যেহেতু আপনি একটি তালিকা পেতে পারেন যে কোনও আইডির জন্য এবং জেনে রাখুন যে প্রতিটি টেবিলের জন্য অনন্য কি ম্যাপিং পাশাপাশি টেবিলের নাম / প্রোগ্রামের যুক্তির নাম ম্যাপিংয়ের পরিবর্তে আপনাকে সেই নির্দিষ্ট টেবিলটি থেকে আইডি = ব্লাহ কোথায় মুছে ফেলতে হবে।
— মাইক
4
কেভিন, তোমার মতোই উদাহরণস্বরূপ: ইউজার_আইডি, পিকেয়ের জন্য রোল_আইডি এবং এফকেয়ের জন্য ভূমিকা_user_id। এটি একটি বৃহত আকারের প্রকল্পে ভাল। কারণ যদি সমস্ত আইডি ক্ষেত্রের নাম "আইডি" রাখা হয় তবে এটি খুব বিভ্রান্ত। তবে আমি এটি ব্যক্তিগত পছন্দ বলে মনে করি, কেউ কেউ কেবল "আইডি" ব্যবহার স্পষ্ট বলে মনে করেন।
— চেউং
4
এটি আমার পছন্দ। ক্রস টেবিলের ক্যোয়ারীগুলি পড়া আরও কঠিন বলে এর অর্থ এই নয় যে আইডি কলামটি এটি আরও সহজ করার জন্য পরিবর্তন করা উচিত। কেবল আপনার এলিয়াসগুলি আরও বর্ণনামূলক করুন।
— tmutton
4
আমি সন্দেহ করি যে সত্তা নাম সহ আইডি উপসর্গকরণের কনভেনশনটি যে কোনও কারণেই "নির্বাচন করুন" থেকে লোকেদের ব্যবহার থেকে আসে। "সিলেক্ট *" করতে সহিষ্ণু পরিবেশে, বাস্তবতা সাধারণত সর্বত্র থেকে সমস্ত কিছুর বাল্ক নির্বাচনকে সমর্থন করার দিকে বিকৃত হয়ে যায়। আপনি অন্ধভাবে সবকিছু নির্বাচন না করলে খুব বেশি অর্থ হয় না। ব্যবহার এবং প্রাকৃতিক যোগদানের উল্লেখ রয়েছে, যা বেশ বিপজ্জনক এবং এগুলি মোটেও আমার পক্ষে যুক্তির মতো মনে হয় না কারণ তারা কার্যকরভাবে আপনাকে ভূমিকা-ভিত্তিক বিদেশী কী নামকরণ কনভেনশন ব্যবহার করা থেকে বিরত করে।
— রোমান পোলুনিন
53

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

যেমন

কর্মচারী থেকে ই বাম গ্রাহকগণ থেকে e.ID = c.EmployeeID

আমাকে কেবল দুজনেই সংযুক্ত রয়েছে তা বলে না, তবে এটিই পিকে এবং কোনটি এফকে । যদিও পুরানো শৈলীতে আপনি সন্ধান করতে বাধ্য হন বা আশা করা যায় যে তাদের নাম ভাল হয়েছে।

— ইকোস্টর্ম
সূত্র
4
আপনার উদাহরণটি লেখার জন্য আমি জীবনে কখনও একক বিকাশকারীকে চিনি না। পরিবর্তে তারা লিখেছেন: বাম গ্রাহকরা সি এন ই.আইডি = সি.এম্পপ্লয়ইআইডি হিসাবে গ্রাহকগণ এটি পরিষ্কার করে: বামে গ্রাহকরা সি এন হিসাবে । স্পষ্টতই ग्राहक.employeeId একটি বিদেশী কী, যখন কর্মচারী.এম্পপ্লয়ইআইডি নয়।
— ডালিন
8
প্রচুর লোকেরা (যেমন রিপোর্ট লেখকেরা যারা খুব জটিল স্কোএল লিখেন) এবং বিআই বিশেষজ্ঞরা আমদানি এবং রফতানি করে এখনও এসকিউএল হস্তাক্ষর করতে হবে। ডাটাবেস ডিজাইনের এগুলি কেবল অ্যাপ্লিকেশন বিকাশকারীকেই নয় খুব বেশি সংযুক্ত করতে হবে।
— এইচএলজিইএম
30

আমরা ব্যবহার InvoiceID, না ID। এটি কোয়েরিকে আরও পঠনযোগ্য করে তোলে - আপনি যখন IDএকা দেখেন তখন এর অর্থ কিছু হতে পারে, বিশেষত যখন আপনি টেবিলটি টানতেন i।

— জেসন কোহেন
সূত্র
সম্মত হোন এবং আপনি "আইডি" ব্যবহার না করার মূল কারণটি উল্লেখ করেছেন, কারণ আমাদের কাছে সর্বদা টেবিলের নাম যেমন ইনওয়াইজের জন্য "আই", এসকিউএল বা লিনকিউ ইত্যাদিতে "প্রোডাক্ট" এর জন্য p থাকে
— চেউং
4
আইডি ব্যবহার করা আরও উপযুক্ত। কলামটি "চালানগুলি" টেবিলের মধ্যে রয়েছে যাতে যথেষ্ট হওয়া উচিত। আপনি যদি ক্রস টেবিল ক্যোয়ারী লিখছেন তবে আপনার আরও বর্ণনামূলক উপাত্ত ব্যবহার করা উচিত। "আমি" যথেষ্ট নয়। এটিকে "চালান" বলুন।
— tmutton
4
এটি পরিষ্কার নয় যে "আইডি" একার অর্থ ইনভয়েস। মনে করুন আপনি অ্যাকাউন্ট এবং লোকের কাছে বিদেশী কীগুলি পেয়েছেন। এখন কোনটি "আইডি"? যোগদানে কী বলা সহজ নয়, বলুন, a.IvvIDID = b.InvoiceID এর পরিবর্তে a.ID = b.InvoiceID পড়ুন এবং সহজেই এটি ডিবাগ করতে সক্ষম হবেন না।
— জেসন কোহেন
4
পছন্দ করেছেন
— জোশুয়া স্লিচটিং
23

আমি কেভেন এবং আরও কয়েক জন লোকের সাথে এখানে একমত যে কোনও টেবিলের জন্য পিকে কেবল আইডি হওয়া উচিত এবং বিদেশী কীগুলি অন্যান্য টেবিল + আইডির তালিকা করে।

তবে আমি একটি কারণ যুক্ত করতে চাই যা সম্প্রতি এই যুক্তিতে আরও ওজন দিয়েছে।

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

কিছু খাদ্যের জন্য চিন্তা.

— পনরোব
সূত্র
8
জেনেরিক নামকরণ কীভাবে নির্দিষ্ট ক্ষেত্রে কোড পুনরায় ব্যবহারের উন্নতি করে তার বাস্তব বিশ্বের উদাহরণের জন্য +1 (যে লক্ষ লক্ষ .NET ডেভস রয়েছে এবং যেহেতু অনেকে EF ব্যবহার করবেন) যেহেতু প্রচুর বিকাশকারী তাদের যত্ন নেবেন।
— কোডিংআউটলৌড
আমার কর্মক্ষেত্রে কেবল ইএফ এবং এর মতো নয় আমাদের প্রচুর জেনেরিক পদ্ধতি রয়েছে। সুতরাং একটি ওয়েব সার্ভিসে তালিকার << ফলাফল> সংরক্ষণ করুন <টি> (তালিকা <int> আইডি) এর মতো কিছু থাকবে; যেহেতু আমরা জানি যে প্রতিটি টেবিলে একটি আইডি কলাম থাকে যা প্রাথমিক কী হয় আমরা তাদের টেবিলে সি # অবজেক্টের কেবল একটি সাধারণ ম্যাপিং দিয়ে এই জিনিসগুলি করতে পারি (<গ্রাহক, "গ্রাহক">, <বিলিংকোড, "বিলিংকোডস"> ( বা আরও ভাল এখনও সঞ্চিত নামগুলির নাম), পাস করা বস্তুর উপর ভিত্তি করে ফ্লাইতে স্ক্যুয়াল তৈরি করুন এবং ভয়েলা প্রতিটি ধরণের অবজেক্টের জন্য পুনরায় সেভ / ডিলিট / এডিট পদ্ধতিগুলি পুনরুদ্ধার করবেন না
— মাইক
11

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


ইনভয়েসগুলি থেকে i.ID, il.ID নির্বাচন করুন আমি বাম ইনভয়েসলাইনস আইএআইডি = আইএল-এ যোগ দিন n

কেন আমি এটা করতে পারি না?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

আমার মতে এটি খুব পঠনযোগ্য এবং সাধারণ। আই এবং ইল হিসাবে ভেরিয়েবলের নামকরণ সাধারণভাবে একটি দুর্বল পছন্দ।

— bjdodo
সূত্র
10

এটি সত্যিই গুরুত্বপূর্ণ নয়, আপনি সম্ভবত নামকরণের সমস্ত সম্মেলনে সিমালার সমস্যায় পড়তে পারেন।

তবে এটি ধারাবাহিক হওয়া জরুরী তাই প্রতিবার আপনি যখন কোনও ক্যুরি লিখেছেন তখন আপনাকে টেবিলের সংজ্ঞাগুলি দেখতে হবে না।

— নীড়
সূত্র
8

আমি সবেমাত্র এমন একটি জায়গায় কাজ করতে শুরু করেছি যা কেবলমাত্র "আইডি" ব্যবহার করে (মূল টেবিলগুলিতে, বিদেশী কীগুলিতে টেবিলনামআইডি দ্বারা উল্লিখিত), এবং ইতিমধ্যে এটি দ্বারা উত্পন্ন TWO উত্পাদন সমস্যা খুঁজে পেয়েছি।

একটি ক্ষেত্রে ক্যোয়ারী "... যেখানে আইডি ইন (অন্য টেবিল থেকে আইডি নির্বাচন করুন ..." এর পরিবর্তে ... ... যেখানে আইডি রয়েছে (অন্যান্য টেবিলের মধ্য থেকে ট্রানজিড নির্বাচন করুন ... ") query

কেউ কি সত্যই বলতে পারেন যে পূর্ণ, ধারাবাহিক নামগুলি ব্যবহার করা হলে চিহ্নিত করা খুব সহজ হত না যেখানে ভুল বিবৃতিটি "... যেখানে ট্রান্সআইড ইন (অন্যান্য টেবিল থেকে অন্যান্য টেবিল নির্বাচন করুন ..."? আমি মনে করি না তাই

কোডটি রিফ্যাকচার করার সময় অন্য সমস্যাটি ঘটে। আপনি যদি কোনও টেম্প টেবিল ব্যবহার করেন তবে পূর্বে কোয়েরিটি একটি মূল টেবিলের বাইরে চলে যায় তবে পুরানো কোডটি "... dbo.MyFunction (t.ID) ..." পড়ে এবং যদি এটি পরিবর্তন না করা হয় তবে "টি" এখন একটি উল্লেখ করে মূল টেবিলের পরিবর্তে টেম্প টেবিল, আপনি একটি ত্রুটিও পান না - কেবল ভুল ফলাফল।

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

— এরিক কাসান
সূত্র
4
+1 আরও নির্দিষ্ট নামের রক্ষণাবেক্ষণযোগ্যতার উন্নতি করার বাস্তব বিশ্বের উদাহরণের জন্য।
— কোডিংআউটলৌড
6

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

— মাইকেল ব্রাউন
সূত্র
6

আমি ব্যক্তিগতভাবে পছন্দ করা (যেমন উপরে বর্ণিত হয়েছে) Table.ID জন্য পি কে এবং TableID জন্য এফ কে । এমনকি (দয়া করে আমাকে গুলি করবেন না) মাইক্রোসফ্ট অ্যাক্সেস এটির প্রস্তাব দেয়।

যাইহোক, আমি এও জানি যে কিছু উত্পাদক সরঞ্জাম পিকে জন্য টেবিলআইডি সমর্থন করে কারণ তারা সমস্ত কলামের নাম যুক্ত করে যা "আইডি" শব্দের সাথে আইডি অন্তর্ভুক্ত করে !!!

এমনকি কোয়েরি ডিজাইনার মাইক্রোসফ্ট এসকিউএল সার্ভারে এটি করেন (এবং আপনার তৈরি প্রতিটি প্রশ্নের জন্য, আপনি কলাম আইডির সমস্ত টেবিলগুলিতে সমস্ত অপ্রয়োজনীয় সদ্য নির্মিত সম্পর্কগুলি ছুঁড়ে ফেলবেন)

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

এটি বলার অপেক্ষা রাখে না যে লোকেরা যখন টেবিলনাম, সারণী বিবরণ এবং এই জাতীয় ব্যবহার শুরু করে আমি আমার লাইন আঁকি। আমার মতে, সম্মেলনগুলি নিম্নলিখিতগুলি করা উচিত:

  • সারণীর নাম: বহুবচন। প্রাক্তন কর্মচারী

  • সারণী ওরফে: পুরো টেবিলের নাম, একবাক্যরণী। প্রাক্তন

    SELECT Employee.*, eMail.Address
FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[হালনাগাদ]

এছাড়াও, "থ্রেড সম্পর্কের ধরণ" বা ভূমিকার কারণে নকল কলামগুলি সম্পর্কে এই থ্রেডে কিছু বৈধ পোস্ট রয়েছে। উদাহরণস্বরূপ, যদি কোনও স্টোরের কোনও কর্মচারী থাকে তবে তা আমাকে স্কোয়াট বলে। তাই আমি মাঝে মাঝে স্টোর.এম্পলয়েআইডি_ম্যানেজারের মতো কিছু করি । নিশ্চিত যে এটি কিছুটা বড় তবে লিজগুলিতে লোকেরা টেবিল ম্যানেজার আইডি , বা সেখানে কর্মচারী কী করছে তা সন্ধান করার জন্য পাগল হবে না । যখন জিজ্ঞাসাবাদ যেখানে হয় আমি এটিকে আরও সরলীকৃত করব: কর্মচারীআইডি_ম্যানেজারকে পরিচালক হিসাবে FROM স্টোর হিসাবে নির্বাচন করুন

— পার্সবাস
সূত্র
আমি মনে করি আপনার পয়েন্টটি ডাটাবেসের সৌন্দর্যের জন্য এবং ডায়ডিকের উদ্দেশ্যে ভাল তবে কার্যকারিতার জন্য আমি মনে করি এটি একটি সমস্যা। বহু টেবিলের নাম টেবিল এবং পিকে আইডির মধ্যে অসঙ্গতি উত্সাহিত করে <-> এফকে আইডিটিবেল একই জিনিসটির নামে দ্বিধা তৈরি করে। একই সময়ে, User.UserIdপ্রোগ্রামিং টাইপ করা কিন্ডা অদ্ভুত কিছু ।
— মাচাডো
4

একটি আনুষ্ঠানিক তথ্য অভিধানের দৃষ্টিকোণ থেকে এটি আসা, আমি তথ্য উপাদান নাম হবে invoice_ID। সাধারণত, ডেটা অভিধানে কোনও ডাটা উপাদানটির নাম অনন্য হয়ে যায় এবং আদর্শভাবে এটি একই নাম জুড়ে থাকতে পারে, যদিও কখনও কখনও প্রসঙ্গের ভিত্তিতে অতিরিক্ত যোগ্যতার শর্তাদি প্রয়োজন হতে পারে যেমন নামকৃত ডেটা উপাদানটি employee_IDচার্টে দুবার ব্যবহার করা যেতে পারে এবং তাই যোগ্য হিসাবে যোগ্য supervisor_employee_IDএবং subordinate_employee_IDযথাক্রমে

স্পষ্টতই, নামকরণের সম্মেলনগুলি বিষয়গত এবং শৈলীর বিষয়। আমি আইএসও / আইইসি 11179 নির্দেশিকা একটি দরকারী সূচনা পয়েন্ট হতে খুঁজে পেয়েছি।

ডিবিএমএসের জন্য, আমি টেবিলগুলি এন্টিগুলির সংগ্রহ হিসাবে দেখি (কেবলমাত্র একটি সারি যেমন কোফিগ টেবিল, ধ্রুবকগুলির টেবিল ইত্যাদি) যেমন টেবিলটি যেখানে আমার employee_IDচাবিটি নামকরণ করা হবে Personnel। তাই সরাসরিTableNameID কনভেনশনটি আমার পক্ষে কাজ করে না।

আমি TableName.ID=PK TableNameID=FKবড় ডেটা মডেলগুলিতে ব্যবহৃত শৈলীটি দেখেছি এবং বলতে হবে যে আমি এটি কিছুটা বিভ্রান্তিকর বলে মনে করি: আমি কোনও পরিচয়কারীর নাম জুড়েই বেশি পছন্দ করি which অর্থ কোন টেবিলে প্রদর্শিত হবে তার ভিত্তিতে নাম পরিবর্তন করি না note লক্ষ্য করার মতো কিছু হ'ল উপরোক্ত স্টাইলটি এমন দোকানে ব্যবহৃত হতে পারে যা বিদেশী কীগুলিতে প্রাকৃতিক এবং যৌগিক কীগুলি বাদ IDENTITYদিয়ে প্রতিটি টেবিলে একটি (অটো-ইনক্রিমেন্ট) কলাম যুক্ত করে । এই দোকানগুলিতে আনুষ্ঠানিক ডেটা ডিকশনারি না থাকে বা ডেটা মডেলগুলি তৈরি করে না। আবার, এটি নিছক শৈলীর প্রশ্ন এবং এটিতে আমি ব্যক্তিগতভাবে সাবস্ক্রাইব করি না। সুতরাং শেষ পর্যন্ত, এটি আমার পক্ষে নয়।

যা কিছু বলেছে, আমি কখনও কখনও কলামের নাম থেকে কোয়ালিফায়ারকে বাদ দেওয়ার ক্ষেত্রে একটি মামলা দেখতে পাই যখন টেবিলের নামটি এমন করার জন্য একটি প্রসঙ্গ সরবরাহ করে যেমন নামকরণ উপাদানটি employee_last_nameকেবল টেবিলের last_nameমধ্যে থাকতে পারে Personnel। যুক্তিপূর্ণ এখানে DOMAIN 'জনগণের শেষ নাম' এবং সম্ভাবনা বেশি করা হয় UNIONসঙ্গে ed last_nameকলাম থেকে বদলে একটি বিদেশী কী হিসাবে ব্যবহার করা যেতে অন্য টেবিল মধ্যে , আবার অন্য টেবিল, কিন্তু তারপর ... আমি শুধু আমার মন পরিবর্তন করতে পারে কখনও কখনও আপনি বলতে পারেন না। এটি হ'ল ডেটা মডেলিং হ'ল পার্ট আর্ট, পার্ট সায়েন্স।

— onedaywhen
সূত্র
2

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

প্রথম বক্তব্যটির দ্বারা আমি যা বোঝাতে চাইছি তা হল আইডির পরিবর্তে আপনি 'রিকনো' এর মতো অন্য কিছু ব্যবহার করতে পারেন। সুতরাং এই টেবিলের চালান_আরকনো এবং এর মতো একটি পিকে থাকবে।

চিয়ার্স, বেন

2

আমার ভোটটি টেবিল আইডির জন্য চালানের জন্য। যখন আমি বিদেশী কী হিসাবে ব্যবহার করি এবং অনুসন্ধানগুলিতে বুদ্ধিমান ওরফে নাম ব্যবহার করি তখনও আমি একই নামকরণ কনভেনশনটি ব্যবহার করি।

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

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

— রব অ্যালেন
সূত্র
1

ডাটাবেসে কলামের নামের জন্য, আমি "ইনভয়েসিআইডি" ব্যবহার করব।

আমি যদি লিনকিউ-এর মাধ্যমে কোনও নামহীন স্ট্রাক্টগুলিতে ক্ষেত্রগুলি অনুলিপি করি তবে কাঠামোর একমাত্র আইডি হলে আমি সেখানে এটি "আইডি" রাখতে পারি।

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

— জেমস কারান
সূত্র
1

যদি আপনি প্রতিটি কীকে একটি অনন্য নাম দেন, যেমন "invoice.vv_id" এর পরিবর্তে "invoice.invoice_id", আপনি কোনও উদ্বেগ ছাড়াই "প্রাকৃতিক যোগদান" এবং "অপারেটর" ব্যবহার করতে পারেন। যেমন

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

পরিবর্তে

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

এসকিউএল আরও ভার্বোস না করে যথেষ্ট ভার্বোজ।

— স্টিভেন হুইগ
সূত্র
আপনি কি জানেন যে এসকিউএল সার্ভার প্রাকৃতিক যোগদানকে সমর্থন করে?
— Arry
আমি মনে করি না যে এটি করে। কানেক্ট.মাইক্রোসফট / এসকিউএল সার্ভার / ফেডব্যাক / এর মতে এটি উপস্থিত হয় যে এসকিউএল সার্ভার ২০০৫-এর পরে সিন্ট্যাক্সটি কিছু সংস্করণে যুক্ত করা হবে I আমি জানি এটি পোস্টগ্র্রেএসকিউএল এবং ওরাকলে কাজ করে।
— স্টিভেন হুইগ
7
কখনই না, কখনও কখনও প্রাকৃতিক যোগদান করবেন না। কোয়েরিটি লেখার সময় যদি কোনও টেবিলে বিবরণ ক্ষেত্র থাকে তবে আপনি ভাল আছেন। যদি পরে, অন্য টেবিলে কেউ বর্ণনার ক্ষেত্র যোগ করে, আপনি তাতে যোগ দিতে শুরু করবেন এবং পুরোপুরি বিরতি দিন।
4
হেই, বাস্তব জীবনের অভিজ্ঞতার শোনার মতো শোনাচ্ছে :)
— ড্যান্ট
আমি শুধুমাত্র অ্যাডহক প্রশ্নের জন্য প্রাকৃতিক যোগদান ব্যবহার করব।
— স্টিভেন হুইগ
1

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

আমার কাছে এটি বিশেষত যোগ দেওয়ার জন্য অর্থবোধ করে যেখানে আমি মনে করি এটি আরও সহজ পড়া যায়।

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk
— আয়ান অ্যান্ড্রুজ
সূত্র
1

এফডব্লিউআইডাব্লু, আমাদের নতুন স্ট্যান্ডার্ড (যা পরিবর্তিত হয়, আহ, মানে প্রতিটি নতুন প্রকল্পের সাথে "বিবর্তিত") হ'ল:

  • লোয়ার কেস ডাটাবেস ক্ষেত্রের নাম
  • বড় হাতের টেবিলের নাম
  • ক্ষেত্রের নামগুলিতে শব্দগুলি পৃথক করতে আন্ডারস্কোরগুলি ব্যবহার করুন - এগুলিকে কোডে পাস্কাল কেসে রূপান্তর করুন।
  • pk_ উপসর্গটির অর্থ প্রাথমিক কী
  • _id প্রত্যয় অর্থ একটি পূর্ণসংখ্যা, স্বতঃবৃদ্ধি আইডি
  • fk_ উপসর্গটির অর্থ বিদেশী কী (প্রত্যয় প্রয়োজন নেই)
  • _VW দেখার জন্য প্রত্যয়
  • is_ বুলিয়ানদের উপসর্গ

সুতরাং, একটি টেবিল নামে NAMES এর ক্ষেত্র থাকতে পারে pk_name_id, first_name, last_name, is_alive,এবং fk_companyএবং একটি দৃশ্য নামক LIVING_CUSTOMERS_VWমত সংজ্ঞা দিয়েছে:

প্রথম নাম, শেষের নাম নির্বাচন করুন
যোগাযোগ থেকে
যেখানে (is_alive = 'সত্য')

অন্যরা যেমন বলেছে, যদিও কোনও স্কিম যতক্ষণ এটি সামঞ্জস্যপূর্ণ এবং অযথা আপনার অর্থগুলি অবিরাম করে না ততক্ষণ কাজ করবে।

— সিএমপালমার
সূত্র
0

আইডি ক্ষেত্রের নামটিতে টেবিলের নাম অন্তর্ভুক্ত করার সাথে আমি অবশ্যই একমত হয়েছি কারণ আপনি যে কারণে দিয়েছেন। সাধারণত, এটি একমাত্র ক্ষেত্র যেখানে আমি টেবিলের নাম অন্তর্ভুক্ত করব।

— ডোক
সূত্র
0

আমি প্লেইন আইডি নাম ঘৃণা করি। আমি সর্বদা চালান_আইড বা এর কোনও বৈকল্পিক ব্যবহার করতে পছন্দ করি। আমি যখনি প্রয়োজন হয় তখন আমি সর্বদা জানি যে টেবিলটি আইডিটির জন্য অনুমোদিত টেবিল, তবে এটি আমাকে বিভ্রান্ত করে

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID

সবচেয়ে খারাপটি হ'ল আপনি যে মিশ্রণটি উল্লেখ করেছেন তা সম্পূর্ণ বিভ্রান্তিকর। আমাকে এমন একটি ডাটাবেস নিয়ে কাজ করতে হয়েছিল যেখানে সর্বাধিক ব্যবহৃত আইডির বাইরে প্রায় সর্বদা এটি foo_id ছিল। এটা ছিল সম্পূর্ণ নরক।

— ভিঙ্কো ভার্সালোভিক
সূত্র
4
আমি এই পোস্টে "চালান" শব্দটি অনেক বার পড়েছি। এটি এখন মজার দেখাচ্ছে
— কেভিন
4
উহ, অন্তর্ভুক্ত! আমি আমার চোখের পাতাটি ছিঁড়ে ফেলতে চাই।
— এইচএলজিইএম
0

আমি ডোমেননাম পছন্দ করি || 'আইডি'। (যেমন ডোমেননাম + আইডি)

ডোমেননাম প্রায়শই, তবে সর্বদা নয়, টেবিলনামের মতো।

নিজেই আইডি নিয়ে সমস্যা হ'ল এটি উপরের দিকে স্কেল করে না। একবার আপনার প্রায় 200 টি টেবিল থাকে, প্রতিটি আইডি নামের প্রথম কলামের সাথে প্রতিটি ডেটা সমস্ত একসাথে দেখতে শুরু করে। আপনি যদি সর্বদা টেবিলের নামের সাথে আইডি যোগ্যতা অর্জন করেন তবে এটি কিছুটা সহায়তা করে, তবে তেমন কিছু নয়।

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

মাঝে মাঝে ডোমেন নাম || 'আইডি' ব্যবহার করা যাবে না, কারণ একই টেবিলে একই নামের সাথে দুটি কলাম থাকবে। উদাহরণ: কর্মচারী E এমপ্লয়েইআইডি এবং কর্মচারী upসপভাইজারআইডি। এই ক্ষেত্রে আমি রোলনাম ব্যবহার করি || উদাহরণ হিসাবে যেমন 'আইডি'।

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

— ওয়াল্টার মিট্টি
সূত্র
0

প্রতিটি টেবিলের জন্য আমি একটি ট্রি লেটার শর্টহ্যান্ড বেছে নিই (যেমন কর্মচারী => এমপি)

এইভাবে একটি সংখ্যার স্বায়ত্তশাসিত প্রাথমিক কীটি এনকেইম্প হয়ে যায় ।

এটি সম্পূর্ণ ডাটাবেসে সংক্ষিপ্ত, অনন্য এবং আমি এক নজরে এর বৈশিষ্ট্যগুলি ঠিক জানি।

আমি এসকিউএল এবং আমি যে সমস্ত ভাষা ব্যবহার করি সেগুলিতে একই নাম রাখি (বেশিরভাগ সি #, জাভাস্ক্রিপ্ট, ভিবি 6)।

— pkario
সূত্র
0

নামকরণ সারণী এবং কলামগুলির সুচিন্তিত সিস্টেমের জন্য ইন্ট্রাক্ট সাইটের নামকরণ কনভেনশনগুলি দেখুন । পদ্ধতিটি প্রতিটি টেবিলের জন্য একটি প্রত্যয় ব্যবহার করে ( _prdপণ্য সারণির জন্য, বা _ctgবিভাগের টেবিলের জন্য) এবং প্রদত্ত টেবিলের প্রতিটি কলামে এটি যুক্ত করে। সুতরাং পণ্যগুলির সারণির জন্য পরিচয় কলামটি id_prdতাই ডাটাবেসে অনন্য।

তারা বিদেশী কীগুলি বোঝার জন্য আরও এক ধাপ এগিয়ে যায়: বিভাগের সারণিকে বোঝায় পণ্য সারণীতে বিদেশী কী এমন হবে idctg_prdযাতে এটি কোন টেবিলের ( _prdপ্রত্যয়) এবং এটি কোন টেবিলের সাথে বোঝায় (বিভাগ) ।

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

— জ্বলন্ত লোকস
সূত্র
-2

আপনি নিম্নলিখিত নামকরণ কনভেনশন ব্যবহার করতে পারেন। এটির ত্রুটি রয়েছে তবে এটি আপনার বিশেষ সমস্যাগুলি সমাধান করে।

  1. সারণির নামগুলির জন্য সংক্ষিপ্ত (3-4 অক্ষর) ডাকনাম ব্যবহার করুন, যেমন চালান - inv, ইনভয়েসলাইনস -invl
  2. এই ডাকনাম ব্যবহার করে টেবিলের কলামগুলির নাম দিন, যেমন inv_id ,invl_id
  3. রেফারেন্স কলামগুলির invl_inv_idজন্য নামের জন্য ব্যবহার করুন।

এইভাবে আপনি বলতে পারেন

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id
— ইলিয়া কোচেতোভ
সূত্র
4
আইক! আমি টেবিলের জন্য সংক্ষিপ্ত ডাকনাম ব্যবহার করার বিরুদ্ধে (বা অন্য কোনও বিষয়) বিরুদ্ধে ভোট দেব। ডাকনাম সহ, আপনি কখনই সংক্ষিপ্ত নামটি ঠিক বুঝতে পারবেন না। মনে রাখবেন, ভুল বানান করার অনেকগুলি উপায় রয়েছে; এটি সঠিকভাবে বানান করার একমাত্র উপায় আছে।
— জেমস কারান 13
4
জেমস, আমি একমত নই। যদি আপনার একটি সংক্ষিপ্ত নাম বর্ণনামূলক নয় এবং আপনি এটি কী তা মনে করতে না পারেন তবে আপনি ভুল নামটি বেছে নিয়েছেন বা অন্য কেউ যে নামকরণের সম্মেলনটি বেছে নিয়েছেন তা বুঝতে পারছেন না।
— কেমিলার2002
4
একই প্রভাব অর্জনের জন্য এলিয়াস ব্যবহার করুন। ইনভয়েস আমন্ত্রণ বাম থেকে * চয়ন করুন inv.ID = invl.InvoiceID
— yfeldblum 16:58
4
না না না না. প্রশ্নের সন্ধানে একটি ছদ্মবেশ সহ টেবিলের নাম দিন। তবে টেবিলের নামটি পূর্ণ হওয়া উচিত।
— জাল করুন
4
কেন এত বেশি প্রোগ্রামার অলস এবং মনে হয় যে সমস্ত কিছুর উত্তর হ'ল কমপক্ষে সম্ভব টাইপ করা কারণ এটি খুব বেশি শক্ত টাইপ করা খুব শক্ত।
— এমপি।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.