সম্পর্কিত টেবিল নামকরণ কনভেনশন

Question

আমি একটি নতুন প্রকল্প শুরু করছি এবং শুরু থেকেই আমার টেবিল- এবং কলামের নামগুলি পেতে চাই। উদাহরণস্বরূপ আমি সর্বদা টেবিলের নামগুলিতে বহুবচন ব্যবহার করেছি তবে সম্প্রতি শিখেছি এককুলারটি সঠিক।

সুতরাং, যদি আমি একটি টেবিল পেয়েছি "ব্যবহারকারী" এবং তারপরে আমি কেবলমাত্র ব্যবহারকারীর কাছে থাকা পণ্যগুলি পেয়েছি, টেবিলটির নামকরণ করা উচিত "ব্যবহারকারীর_ উত্পাদন" বা কেবল "পণ্য"? এটি অনেক সম্পর্কের মধ্যে একটি।

এবং আরও বলতে গেলে, আমি যদি প্রতিটি পণ্যটির জন্য কয়েকটি কারণের (কোনও কারণে) বিবরণী রাখি তবে এটি কি "ব্যবহারকারীর_পরিচয়_ বিবরণ" বা "পণ্য_ বিবরণ" বা কেবল "বিবরণ" হবে? অবশ্যই সঠিক বিদেশী কী সেট করা আছে .. এটির নামকরণের নামকরণই সমস্যাযুক্ত কারণ আমার ব্যবহারকারীর বিবরণ বা অ্যাকাউন্টের বিবরণ বা যা কিছু থাকতে পারে ..

আমি যদি কেবল দুটি কলাম সহ খাঁটি সম্পর্কের টেবিলটি (অনেকের কাছে অনেক) চাই, তবে এটির মতো দেখতে কেমন? "ইউজার_স্টফ" বা সম্ভবত "রিল_ইউজার_স্টফ" এর মতো কিছু? এবং যদি প্রথমটি হয় তবে এটির থেকে কী আলাদা করা যাবে, উদাহরণস্বরূপ "ব্যবহারকারীর_ উত্পাদন"?

যে কোনও সাহায্যের প্রশংসা করা হয় এবং যদি আপনার ছেলেরা সুপারিশ করে যে নামকরণের নামকরণের কোনও প্রকার যদি সেখানে থাকে তবে বিনা দ্বিধায় লিঙ্ক করুন।

ধন্যবাদ

Comments

(ক) প্রশ্নটি জিজ্ঞাসা করা হয়েছিল এবং চার বছর আগে উত্তর দেওয়া হয়েছিল। (খ) প্রশ্ন এবং নির্বাচিত উত্তর উভয়েরই উচ্চ ভোট রয়েছে। (গ) আমাদের একটি নামকরণ-কনভেনশন ট্যাগ রয়েছে (ঘ) কোনও উত্তরদাতাকে উত্তর দেওয়ার জন্য এটি "মতামত ভিত্তিক" হতে পারে, তবে অভিজ্ঞ প্রযুক্তিবিদদের কাছে এটি আদর্শের বিষয়, যাদের সন্ধানকারী খুঁজছেন। তবুও, অনেকগুলি প্রেসক্রিপশনগুলির প্রতিটিটির জন্য কারণ দেওয়া হয়। (ঙ) সুতরাং, প্রমাণের ভিত্তিতে, primarily opinion-basedস্পষ্টতই মিথ্যা।

— পারফরম্যান্সডিবিএ

অভিজ্ঞ প্রযুক্তিবিদ বা প্রাচীন আইডিইএফ স্ট্যান্ডার্ড জুড়ে আসা এবং বিশ্বাস করা যে তারা প্রকৃত মানদণ্ডের জন্য এটি স্ট্যান্ডার্ডের বিষয়।

— জিবিআর

তদ্ব্যতীত, নামকরণ কনভেনশনগুলিতে রয়েছে আরও বেশ কয়েকটি কিউস রয়েছে, সকলেরই একটি মূল্য রয়েছে। ডানদিকে কলামে লিঙ্কযুক্ত উল্লেখ করুন ..

— পারফরম্যান্সবিডিবি

Answer 1

ছক • নাম

সম্প্রতি শিখেছি একবচন সঠিক

হ্যাঁ. বিধর্মীদের থেকে সাবধান থাকুন। টেবিলের নামগুলির বহুবচন হ'ল এমন কোনও ব্যক্তির একটি নিশ্চিত চিহ্ন যাঁর কোনও মানক পদার্থ পড়েনি এবং ডাটাবেস তত্ত্ব সম্পর্কে জ্ঞান নেই।

মানক সম্পর্কে দুর্দান্ত কিছু জিনিস হ'ল:

• তারা সবাই একে অপরের সাথে একীভূত হয়
• তারা একসাথে কাজ
• এগুলি আমাদের চেয়ে বৃহত্তর মন দ্বারা রচিত হয়েছিল, তাই তাদের নিয়ে আমাদের বিতর্ক করার দরকার নেই।

স্ট্যান্ডার্ড টেবিলের নামটি টেবিলের প্রতিটি সারি বোঝায় , যা সমস্ত ভার্চিয়ায় ব্যবহৃত হয়, টেবিলের মোট সামগ্রী নয় (আমরা জানি যে Customerটেবিলটিতে সমস্ত গ্রাহক রয়েছে)।

সম্পর্ক, ক্রিয়া বাক্যাংশ

