প্রাথমিক কী / বিদেশী কী নামকরণ সম্মেলন [বন্ধ]


97

আমাদের দেব গোষ্ঠীতে প্রাথমিক এবং বিদেশী কীগুলির নামকরণ কনভেনশন সম্পর্কিত আমাদের তীব্র বিতর্ক রয়েছে। আমাদের গ্রুপে মূলত দুটি বিদ্যালয় রয়েছে:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

বা

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

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

কিছু অন্য বিকল্প 2 পছন্দ করে যেখানে আপনি প্রাথমিক কীটির নাম টেবিলের নামের সাথে উপরিযুক্ত করে রেখেছেন যাতে কলামের নামটি ডাটাবেস জুড়ে একই থাকে। আমি সেই পয়েন্টটি দেখতে পাচ্ছি, তবে আপনি এখন কোনও বিদেশী কী থেকে প্রাথমিক কীটি দৃশ্যত পৃথক করতে পারবেন না।

এছাড়াও, আমি মনে করি এটি কলামের নাম অনুসারে টেবিলের নাম রাখা অপ্রয়োজনীয় কারণ আপনি যদি সারণিকে সত্তা হিসাবে এবং কোনও কলামটিকে সেই সত্তার সম্পত্তি বা বৈশিষ্ট্য হিসাবে মনে করেন তবে আপনি এটির আইডি বৈশিষ্ট্য হিসাবে ভাবেন Employee, না EmployeeIDএকজন কর্মী এর অ্যাট্রিবিউট। আমি যেতে না একটি আমার সহকর্মীকে তার জিজ্ঞাসা PersonAgeবা PersonGenderহয়। আমি তাকে জিজ্ঞাসা করি তার বয়স কী।

সুতরাং আমি যেমন বলেছিলাম, এটি একটি তীব্র বিতর্ক এবং আমরা এটি নিয়ে আরও এগিয়ে চলেছি। আমি কিছু নতুন দৃষ্টিভঙ্গি পেতে আগ্রহী।



4
আমি 10 টিরও বেশি অনুরূপ প্রশ্ন পড়েছি এবং অবশেষে এখানে শীর্ষ 3 উত্তরগুলি ভাল পেয়েছি: stackoverflow.com/a/465146/781695
ব্যবহারকারী

কেবলমাত্র একটি পার্শ্ব নোট: পছন্দ 2 আপনাকে 'প্রাকৃতিক যোগদান' করতে দেয়। হেক, এখনও 'কর্মচারী.আইডি হিসাবে কর্মচারী.আইডি' যোগ করে পছন্দ 1 এ এটি করবেন না। তবে অনুশীলনের আরও ভাল উপায় 'ওয়ান এমপ্লয়ি.আইডি = ইভেন্ট.EmployeeID' ব্যবহার করে 'যোগদান' বলে মনে হচ্ছে।
লিও

উভয় পরিস্থিতিতেই আপনি এক বা একাধিক কুইরে উপনাম (বা 'টেবিল_নাম.কমলন_নাম') ব্যবহার করবেন কারণ আপনি উভয় ক্ষেত্রেই কলামের নাম পুনরাবৃত্তি করছেন।
করে_ডন্ট_বুলি_মে_স_এলর্ডস

উত্তর:


52

এটা আসলে কোন ব্যাপার না। আমি কখনও এমন কোনও সিস্টেমে চলে যাইনি যেখানে পছন্দ ১ এবং পছন্দ ২ এর মধ্যে সত্যিকারের পার্থক্য রয়েছে।

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

একটি চয়ন করুন এবং তাদের প্রকৃতপক্ষে আপনার কোডকে প্রভাবিত করে এমন বিষয়ে ফোকাস করতে তাদের বলুন tell

সম্পাদনা: আপনি মজা করতে চাইলে, পুনরাবৃত্তিযোগ্য সারণী রেফারেন্সগুলির জন্য কেন তাদের পদ্ধতিটি সর্বোত্তম length তাদের দৈর্ঘ্যে নির্দিষ্ট করুন।