জেনুইন রিলেশনাল ডেটাবেসগুলিতে মডেল করা হয়েছে (1970-এর পূর্বের রেকর্ড ফাইলিং সিস্টেমগুলির বিপরীতে [ Record IDsসুবিধার জন্য একটি এসকিউএল ডাটাবেস ধারক প্রয়োগ করা হয় যার দ্বারা চিহ্নিত ):

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

Diagram_A

অবশ্যই, সম্পর্কটি CONSTRAINT FOREIGN KEYশিশু টেবিলে একটি হিসাবে এসকিউএল তে প্রয়োগ করা হয়েছে (আরও, পরে)। এখানে Verb বাক্যাংশ (মডেলটিতে), পূর্বাভাস যা এটি উপস্থাপন করে (মডেল থেকে পড়তে হবে), এবং এফকে সীমাবদ্ধতার নাম :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

সারণী • ভাষা

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

    Each Customer initiates zero-to-many SalesOrders

না

    Customers have zero-to-many SalesOrders 

সুতরাং, যদি আমি একটি টেবিল পেয়েছি "ব্যবহারকারী" এবং তারপরে আমি কেবলমাত্র ব্যবহারকারীদের কাছে থাকা পণ্যগুলি পেয়েছি, সারণীর "ব্যবহারকারী-পণ্য" বা কেবল "পণ্য" নামকরণ করা উচিত? এটি অনেক সম্পর্কের মধ্যে একটি।

(এটি নামকরণ-কনভেনশন প্রশ্ন নয়; এটি আ ডিবি ডিজাইনের প্রশ্ন)) user::product1 :: n হয় কিনা তা বিবেচ্য নয়। কী গুরুত্বপূর্ণ তা productপৃথক সত্তা কিনা এবং এটি একটি স্বতন্ত্র টেবিল , কিনা is এটি নিজস্বভাবে থাকতে পারে। অতএব product, না user_product।

এবং যদি productকেবলমাত্র একটি প্রসঙ্গে থাকে তবে user। এটি একটি নির্ভরশীল টেবিল , সুতরাং user_product।

Diagram_B

এবং আরও বলতে গেলে, আমি যদি প্রতিটি পণ্যটির জন্য (কোনও কারণে) একাধিক পণ্যের বিবরণ পাই, তবে এটি "ব্যবহারকারী-পণ্য-বিবরণ" বা "পণ্য-বিবরণ" বা কেবল "বিবরণ" হবে? অবশ্যই সঠিক বিদেশী কী সেট করা আছে .. কেবলমাত্র বিবরণটির নামকরণ করা সমস্যাযুক্ত কারণ আমার ব্যবহারকারীর বিবরণ বা অ্যাকাউন্টের বিবরণ বা যা কিছু থাকতে পারে।

সেটা ঠিক. হয় user_product_descriptionxor product_descriptionউপরের উপর ভিত্তি করে সঠিক হবে। এটি অন্যের থেকে পৃথক করার জন্য নয় xxxx_descriptions, তবে নামটি এটি কোথায় রয়েছে তার একটি ধারণা প্রদান করা, যার উপসর্গটি পিতামাতার সারণী।

আমি যদি কেবল দুটি কলাম সহ খাঁটি সম্পর্কের টেবিলটি (অনেকের কাছে অনেক) চাই, তবে এটির মতো দেখতে কেমন? "ব্যবহারকারীর স্টাফ" বা সম্ভবত "rel-user-stuff" এর মতো কিছু? এবং যদি প্রথমটি হয় তবে এটির থেকে কী আলাদা হবে, উদাহরণস্বরূপ "ব্যবহারকারী-পণ্য"?

1. আশা করি রিলেশনাল ডাটাবেসের সমস্ত টেবিলগুলি খাঁটি সম্পর্কযুক্ত, সাধারণ টেবিল। নামে এটি সনাক্ত করার দরকার নেই (অন্যথায় সমস্ত টেবিল হবে rel_something)।

2. যদি এতে কেবলমাত্র দুটি পিতা-মাতার পিকে থাকে (যা যৌক্তিক এন :: এন সম্পর্ককে যৌক্তিক স্তরে সত্তা হিসাবে বিদ্যমান নয়, একটি শারীরিক টেবিলের মধ্যে সমাধান করে), এটি একটি সহযোগী ছক । হ্যাঁ, সাধারণত নামটি দুটি পিতামাতার নামের সংমিশ্রণ।

   • নোট করুন যে এই জাতীয় ক্ষেত্রে ক্রিয়া বাক্যাংশ প্রযোজ্য, এবং সন্তানের টেবিলকে উপেক্ষা করে পিতামাতার কাছ থেকে যেমন পড়া হয়, কারণ জীবনের একমাত্র উদ্দেশ্য হ'ল দুটি পিতা-মাতার সাথে সম্পর্কযুক্ত।

     Diagram_C

   • যদি তা না হয় না একটি মিশুক ছক (অর্থাত। দুই পিকেএস ছাড়াও, এটা তথ্য রয়েছে), তারপর এটা উপযুক্তভাবে নাম দিন, এবং ক্রিয়া বাক্যাংশ এটি, সম্পর্ক শেষে না পিতা বা মাতা প্রযোজ্য।

     Diagram_D

3. যদি আপনি দুটি user_productটেবিল দিয়ে শেষ করেন , তবে এটি খুব উচ্চতর সংকেত যা আপনি ডেটাটিকে সাধারণীকরণ করেননি। সুতরাং কয়েকটি পদক্ষেপ ফিরে যান এবং এটি করুন এবং সারণীগুলির নাম নির্ভুল এবং ধারাবাহিকভাবে দিন। নামগুলি তখন তাদের সমাধান করবে।

নামকরণ কনভেনশন

যে কোনও সাহায্যের প্রশংসা করা হয় এবং যদি আপনার ছেলেরা সুপারিশ করে যে নামকরণের নামকরণের কোনও প্রকার যদি সেখানে থাকে তবে বিনা দ্বিধায় লিঙ্ক করুন।

আপনি যা করছেন তা অত্যন্ত গুরুত্বপূর্ণ এবং এটি প্রতিটি স্তরে ব্যবহারের সহজলভ্যতা এবং বোঝার উপর প্রভাব ফেলবে। সুতরাং শুরুতে যতটা সম্ভব বোঝাপড়া পাওয়া ভাল। আপনি এসকিউএল এ কোডিং শুরু না করা পর্যন্ত এর বেশিরভাগের প্রাসঙ্গিকতা স্পষ্ট হবে না।

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

2. কোনও অ্যাপ্লিকেশন বা ব্যবহারের ফোকাস নয়, ডেটা ফোকাস বজায় রাখুন । এটি, সমস্ত 2011 পরে, আমাদের ওপেন আর্কিটেকচার হয়েছে 1984 এর পর থেকে এবং ডেটাবেসগুলি সেগুলি যে অ্যাপ্লিকেশনগুলি ব্যবহার করে সেগুলি থেকে আলাদা বলে মনে করা হচ্ছে।

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

3. খুব বিচক্ষণ এবং নাম টেবিল এবং কলামগুলি খুব নির্ভুলভাবে করুন । UpdatedDateএটি যদি DATETIMEডেটাটাইপ হয় তবে ব্যবহার করবেন না UpdatedDtm। _descriptionএটিতে ডোজ থাকলে ব্যবহার করবেন না ।

4. এটি ডাটাবেস জুড়ে সামঞ্জস্যপূর্ণ হওয়া গুরুত্বপূর্ণ । ব্যবহার করবেন না NumProductএক জায়গায় পণ্য সংখ্যা এবং ইঙ্গিত ItemNoবা ItemNumঅন্য জায়গায় আইটেমের সংখ্যা নির্দেশ করে হবে। ব্যবহার করুন NumSomethingসংখ্যা অফ, এবং SomethingNoবা SomethingIdশনাক্তকারী জন্য, ধারাবাহিকভাবে।

5. সারণীর নাম বা সংক্ষিপ্ত কোড যেমন কলামের নামটি উপস্থাপন করবেন না user_first_name। এসকিউএল ইতিমধ্যে যোগ্যতা হিসাবে টেবিলের নাম সরবরাহ করে:

       table_name.column_name  -- notice the dot
   

6. ব্যতিক্রমসমূহ:

   • প্রথম ব্যতিক্রম পিকেগুলির জন্য, তাদের বিশেষ হ্যান্ডলিং দরকার কারণ আপনি এগুলিকে সর্বদা যোগ দিয়ে থাকেন এবং আপনি কী ডেটা কলাম থেকে আলাদা হয়ে থাকতে চান want সর্বদা ব্যবহার user_id, কখনও না id।

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

   • দ্বিতীয় ব্যতিক্রম হ'ল যেখানে একাধিক এফকে সন্তানের বহন করে একই পিতামাতার টেবিল টেবিলটি উল্লেখ করা হয়। অনুযায়ী রিলেশনাল মডেল , ব্যবহার ভূমিকা নাম অর্থ বা ব্যবহারের যেমন পার্থক্য। AssemblyCodeএবং ComponentCodeদুই জন্য PartCodes। এবং সেক্ষেত্রে এগুলির একটির জন্য অবিচ্ছিন্ন ব্যবহার করবেন নাPartCode । নিখুঁত হউন.

     Diagram_E

7. উপসর্গ
   যেখানে আপনার 100 টি টেবিলের বেশি বলা আছে, সেখানে সাবজেক্ট এরিয়া দিয়ে টেবিলের নামগুলি উপসর্গ করুন:

   REF_ রেফারেন্স সারণীর জন্য
   OE_অর্ডার এন্ট্রি ক্লাস্টারের জন্য, ইত্যাদি।

   শুধুমাত্র শারীরিক স্তরে, যৌক্তিক নয় (এটি মডেলকে ছড়িয়ে দেয়)।

8. প্রত্যয়
   কখনও টেবিলগুলিতে প্রত্যয় ব্যবহার করবেন না এবং সর্বদা সর্বদা প্রত্যয় ব্যবহার করুন। এর অর্থ ডাটাবেসের যৌক্তিক, সাধারণ ব্যবহারের মধ্যে কোনও আন্ডারস্কোর নেই; তবে প্রশাসনিক দিক থেকে, আন্ডারস্কোরগুলি পৃথককারী হিসাবে ব্যবহৃত হয়:

   _Vদেখুন ( TableNameসামনে মূল সহ , অবশ্যই)
   _fkবিদেশী কী (সীমাবদ্ধতার নাম, কলামের নাম নয়)
   _cacক্যাশে
   _segবিভাগের
   _trলেনদেন (সঞ্চিত প্রোক বা ফাংশন)
   _fnফাংশন (অ-লেনদেনের) ইত্যাদি etc.

   ফর্ম্যাটটি হ'ল টেবিল বা এফকে নাম, একটি আন্ডারস্কোর এবং ক্রিয়া নাম, একটি আন্ডারস্কোর এবং অবশেষে প্রত্যয়।

   এটি সত্যই গুরুত্বপূর্ণ কারণ যখন সার্ভার আপনাকে একটি ত্রুটি বার্তা দেয়:

   ____blah blah blah error on object_name

   কোন জিনিসটি লঙ্ঘন করা হয়েছিল এবং এটি করার চেষ্টা করছিল তা আপনি ঠিক জানেন:

   ____blah blah blah error on Customer_Add_tr