28
+1, সাধারণ জ্ঞানের জন্য ... আরও অনেক গুরুত্বপূর্ণ বিষয় নিয়ে তর্ক করার দরকার আছে .. সুতরাং, এটি আমার উপায়ে করুন (পছন্দ 2)
চার্লস বেতানা

4
এবং, আত্ম-রেফারেন্সিং ডিআরআই-এর জন্য, যখন একই পিকে একাধিক এফকে রেফারেন্স পাওয়া যায়, তখন আপনাকে দুটি "স্ট্যান্ডার্ড" লঙ্ঘন করতে হবে, যেহেতু দুটি এফকে কলাম একই নামকরণ করা যায় না ... যেমন, এমপ্লয়টেবল EmployeeId পি কে, SupervisorId এফ কে, MentorId FK, PartnerId এফ কে, ইত্যাদি ইত্যাদি ... সঙ্গে
চার্লস Bretana

76

যদি দুটি কলামে উভয় সারণীতে একই নাম থাকে (কনভেনশন # 2), আপনি এসকিউএল-তে ইউএসিং সিনট্যাক্সটি কিছু টাইপিং এবং কিছু বয়লারপ্লেট শব্দটি সংরক্ষণ করতে ব্যবহার করতে পারেন:

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

কনভেনশন # 2 এর পক্ষে আর একটি যুক্তি হ'ল এটি যেভাবে সম্পর্কিত মডেলটি তৈরি হয়েছিল।

প্রতিটি কলামের তাত্পর্যটি সংশ্লিষ্ট ডোমেনটির নামের সাথে লেবেল করে আংশিকভাবে জানানো হয়।


4
এসকিউএল সিনট্যাক্স এবং শব্দার্থবিজ্ঞানগুলি কীভাবে এটি ব্যবহার করা উচিত সে সম্পর্কে একটি দুর্দান্ত ভাল ধারণা দেয়। উদাহরণস্বরূপ সিনট্যাক্স ব্যবহারের অর্থ একই ডোমেনের কলামগুলির একই নাম হওয়া উচিত, NULL = NULL -> NULL এর অর্থ NUL "প্রযোজ্য নয়" এর পরিবর্তে "অজানা", এবং আপডেট ক্যাসকেডের অর্থ কীগুলি কেবল অনন্য হতে হবে, অপরিবর্তনীয় নয়।
স্টিভেন হুইগ

6
ভাল এমনকি, এটা এই অনুমতি দেয়: SELECT name, address, amount FROM employees NATURAL JOIN payroll
onedaywhen

4
আমি মোতায়েন কোডে প্রাকৃতিক যোগদান ব্যবহার করব না, কারণ এটি স্কিমা সংযোজন ক্ষেত্রে ভঙ্গুর। ইন্টারেক্টিভ অনুসন্ধানের জন্য, এটি দুর্দান্ত।
স্টিভেন হুইগ

4
+1 তবে সর্বদা একটি ব্যতিক্রম আছে। উদাহরণস্বরূপ, যদি বেতনপত্রে আপনার দুটি কলাম থাকে যা উভয়ই কর্মীর বিদেশী কী (যেমন একজন ব্যক্তির অর্থ প্রদান করা হচ্ছে, দ্বিতীয়টি বাজেট কর্তৃপক্ষ সহ পরিচালকের কাছে রয়েছে)। তবে আমরা উভয় বিদেশী কী নামকরণ করতে পারি না employee_id
বিল কারভিন

4
"ব্যবহার" কীওয়ার্ডটি মাইএসকিউএল নির্দিষ্ট specific দুর্ভাগ্যক্রমে টি-এসকিউএল এ কাজ করে না।
পাখি

12

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

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


4
মিলে যায় না এমন কলামের নামগুলির সাথে যোগ দেওয়ার জন্য +1
রাজ মোর

4
"পুরানো সিস্টেমে" 8 অক্ষরের দীর্ঘ নামের প্রতিবন্ধকতা যা এর চেয়ে অনেক বেশি ব্যথা করে। আমি কোনও অঙ্গ নিয়ে বেরিয়ে আসতে চাই এবং অনুমান করতে পারি যে আপনি যে পুরনো সিস্টেমে व्यवहार করছেন তার মধ্যে পিকে নামকরণ করা আইডি রাখা দুঃস্বপ্নের প্রাথমিক কারণ নয়। এছাড়াও "এটি পুরানো সিস্টেমে স্তন্যপান করা হয়েছে" সফটওয়্যার বিকাশে বিশেষত ডাটাবেসগুলিতে প্রায়শই ওয়াহাএ ব্যবহৃত হয়। আমি নিয়মিত লোককে যে কোনও অনুশীলনকে ন্যায্যতা দেখছি, এটি 10+ বছর আগে প্রকাশিত ডিবি সিস্টেমে যেভাবে তাদের অভিজ্ঞতায় কাজ করেছে তার উপর ভিত্তি করে।
রাসেল স্টেইন

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

4
সুতরাং 20 বছর আগে লোকেরা যে কোনওভাবে কলামের নাম ব্যবহার করা উচিত যা আজকে উপলব্ধি করেছে, যদিও তাদের কেবল 8 টি অক্ষর ছিল? বিগত 20 বছরে ডেটা স্টোরেজ ফর্ম্যাটগুলি মারাত্মকভাবে পরিবর্তিত হয়েছে এবং পরবর্তী 20 সালে আবার পরিবর্তন হবে demonst আপনার পছন্দকে তালিকাভুক্ত অন্যান্য পদ্ধতির চেয়ে সময়ের পরীক্ষার পক্ষে দাঁড় করানোর কোনও উপায় নেই। 20 বছরে লোকেরা যখন এই আলোচনার সময় কাটাচ্ছে তখন "কলামের নামগুলি" তারা নিজেরাই "পুরানো বাজে" হতে পারে, যেহেতু ডেটা সংরক্ষণ এবং পরিচালনা করার আমাদের দক্ষতার উন্নতি হয়। টেবিলগুলি এমন একটি মানব নির্মাণ যা অসম্পূর্ণভাবে ডেটা সম্পর্কের প্রতিনিধিত্ব করে ...
রাসেল স্টেইন

4
সঠিক যুক্তিযুক্ত বৌদ্ধিক প্রতিক্রিয়ার জন্য আপনাকে ধন্যবাদ।
রাসেল স্টেন

3

উভয়ই কনভেনশন সব ক্ষেত্রেই কাজ করে না, তবে কেন একটি আদৌ আছে? সাধারণ বুদ্ধি ব্যবহার কর...

উদাহরণস্বরূপ, স্ব-রেফারেন্সিং টেবিলের জন্য, যখন একাধিক এফকে কলাম থাকে যখন একই টেবিলের পিকে স্ব-উল্লেখ করা হয়, আপনি দুটি "স্ট্যান্ডার্ড" লঙ্ঘন করতে পারেন, যেহেতু দুটি এফকে কলাম একই নামকরণ করা যায় না ... উদাহরণস্বরূপ , কর্মচারী আইডির সাথে কর্মচারী পিকে, সুপারভাইজার আইডি এফ কে, মেন্টোরআইডি এফ, পার্টনার আইড এফ,, ...


4
প্রকৃত প্রযুক্তিগত উদ্দেশ্য উত্তরের জন্য +1
ডিভি কে

একটি ভাল, প্রযোজ্য উত্তর, তবে ডেমসের উত্তরের যুক্তিগুলি বিন্দুটি মিস করে।
জেল্টন

3

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

লোকেরা যদি 'নিজস্ব কাজ করা' শুরু করে তবে তাদের জাল দ্বারা তাদের শক্তিশালী করা উচিত। আইএমএইচও :)