9. বিদেশী কী (সীমাবদ্ধতা, কলামটি নয়)। এফকে সবচেয়ে ভাল নামকরণ হ'ল ভার্বব বাক্যাংশ (বিয়োগ "প্রতিটি" এবং কার্ডিনালিটি) ব্যবহার করা।

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Parent_Child_fkক্রমটি ব্যবহার করুন না Child_Parent_fkকারণ (ক) আপনি যখন তাদের সন্ধান করছেন তখন এটি সঠিক ক্রমে প্রদর্শিত হয় এবং (খ) আমরা জড়িত শিশুটিকে সর্বদা জানি, আমরা কী অনুমান করছি তা কোন পিতামাতার। ত্রুটি বার্তাটি তখন আনন্দদায়ক:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk।

   এটি সেই লোকদের জন্য ভাল কাজ করে যারা তাদের ডেটা মডেল করতে বিরত হন, যেখানে ভার্ভ বাক্যাংশগুলি চিহ্নিত করা হয়েছিল। বাকিগুলির জন্য, রেকর্ড ফাইলিং সিস্টেমগুলি, ইত্যাদি Parent_Child_fk।

10. সূচকগুলি বিশেষ, তাই তাদের নিজস্ব নিজস্ব একটি নামকরণের কনভেনশন রয়েছে, যাতে প্রতিটি চরিত্রের অবস্থান 1 থেকে 3 পর্যন্ত থাকে:

    Uঅনন্য, বা _অ-অনন্য
    Cক্লাস্টারযুক্ত, বা _নন-ক্লাস্টার
    _বিভাজকের জন্য

    বাকি জন্য:

    • কীটি যদি একটি কলাম বা খুব কয়েকটি কলাম হয়:
      ____ColumnNames

    • কীটি যদি কয়েকটি কলামের বেশি হয়:
      ____ PKপ্রাথমিক কী (মডেল অনুযায়ী)
      ____ AK[*n*]বিকল্প কী (আইডিইএফ 1 এক্স শব্দ)

    নোট করুন যে সারণির নাম সূচকের নামে প্রয়োজন হয় না , কারণ এটি সর্বদা হিসাবে প্রদর্শিত হয়table_name.index_name.

    সুতরাং যখন Customer.UC_CustomerIdবা Product.U__AKত্রুটি বার্তায় উপস্থিত হয়, এটি আপনাকে অর্থপূর্ণ কিছু বলে। আপনি যখন কোনও টেবিলে সূচকগুলি দেখেন, আপনি এগুলি সহজেই আলাদা করতে পারেন।

11. যোগ্য এবং পেশাদার কাউকে খুঁজুন এবং তাদের অনুসরণ করুন। তাদের নকশা দেখুন এবং সাবধানতার সাথে তারা যে নামকরণ কনভেনশনগুলি ব্যবহার করেন তা অধ্যয়ন করুন। আপনি বুঝতে পারেন না এমন কিছু সম্পর্কে তাদের নির্দিষ্ট প্রশ্ন জিজ্ঞাসা করুন। বিপরীতে, যে কেউ নামকরণের সম্মেলন বা মান সম্পর্কে সামান্য সম্মান দেখায় তার কাছ থেকে নরকের মতো ছুটে যান। আপনাকে শুরু করার জন্য এখানে কয়েকটি দেওয়া হল:

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

স্ট্যান্ডার্ড-অনুবর্তী ঠিকানাগুলি সহ অর্ডার এন্ট্রি এবং ইনভেন্টরি

পিএইচপি / মাইননএসকিউএল এর জন্য সহজ আন্তঃ অফিস বুলেটিন সিস্টেম

সম্পূর্ণ অস্থায়ী ক্ষমতা সহ সেন্সর পর্যবেক্ষণ

প্রশ্নের উত্তর

^{মন্তব্যের জায়গায় যুক্তিযুক্তভাবে উত্তর দেওয়া যায় না।}

ল্যারি লাস্টিগ:
... এমনকি সবচেয়ে তুচ্ছ উদাহরণ দেখায় ...
যদি কোনও গ্রাহকের শূন্য থেকে অনেকগুলি পণ্য থাকে এবং একটি পণ্যটিতে এক থেকে একাধিক উপাদান থাকে এবং একটি উপাদানতে এক থেকে একাধিক সরবরাহকারী থাকে এবং সরবরাহকারী শূন্য বিক্রয় করে অনেকগুলি উপাদান এবং একটি বিক্রয়রেপে একাধিক গ্রাহক থাকে "প্রাকৃতিক" গ্রাহক, পণ্য, উপাদান এবং সরবরাহকারীদের সারণীগুলির নাম কী?

আপনার মন্তব্যে দুটি বড় সমস্যা রয়েছে:

1. আপনি আপনার উদাহরণটিকে "সর্বাধিক তুচ্ছ" হিসাবে ঘোষণা করেছেন, তবে এটি কিছুই নয়। এই ধরণের বৈপরীত্যের সাথে, আপনি যদি গুরুতর হন তবে প্রযুক্তিগতভাবে সক্ষম হলে আমি অনিশ্চিত।

2. এই "তুচ্ছ" জল্পনা বেশ কয়েকটি স্থূল নর্মালাইজেশন (ডিবি ডিজাইন) ত্রুটি রয়েছে।

   • যতক্ষণ না আপনি এগুলি সংশোধন করেন, এগুলি অপ্রাকৃত এবং অস্বাভাবিক এবং এগুলি কোনও ধারণা রাখে না। আপনি এগুলির পাশাপাশি নাম রাখতে পারেন অস্বাভাবিক_1, অস্বাভাবিক 2, ইত্যাদি etc.

   • আপনার কাছে "সরবরাহকারী" রয়েছে যারা কিছু সরবরাহ করেন না; বিজ্ঞপ্তি সংক্রান্ত রেফারেন্স (অবৈধ এবং অপ্রয়োজনীয়); গ্রাহকরা কোনও বাণিজ্যিক সরঞ্জাম ছাড়াই পণ্য কিনে (যেমন চালান বা বিক্রয় অর্ডার হিসাবে) কেনার ভিত্তি হিসাবে (বা গ্রাহকদের "নিজস্ব" পণ্য রয়েছে?); অমীমাংসিত বহু থেকে বহু সম্পর্ক; প্রভৃতি

   • এটি একবার সাধারণ হয়ে গেলে, এবং প্রয়োজনীয় সারণীগুলি সনাক্ত করা গেলে, তাদের নামগুলি সুস্পষ্ট হয়ে উঠবে। স্বাভাবিকভাবে.

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

• আমি ধরে নেব যে পণ্যটি যদি উপাদানগুলির সমন্বয়ে গঠিত হয় তবে পণ্যটি একটি সমাবেশ হয় এবং উপাদানগুলি একাধিক সমাবেশে ব্যবহৃত হয়।

• আরও, যেহেতু "সরবরাহকারী শূন্য থেকে অনেকগুলি উপাদান বিক্রি করে" যেগুলি তারা তা করে না পণ্য বা সমাবেশগুলি বিক্রি করে , তারা কেবল উপাদানগুলি বিক্রি করে।

জল্পনা বনাম সাধারণ মডেল

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

... গ্রাহক, পণ্য, উপাদান এবং সরবরাহকারীদের রাখা টেবিলগুলির "প্রাকৃতিক" নামগুলি কী কী?

• ক্রেতা
• প্রোডাক্ট
• উপাদান (বা, এসেম্বল কম্পোনেন্ট, যারা বুঝতে পারেন যে একটি ঘটনা অন্যটিকে চিহ্নিত করে)
• সরবরাহকারী

এখন আমি টেবিলগুলি সমাধান করেছি, আমি আপনার সমস্যা বুঝতে পারি না। সম্ভবত আপনি একটি নির্দিষ্ট প্রশ্ন পোস্ট করতে পারেন ।

ভোটকফি:
রনিস তার উদাহরণে পোস্ট করা দৃশ্যটি আপনি কীভাবে পরিচালনা করছেন যেখানে দুটি সারণীর (ব্যবহারকারী_লিক্স_প্রডাক্টর, ব্যবহারকারী_ব্যক্ত_প্রডাক্ট) এর মধ্যে একাধিক সম্পর্ক বিদ্যমান? আমি ভুল বুঝে উঠতে পারি, তবে এর ফলে আপনার কনভেনশনটি বিশদভাবে ব্যবহার করে সারণীর নামগুলি সদৃশ হবে।

ধরে নেওয়া যাক কোনও সাধারণকরণের ত্রুটি নেই, User likes Productএটি একটি ছদ্মবেশী, কোনও সারণী নয়। তাদের বিভ্রান্ত করবেন না। আমার উত্তরটি দেখুন, যেখানে এটি সাবজেক্টস, ক্রিয়াগুলি এবং পূর্বাভাসগুলির সাথে সম্পর্কিত এবং সাথে সাথে আমার উপরে ল্যারির প্রতিক্রিয়া।

• প্রতিটি সারণীতে ফ্যাক্টসের একটি সেট থাকে (প্রতিটি সারিটি একটি বাস্তব)। পূর্বাভাস (বা প্রস্তাব), সত্য নয়, সেগুলি সত্য হতে পারে বা নাও পারে।

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

  • তদুপরি, প্রতিটি টেবিলটি একটি নয় , বহু পূর্বাভাসের প্রতিনিধিত্ব করে বা বাস্তবায়ন করে ।

• একটি ক্যোয়ারী একটি প্রিডিকেট (বা একাধিক ভবিষ্যদ্বাণী, এক সাথে জড়িত) এর পরীক্ষা যা সত্য (ফ্যাক্টটি বিদ্যমান) বা মিথ্যা (ফ্যাক্টের অস্তিত্ব নেই) এর ফলাফল।

• সুতরাং সারণীর নাম দেওয়া উচিত, যেমনটি আমার উত্তর (নামকরণের কনভেনশন) তে সারি অনুসারে, ফ্যাক্ট এবং প্রেডিকেটস নথিভুক্ত করা উচিত (সমস্ত উপায়ে এটি ডাটাবেস ডকুমেন্টেশনের অংশ) তবে ভবিষ্যদ্বাণীগুলির পৃথক তালিকা হিসাবে ।

• এটি গুরুত্বপূর্ণ নয় যে এগুলি কোনও পরামর্শ নয়। এগুলি খুব গুরুত্বপূর্ণ, তবে আমি এখানে এটি লিখব না।

• তাড়াতাড়ি, তারপর। যেহেতু রিলেশনাল মডেলটি এফপিসিতে প্রতিষ্ঠিত, তাই পুরো ডাটাবেসকে এফপিসি ঘোষণার একটি সেট, ভবিষ্যদ্বাণীগুলির একটি সেট বলা যেতে পারে। তবে (ক) অনেক ধরণের ভবিষ্যদ্বাণী রয়েছে এবং (খ) একটি সারণী একটি ভবিষ্যদ্বাণীকে প্রতিনিধিত্ব করে না (এটি বহু ভবিষ্যদ্বাণী এবং বিভিন্ন ধরণের ভবিষ্যদ্বাণীগুলির শারীরিক বাস্তবায়ন )।