4
ধারাবাহিকতা "সঠিক" হওয়ার চেয়ে গুরুত্বপূর্ণ (এই ক্ষেত্রে) হওয়ার জন্য +1
রাসেল স্টেইন

"বোকা ধারাবাহিকতা" প্রয়োগ করার চেষ্টা করার জন্য -1। পুরাতন চীনা প্রবাদটি বলেছে "" বোকা ধারাবাহিকতা হ'ল সহজ মনের জন্য একটি হাবগোব্লিন "
চার্লস ব্রেটানা

@ চারেলস: এমন এক পৃথিবীতে যেখানে বিভিন্ন লোক একে অপরের কোড বজায় রাখে, প্রায়শই যখন লেখক চলে যায় এবং ডকুমেন্টেশনটি অপ্রচলিত বা অ-অস্তিত্বহীন থাকে, এটি বোকা ধারাবাহিকতা নয়। আমি তোমার সাথে কাজ করি না বলে আমি খুব আনন্দিত ...
ম্যাটবাইলি

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

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

3

আপনি কি নিম্নলিখিত বিবেচনা করেছেন?

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

4
জনগণ ভোট দিলে আমি দাঁড়াতে পারি না এবং কারণ কেন রাখি না। এটি একটি সম্পূর্ণ বৈধ উত্তর, এটি কারওর জন্য স্পষ্টকর বা না তা ভিন্ন প্রশ্ন, তবে এটি বিষয়গত এবং কোনও ভোট ভোটের প্রয়োজন হয় না।
জেরেমি