• সুতরাং "" ভবিষ্যদ্বাণী যে এটি "উপস্থাপন করে" এর জন্য সারণীর নামকরণ একটি অবাস্তব ধারণা।

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

  • এবং অবশ্যই, তারা কয়েক থেকে কিম্ভুতকিমাকার বেশী যে তারা জানে না নির্বাচন করুন: EXISTING_PERSON; PERSON_IS_CALLED। যদি এটি এতটা দুঃখ না হত তবে এটি হাসিখুশি হবে।

  • আরও লক্ষ করুন যে স্ট্যান্ডার্ড বা পারমাণবিক সারণীর নাম (সারিটির নামকরণ) সমস্ত ভার্বায়েজ (টেবিলের সাথে সংযুক্ত সমস্ত ভবিষ্যদ্বাণী সহ) জন্য দুর্দান্তভাবে কাজ করে। বিপরীতভাবে, বোকা "টেবিল প্রিকেট প্রতিনিধিত্ব করে" নামটি পারে না। যা "তাত্ত্বিকদের" পক্ষে ঠিক আছে, যারা ভবিষ্যদ্বাণী সম্পর্কে খুব কম বোঝেন, তবে অন্যথায় প্রতিবন্ধক হন।

• পূর্বাভাসগুলি যা ডেটা মডেলের সাথে প্রাসঙ্গিক, মডেলটিতে প্রকাশিত হয় , সেগুলি দুটি আদেশের।

  1. ইউনিারি প্রিডিকেট
     প্রথম সেটটি ডায়াগ্রাম্যাটিক , টেক্সট নয়: স্বরলিপিটি । এর মধ্যে রয়েছে বিভিন্ন অস্তিত্বের অন্তর্ভুক্ত; বাধ্যতা ওরিয়েন্টেড; এবং বর্ণনাকারী (গুণাবলী) পূর্বাভাস।

     • অবশ্যই, এর অর্থ যারা কেবলমাত্র একটি স্ট্যান্ডার্ড ডেটা মডেলই 'পড়তে' পারেন সেই ভবিষ্যদ্বাণীগুলি পড়তে পারেন। একারণে "তাত্ত্বিক", যারা কেবল তাদের পাঠ্য-একমাত্র মানসিকতার দ্বারা গুরুতরভাবে পঙ্গু হয়ে পড়েছে, তারা ডেটা মডেলগুলি পড়তে পারে না, কেন তারা 1984-এর পূর্বের পাঠ্য-কেবল মানসিকতার সাথে লেগে থাকে।

  2. বাইনারি ভবিষ্যদ্বাণী
     দ্বিতীয় সেটটি হ'ল ফ্যাক্টগুলির মধ্যে সম্পর্ক তৈরি করে। এটি সম্পর্ক রেখা। ক্রিয়া বাক্যাংশ (উপরে বর্ণিত) ভবিষ্যদ্বাণী, প্রস্তাবটি চিহ্নিত করে যা বাস্তবায়িত হয়েছে (যা ক্যোয়ারির মাধ্যমে পরীক্ষা করা যেতে পারে)। এর চেয়ে বেশি স্পষ্টতই আর কেউ পেতে পারে না।

     • সুতরাং, যিনি স্ট্যান্ডার্ড ডেটা মডেলগুলিতে সাবলীল, তার কাছে প্রাসঙ্গিক সমস্ত পূর্বাভাস মডেলটিতে নথিভুক্ত করা হয়। তাদের ভবিষ্যদ্বাণীগুলির একটি পৃথক তালিকা প্রয়োজন নেই (তবে ব্যবহারকারীরা, যারা ডেটা মডেল থেকে সমস্ত কিছু 'পড়তে পারেন না, করেন!')।

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

সুতরাং দুটি পিতামাতার টেবিলের মধ্যে একাধিক সন্তানের টেবিলের ঘটনা কোনও সমস্যা নয়, কেবল তাদের বিষয়বস্তুটিকে এক্সটেনশিয়াল ফ্যাক্ট হিসাবে নাম দিন এবং নামগুলি স্বাভাবিক করুন।

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

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

---

চার্লস বার্নস:
ক্রমানুসারে, আমি বলতে চাইছিলাম ওরাকল-স্টাইলের অবজেক্টটি কোনও নিয়ম অনুসারে একটি নম্বর এবং এর পরবর্তী অংশটি বিশুদ্ধরূপে ব্যবহৃত হয় (যেমন "1 যোগ করুন")। যেহেতু ওরাকলটিতে অটো-আইডি টেবিলের অভাব রয়েছে, তাই আমার সাধারণ ব্যবহারটি টেবিল পিকেগুলির জন্য স্বতন্ত্র আইডি তৈরি করা। অন্তর্ভুক্ত foo (আইডি, সোমডাটা) ভ্যালু (foo_s.nextval, "ডেটা" ...)

ঠিক আছে, এটিকেই আমরা একটি কী বা নেক্সটকি টেবিল বলি। নাম হিসাবে এটি। যদি আপনার সাবজেক্টআরিয়াস থাকে তবে এটি ডাটাবেস জুড়ে সাধারণ তা বোঝাতে COM_NextKey ব্যবহার করুন।

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

Comments

দুর্দান্ত ক্লিনআপ, আপনাকে ধন্যবাদ। সমস্ত ভাল মন্তব্য (তারকাচিহ্নিত, ভোট দেওয়া) পাশাপাশি গেছে। ওহ ভাল, সময় দিন, এবং তারা ফিরে আসবে।

— পারফরমেন্সডিবিএ

পোস্টটিতে comments 76 টি মন্তব্য ছিল, উত্তরের মধ্যে মূল্যবান কিছু হওয়া উচিত ছিল কারণ সেগুলি থেকে কোনও কিছুই বের করা প্রায় অসম্ভব।

— তারিন

@PerformanceDBA। "এটিই উত্তরের ধরণ যা আমি চাই যে আমি অভিনয় করতে পারতাম" - এর মতো কোনও মন্তব্য উত্তরকে সরানো উচিত নয় । যে ধরণের জিনিসটি অন্তর্ভুক্ত করা উচিত তা হ'ল মন্তব্যগুলির স্পষ্টতা জিজ্ঞাসা করা বা ত্রুটিগুলি নির্দেশ করার উত্তর ।

— ক্রিসএফ

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

— পারফরম্যান্সডিবিএ

আপনি কি এই "স্ট্যান্ডার্ড" এর কোনওটির জন্য রেফারেন্স সরবরাহ করতে পারেন? বর্তমানে এটি কেবল একটি খুব ভালভাবে লেখা ব্যক্তিগত মতামত।

— শেন কোর্ট্রিল 18

Answer 2

একবচন বনাম বহুবচন: একটি বাছাই করুন এবং এটি দিয়ে আটকে দিন।

কলামগুলি উপসর্গযুক্ত / প্রত্যয়যুক্ত / ইনফিক্সিং করা উচিত নয় বা যাইহোক এটি একটি কলাম হিসাবে উল্লেখের সাথে সংশোধন করা উচিত। একই টেবিলের জন্য যায়। EMPLOYEE_T বা TBL_EMPLOYEES টেবিলের নাম রাখবেন না কারণ দ্বিতীয়টি এটির সাথে প্রতিস্থাপন করা হয়েছে, জিনিসগুলি সত্যই বিভ্রান্ত হয়।

নামগুলিতে প্রকারের তথ্য এম্বেড করবেন না, যেমন বর্ণের জন্য "vc_firstname", বা "flavour_enum"। কলামের নামগুলিতে যেমন "বিভাগ_এফকে" বা "কর্মচারী_পিকে" সীমাবদ্ধ করবেন না don't

আসলে, * সংশোধন করা হয়েছে আমি মনে করতে পারেন, সম্পর্কে শুধুমাত্র ভাল জিনিস যে তোমার মত সংরক্ষিত শব্দ ব্যবহার করতে পারেন where_t, tbl_order, user_vw। অবশ্যই, সেই উদাহরণগুলিতে, বহুবচন ব্যবহার করে সমস্যার সমাধান হয়ে যেত :)

সমস্ত কীগুলির নাম "আইডি" রাখবেন না। একই জিনিসটিকে বোঝানো কীগুলি, সমস্ত টেবিলে একই নাম থাকা উচিত। ব্যবহারকারীর আইডি কলামটি ব্যবহারকারী সারণীতে এবং ব্যবহারকারীকে উল্লেখ করা সমস্ত টেবিলগুলিতে USER_ID বলা যেতে পারে। শুধুমাত্র ব্যবহারকারী যখন বিভিন্ন ব্যবহারকারী বিভিন্ন বার্তা যেমন মেসেজ (প্রেরক_ ব্যবহারকারী_আইডি, রিসিভার_ইউজার_আইডি) খেলছেন তখনই নামটির নামকরণ হয়। বৃহত্তর প্রশ্নের সাথে ডিল করার সময় এটি সত্যই সহায়তা করে।

সিএএস সম্পর্কিত:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

সাধারণভাবে উল্লেখ করা টেবিলের নামের চেয়ে বর্ণিত সম্পর্কের সাথে মেলে তুলতে "ম্যাপিং টেবিলগুলি" নামকরণ করা ভাল। একজন ব্যবহারকারী পণ্য সম্পর্কের কোন সংখ্যা হতে পারে user_likes_product, user_bought_product, user_wants_to_buy_product।

Comments

আমি আন্ডারস্কোর তাকান পছন্দ করি তবে আমি উট কেস টাইপ করতে পছন্দ করি। আন্ডারস্কোর সম্পর্কে কিছু আছে ... আমি যতই অনুশীলন করি না কেন, আমি কীবোর্ডটি থামাতে এবং বাধ্য করতে বাধ্য হই।

— লর্ড টাইডাস

@ রনিস, আপনি কি দয়া করে "" সমস্ত কীটির নাম "আইডি" রাখবেন না তা বিশদভাবে বর্ণনা করবেন। কী একই জিনিসকে উল্লেখ করে, সমস্ত টেবিলে একই নাম থাকা উচিত? ""

— ট্র্যাভিস

@ ট্রাভিস, নিশ্চিত যে আমি পারতাম, কিন্তু পুরো অনুচ্ছেদটি কি একটি বিস্তৃতকরণ?

— রোনিস

আমি আমার প্রশ্নের একটি (অ-পৃথকীকৃত ভূমিকা) নামকরণ সুবিধাগুলো সিন্থেটিক প্রাথমিক কী হয় {table_name}_idবরং তুলনায় id, যেহেতু কলাম শুধুমাত্র কখনও সারণী নাম একটি কোয়ালিফায়ার, যেমন যেমন পূর্বে সমাধান সঙ্গে উল্লেখ করা হবে table_name.id। প্রসঙ্গে, আমি এমন একটি বাস্তু সিস্টেমে পরিচালনা করছি যেখানে ফর্মের সিনট্যাক্সটিতে যোগদানের table_a JOIN table_b ON table_b_id_columnসমর্থন নেই; আমাকে করতে হবে table_a JOIN table_b ON table_b.id_column = table_a.table_b_id_column।