4
এই বিষয়টি চিহ্নিত করার জন্য ধন্যবাদ. আপনি কেন এই ফর্ম্যাটটি ব্যবহার করবেন না সেই কারণগুলিতে আমি আগ্রহী । এবং আমি নিশ্চিত যে এর ভাল কারণগুলি থাকবে ...
ওয়াউটার

এটাই সবচেয়ে ভাল উপায়, কারণ আপনাকে table_name.column_nameবারবার নামগুলি না থাকলে আপনার কোনও ক্যোয়ারী ব্যবহার করতে হবে না এবং কলামের নামগুলির জন্য উপনাম ব্যবহার করতে হবে না ...
করে_ডন্ট_বুলি_মে_স_লর্ডস

4
এটি হাঙ্গেরিয়ান স্বরলিপি একটি রূপ বিবেচনা করা যেতে পারে। সুতরাং পক্ষে এবং এর বিরুদ্ধে যুক্তি বিবেচনা করুন।
ফ্রেড

2

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


আমি সিদ্ধান্ত নিয়েছি না যে আমি বহুবচনযুক্ত টেবিলের নাম পছন্দ করি। একক ব্যবহার করে কোয়েরিগুলি আরও ভাল পড়তে পারে বলে মনে হয় ("কর্মচারী.নাম" এর বিপরীতে "কর্মচারী.নাম")। এমনকি আপনি যুক্ত হয়ে অন্য টেবিলে একক রেকর্ড যোগ দিচ্ছেন বলে মনে হয় এটি আরও ভাল পড়তে পারে। তবে বহুত্বযুক্ত টেবিলের নামগুলি কোয়েরির চেয়ে টেবিলটি নিয়ে চিন্তা করার সময় আরও সঠিক মনে হয়। আমি যা ব্যবহার করি তা হিসাবে আমি একবচন দিয়ে আটকে যাব, তবে আমি মনে করি এটি যাওয়ার সঠিক
উপায়ও

হ্যাঁ আমার ধারণা, এটি ব্যক্তিগত পছন্দ এবং / বা আপনি যা ব্যবহার করতে অভ্যস্ত তা বেশি।
জ্যারেট মিল্লার্ড

2

আপনি যদি কেবল ডাটাবেস অনুসন্ধানগুলি না করে অ্যাপ্লিকেশন কোডটি দেখছেন তবে কিছু জিনিস আমার কাছে স্পষ্ট বলে মনে হচ্ছে:

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

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


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

2

আমি কনভেনশন # 2 পছন্দ করি - এই বিষয়টি অনুসন্ধানে, এবং নিজের পোস্ট করার আগে এই প্রশ্নটি সন্ধান করার পরে আমি এই সমস্যাটিতে চলে এসেছি যেখানে:

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

SELECT table1.id AS parent_id, table2.id AS child_id

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