— ট্র্যাভিস

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

— রনিস

Answer 3

একবচন বনাম বহুবচন সম্পর্কে কোনও 'সঠিক' নেই - এটি বেশিরভাগ স্বাদের বিষয়।

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

1. যেহেতু আপনার সম্ভবত একটি সারণী 'ব্যবহারকারী', অন্য একটি 'পণ্য' এবং তৃতীয়টি ব্যবহারকারীদের পণ্যগুলির সাথে সংযুক্ত করার জন্য প্রয়োজন, তারপরে আপনার একটি 'সারণী ব্যবহারকারীর প্রোডাক্ট' দরকার।

2. যেহেতু বিবরণটি কোনও পণ্যের ক্ষেত্রে প্রযোজ্য তাই আপনি 'product_descript' ব্যবহার করবেন। যতক্ষণ না প্রতিটি ব্যবহারকারী নিজের জন্য প্রতিটি পণ্য নাম দেয় ...

3. 'ইউজার_প্রডাক্ট' টেবিলটি প্রোডাক্ট আইডি এবং ব্যবহারকারীর আইডি সহ অন্য কোনও নয় এমন একটি সারণীর উদাহরণ (বা হতে পারে)। আপনি একই সাধারণভাবে দ্বি-গুণযুক্ত টেবিলের নাম দিন: 'ব্যবহারকারীর_সন্ধান'। 'Rel_' এর মতো আলংকারিক উপসর্গগুলি সত্যই সহায়তা করে না। উদাহরণস্বরূপ আপনি কিছু লোককে দেখতে পাবেন প্রতিটি টেবিলের নামের সামনে 't_' ব্যবহার করে। এটি অনেক সাহায্যকারী নয়।

Comments

যখন আপনি "এবং তৃতীয় ব্যবহারকারীদের সংযোগ করার জন্য" বলবেন। আপনি একটি তৃতীয় টেবিল মানে? একাধিক সম্পর্কের সাথে এক থাকার সময় আমার তৃতীয় টেবিলের কী দরকার (ব্যবহারকারীদের অনেক পণ্য রয়েছে)? আপনি উপায় দ্বারা ব্যবহারকারীর পরিবর্তে ব্যবহারকারীর প্রোডাক্ট ব্যবহার করার পরামর্শ দিন?

— আন্দ্রেয়াস

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

— জোনাথন লেফলার

দুঃখিত, পণ্যগুলির চেয়ে আমার আরও ভাল উদাহরণ ব্যবহার করা উচিত ছিল। আমি এটি এমনভাবে বোঝাতে চাইছিলাম যে পণ্যটি কোনও ব্যবহারকারীর কাছে অনন্য। তাই এই সঙ্গে, সাফ আমি অনুমান বিবরণ টেবিল হতে হবে, "user_product_description" এটি ব্যবহারকারী / পণ্যের জন্য অনন্য যেহেতু .. আমি কি দেখতে একটি ভয়ঙ্কর উদাহরণ আমি পণ্যের সঙ্গে নেন :) আপনাকে ধন্যবাদ জানেন

— আন্দ্রিয়াস

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

— জোনাথন লেফলার

Answer 4

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

আপনি বহু-বহু সম্পর্কের রূপরেখাই না করতে চাইলে আমি আন্ডারস্কোরগুলি দিয়ে থাকব; এবং একটি প্রাথমিক মূলধন ব্যবহার করুন কারণ এটি ওআরএম-এ জিনিস আলাদা করতে সহায়তা করে।

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

তাই:

User

UserProduct (it is a users products after all)

যদি কেবলমাত্র একজন ব্যবহারকারীর কোনও পণ্য থাকতে পারে

UserProductDescription

তবে পণ্যটি যদি ব্যবহারকারীরা ভাগ করে নেয়:

ProductDescription

আপনি যদি অনেকগুলি সংখ্যক সম্পর্কের জন্য আন্ডারস্কোরগুলি সংরক্ষণ করেন তবে আপনি যেমন কিছু করতে পারেন:

UserProduct_Stuff

ব্যবহারকারী-উত্পাদন এবং স্টাফের মধ্যে এম-টু-এম গঠনের জন্য - প্রশ্ন থেকে নিশ্চিত নন যে বহু-থেকে-বহু লোকের সঠিক প্রকৃতি।

Comments

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

— আন্দ্রেয়াস

@ আন্দ্রেয়াস আপনাকে টেবিলগুলির জন্য উচ্চতর কেস ব্যবহার করার দরকার নেই, কেবল পৃথক শব্দের প্রথম অক্ষরকে মূলধন করুন।

— অমলভিন

Answer 5

বহুবচন রূপের চেয়ে একক ব্যবহারের চেয়ে বেশি সঠিক নেই, আপনি কোথায় শুনেছেন? আমি বরং বলব যে ডাটাবেস টেবিলগুলির নামকরণের জন্য বহুবচন ফর্ম বেশি সাধারণ ... এবং আমার মতে আরও যুক্তিযুক্ত। সারণীতে প্রায়শই একাধিক সারি থাকে;) ধারণাগত মডেলে যদিও সত্তার নামগুলি প্রায়শই একবচন থাকে।

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