4
SELECT *যাইহোক, (বেশিরভাগ) উত্পাদন প্রশ্নাবলীর জন্য নো-হ'ল, সুতরাং এটি নামকরণের মান বাছাই করার কোনও কারণ নয়।
পি ড্যাডি

4
দ্বিমত পোষণ করছেন না: আপনি কেন কোনও কারণের জন্য একটি লিঙ্ক সরবরাহ করতে পারেন? আমার ক্যোয়ারিতে 80 টি কলামের নাম বজায় রাখার ধারণাটি আমি পছন্দ করি না।
জেলটন 20

এই মুহুর্তে কোনও লিঙ্ক খুঁজে পাওয়া যায় না ("*" এর জন্য গুগল করা কঠিন) তবে আমি মূল বিষয়গুলি উল্লেখ করব: (1) সারণিতে পরিবর্তনগুলি আপনার অ্যাপ্লিকেশনটিকে নেতিবাচকভাবে প্রভাবিত করতে পারে, (২) এটি হতে পারে পারফরম্যান্সের জন্য খারাপ এবং (3) আপনার আসলে কী ডেটা দরকার তা স্পষ্টভাবে উল্লেখ করা আপনার কোডটি বুঝতে সহজ করে তুলবে। এই পয়েন্টগুলি প্রসারিত হতে পারে এবং এর ব্যতিক্রমগুলি রয়েছে (যেমন আমি ইঙ্গিত করেছি) তবে এটি এখানে উপযুক্ত নয়। আপনি যদি এটি একটি নতুন প্রশ্ন হিসাবে পোস্ট করেন তবে আমি (এবং অন্যরা) আরও বিশদভাবে জানাতে পেরে খুশি হব।
পি ড্যাডি

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

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

2

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


1

আমি কনভেনশন # 2 ব্যবহার করি। আমি এখন একটি লিগ্যাসি ডেটা মডেল নিয়ে কাজ করছি যেখানে আমি জানিনা যে প্রদত্ত টেবিলে কী দাঁড়ায়। ভার্বোস হওয়ার ক্ষতি কোথায়?


1

বিদেশী কীটির নামকরণ কীভাবে

ভূমিকা_id

রেফারেন্সড সত্তাটি হাতের টেবিলের সাথে সম্পর্কিত হওয়ার ক্ষেত্রে ভূমিকাটি। এটি একই টেবিলটিতে পুনরাবৃত্ত তথ্যসূত্র এবং একাধিক fks এর সমস্যা সমাধান করে।

অনেক ক্ষেত্রে রেফারেন্সযুক্ত টেবিলের নামের সাথে মিল থাকবে। এই ক্ষেত্রে এটি আপনার প্রস্তাবগুলির মধ্যে একটির মতো হয়ে যায়।

যে কোনও ক্ষেত্রে হ্যাভিন দীর্ঘ আর্গুমেন্ট একটি খারাপ ধারণা is


0

"যেখানে" কর্মচারী অর্ডার যোগ দিন অর্ডার.ইম্প্লোয়ে_আইডি = কর্মচারী। আইডিতে "অতিরিক্ত যোগ্যতার দরকার আছে?"

অতিরিক্ত যোগ্যতার প্রয়োজন নেই কারণ আমি যে যোগ্যতার কথা বলেছি তা ইতিমধ্যে রয়েছে।

"কোনও ব্যবসায়ী ব্যবহারকারী অর্ডার আইডি বা কর্মচারী আইডি উল্লেখ করার কারণটি প্রসঙ্গ সরবরাহ করা, তবে একটি ডাটাবেস পর্যায়ে আপনার ইতিমধ্যে প্রসঙ্গ রয়েছে কারণ আপনি টেবিলে উল্লেখ করছেন"।

প্রার্থনা করুন, আমাকে বলুন, যদি কলামটির নাম দেওয়া হয়েছে 'আইডি', তবে আইডি কলামের এই রেফারেন্সটিকে আমি ঠিক যেভাবে বলার যোগ্য করে না রেখে "টেবিলে" রেফারিং [sic] ঠিক কীভাবে করা হবে?

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.