database - ডাটাবেস, টেবিল এবং কলাম নামকরণ কনভেনশন?




রিলেশনাল ডাটাবেজ কি (16)

  1. না। একটি টেবিলের নামটি সত্তা হিসাবে উপস্থাপন করা উচিত। ব্যক্তি, কোনও ব্যক্তির প্রতিনিধিত্বকারীকে আপনি কীভাবে উল্লেখ করবেন তা নয়।
  2. আবার, একই জিনিস। কলাম ফার্স্টনেম সত্যিই প্রথম নাম বলা উচিত নয়। এটা আপনি কলামের সাথে প্রতিনিধিত্ব করতে চান তার উপর নির্ভর করে।
  3. কোন।
  4. হ্যাঁ। এটা স্বচ্ছতার জন্য কেস। যদি আপনার "ফার্স্টনাম" মত কলাম থাকতে হবে, আবরণটি পড়তে সহজ হবে।

ঠিক আছে. আমার $ 0.02 Thats

যখনই আমি ডেটাবেস ডিজাইন করি, আমার ডেটাবেসে একটি আইটেম নামকরণের সেরা উপায় থাকলে আমি সর্বদা আশ্চর্য হয়ে যাই। প্রায়শই আমি নিজেকে নিম্নলিখিত প্রশ্ন জিজ্ঞেস করি:

  1. টেবিলের নাম বহুবচন হতে হবে?
  2. কলাম নাম একক হতে হবে?
  3. আমি টেবিল বা কলাম উপসর্গ করা উচিত?
  4. আমি আইটেম নামকরণ কোনো ক্ষেত্রে ব্যবহার করা উচিত?

একটি ডাটাবেসের মধ্যে আইটেম নামকরণের জন্য সেখানে কোন সুপারিশ নির্দেশিকা আছে?


  1. নিশ্চিতভাবে টেবিল নাম একবচন, ব্যক্তি না মানুষ রাখা
    1. একই অবস্থা
    2. না। আমি কিছু ভয়ানক উপসর্গ দেখেছি, যা নিয়ে ডিল করা হয়েছে তা জানাতে এতদূর যাওয়া হয়েছে যে একটি টেবিল (tbl_) বা একটি ব্যবহারকারী স্টোর পদ্ধতি (usp_)। এই ডাটাবেসের নাম অনুসরণ করে ... এটা করবেন না!
    3. হ্যাঁ। আমি সব আমার টেবিল নাম PascalCase ঝোঁক

আমাদের পছন্দ:

  1. টেবিলের নাম বহুবচন হতে হবে?
    কখনও। এটির সংগ্রহের জন্য আর্গুমেন্টগুলি অর্থবহ করে তোলে তবে আপনি কখনই টেবিলে যাচ্ছেন তা আপনি জানেন না (0,1 বা অনেকগুলি আইটেম)। বহুবচন নিয়ম নামকরণ অযথা জটিল। 1 হাউস, ২ ঘর, মাউস বনাম মাউস, ব্যক্তি বনাম মানুষ, এবং আমরা অন্য কোনও ভাষাও দেখিনি।

    Update person set property = 'value' টেবিলের প্রতিটি ব্যক্তির উপর কাজ করে।
    Select * from person where person.name = 'Greg' ব্যক্তি সারির একটি সংগ্রহ / রোজেট প্রদান করে।

  2. কলাম নাম একক হতে হবে?
    সাধারণত, হ্যাঁ, যেখানে আপনি স্বাভাবিকীকরণ নিয়ম ভাঙ্গা হয় ছাড়া।

  3. আমি টেবিল বা কলাম উপসর্গ করা উচিত?
    বেশিরভাগ একটি প্ল্যাটফর্ম পছন্দ। আমরা টেবিল নামের সাথে কলাম উপসর্গ পছন্দ। আমরা টেবিলগুলি উপসর্গ করি না, তবে আমরা উপসর্গ দর্শনগুলি (v_) এবং সংরক্ষিত_প্রকল্পগুলি (sp_ বা f_ (ফাংশন)) করি। এটি এমন ব্যক্তিদের সাহায্য করে যারা উদযাপনের v_person.age চেষ্টা করতে চায় যা প্রকৃতপক্ষে একটি গণনাকৃত ক্ষেত্র (যা কোনওভাবে আপডেট করা যাবে না)।

    এটি কীওয়ার্ড সংঘর্ষ এড়াতে দুর্দান্ত উপায় (delivery.from breaks, but delivery_from হয় না)।

    এটি কোডটিকে আরও ক্রিয়াপদ করে তোলে, তবে প্রায়শই পাঠযোগ্যতার জন্য সহায়ক হয়।

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ... খুব পঠনযোগ্য এবং স্পষ্ট। যদিও হাত থেকে বেরিয়ে আসতে পারে:

    customer.customer_customer_type_id

    গ্রাহক এবং গ্রাহক-ধরন টেবিলের মধ্যে সম্পর্ককে নির্দেশ করে, গ্রাহক-ধরন টেবিলে (গ্রাহক_type_id) প্রাথমিক কী নির্দেশ করে এবং আপনি যদি কোনও প্রশ্ন ডিবাগ করার সময় 'customer_customer_type_id' দেখেন তবে আপনি তাৎক্ষণিকভাবে তা জানতে পারেন (গ্রাহক টেবিল)।

    অথবা যেখানে আপনি গ্রাহক_type এবং গ্রাহক_category মধ্যে একটি এমএম সম্পর্ক আছে (শুধুমাত্র নির্দিষ্ট ধরনের নির্দিষ্ট বিভাগে উপলব্ধ)

    customer_category_customer_type_id

    ... দীর্ঘ দিকে একটু (!)।

  4. আমি আইটেম নামকরণ কোনো ক্ষেত্রে ব্যবহার করা উচিত? হ্যাঁ - নিম্ন কেস :), underscores সঙ্গে। এই খুব পঠনযোগ্য এবং ক্রস প্ল্যাটফর্ম। একসঙ্গে 3 এর সাথে এটি জ্ঞান করে তোলে।

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


আমার মতে:

  1. টেবিল নাম বহুবচন হতে হবে।
  2. কলামের নাম একবচন হতে হবে।
  3. না।
  4. উভয় টেবিল নাম এবং কলামের নামগুলির জন্য CamelCase (আমার পছন্দের) বা underscore_ পৃথক।

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


আমি জানি এই গেমটি দেরি হয়ে গেছে, এবং প্রশ্নটি খুব ভালভাবে উত্তর দেওয়া হয়েছে, তবে আমি কলামের নামগুলির পূর্বরূপ সম্পর্কে # 3 এ আমার মতামত দিতে চাই।

সমস্ত কলামগুলি এমন একটি উপসর্গের সাথে নামকরণ করা উচিত যা টেবিলের জন্য আলাদা।

যেমন "গ্রাহক" এবং "ঠিকানা" দেওয়া টেবিল দেওয়া যাক, যথাক্রমে "কাস্ট" এবং "অ্যাড্র" এর উপসর্গগুলির সাথে যাই। "গ্রাহক" এর মধ্যে "cust_id", "cust_name" ইত্যাদি থাকবে। "ঠিকানা" এর মধ্যে "addr_id", "addr_cust_id" (FK ফিরে গ্রাহক), "addr_street" ইত্যাদি থাকবে।

যখন আমি প্রথম এই মান সঙ্গে উপস্থাপন করা হয়, আমি এটা বিরুদ্ধে মৃত সেট ছিল; আমি ধারণা ঘৃণা। আমি যে অতিরিক্ত টাইপিং এবং redundancy ধারণা স্ট্যান্ড করতে পারে না। এখন আমার কাছে যথেষ্ট অভিজ্ঞতা আছে যে আমি কখনো ফিরে যাব না।

এটি করার ফলাফল হল আপনার ডাটাবেসের স্কিমের সমস্ত কলাম অনন্য। এটির একটি প্রধান সুবিধা রয়েছে, যা এটির বিরুদ্ধে সমস্ত আর্গুমেন্টকে হ্রাস করে (আমার মতে, অবশ্যই):

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

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

আরেকটি, অপেক্ষাকৃত অপ্রাপ্তবয়স্ক সুবিধাটি হল যে আপনি নিজে যোগদান করার সময় কেবলমাত্র টেবিল-উপনামগুলি ব্যবহার করতে হবে:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

আমি তিনটি DBAs সহ একটি ডাটাবেস সহায়তা টিমতে কাজ করি এবং আমাদের বিবেচিত বিকল্পগুলি হল:

  1. কোন নামকরণ মান কোন মান চেয়ে ভাল।
  2. কোন "এক সত্য" মান আছে, আমরা সব আমাদের পছন্দ আছে
  3. ইতিমধ্যে ইতিমধ্যে মান আছে, এটি ব্যবহার করুন। অন্য স্ট্যান্ডার্ড তৈরি না বা বিদ্যমান স্ট্যান্ডার্ড muddy না।

আমরা টেবিল জন্য একবচন নাম ব্যবহার করুন। টেবিল সিস্টেমের নাম (অথবা তার আদ্যক্ষর) সঙ্গে prefixed করা ঝোঁক। সিস্টেমটি জটিল হিসাবে যদি আপনি যৌক্তিকভাবে টেবিলগুলিকে একত্রিত করতে উপসর্গটি পরিবর্তন করতে পারেন (যেমন reg_customer, reg_booking এবং regadmin_limits)।

ক্ষেত্রের জন্য আমরা ক্ষেত্রের নামগুলিতে টেবিলের উপসর্গ / অ্যাক্রিয়নম অন্তর্ভুক্ত করতে চাই (অর্থাৎ cust_address1) এবং আমরা প্রিক্সিক্সের একটি স্ট্যান্ডার্ড সেট (পিকেটার জন্য _id, "কোড" এর জন্য _cd, নামটির জন্য _nm) পছন্দ করতে পছন্দ করি "," সংখ্যা "জন্য _nb," তারিখ "এর জন্য _dt)।

Foriegn key ক্ষেত্রের নামটি প্রাথমিক কী ক্ষেত্রের মতো হওয়া উচিত।

অর্থাত

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

একটি নতুন প্রকল্প তৈরি করার সময়, আমি আপনাকে সমস্ত পছন্দের সত্তা নাম, উপসর্গ এবং acronyms লিখতে সুপারিশ এবং আপনার দস্তাবেজ এই নথি দিতে সুপারিশ। তারপরে, যখন তারা একটি নতুন টেবিল তৈরি করার সিদ্ধান্ত নেয়, তখন তারা "অনুমান" টেবিল এবং ক্ষেত্রগুলিকে কী বলা উচিত তার চেয়ে নথিতে উল্লেখ করতে পারে।


আমি মাইক্রোসফ্ট এর SQL সার্ভার নমুনা ডেটাবেস চেক আউট করার সুপারিশ: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

অ্যাডভেঞ্চারওয়ার্কস নমুনা ডাটাবেস অবজেক্টের সংস্থার জন্য স্কিমা নামগুলি ব্যবহার করে এমন একটি খুব স্পষ্ট এবং সামঞ্জস্যপূর্ণ নামকরণ কনভেনশন ব্যবহার করে।

  1. টেবিল জন্য একক নাম
  2. কলামের জন্য একক নাম
  3. টেবিল উপসর্গের জন্য স্কিমা নাম (উদাহরণ: SchemeName.TableName)
  4. পাস্কাল আবরণ (উর উপরের উটের ক্ষেত্রে)

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

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

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

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

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

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


এখানে উত্তর উত্তর, কিন্তু সংক্ষিপ্ত:

  1. আমার পছন্দ বহুবচন
  2. হাঁ
  3. টেবিল : * সাধারণত * কোন উপসর্গ সেরা। কলাম : না।
  4. উভয় টেবিল এবং কলাম: PascalCase।

বিবরণাদি:

(1) আপনি কি করতে হবে। খুব অল্প কিছু জিনিস আছে যা আপনাকে অবশ্যই নির্দিষ্টভাবে করতে হবে , কিন্তু কয়েকটি আছে।

  • "[SingularOfTableName] আইডি" বিন্যাস ব্যবহার করে আপনার প্রাথমিক কীগুলি নাম দিন। অর্থাৎ, আপনার টেবিল নাম গ্রাহক বা গ্রাহক কিনা, প্রাথমিক কীটি গ্রাহক আইডি হওয়া উচিত।
  • উপরন্তু, বিদেশী কীগুলি বিভিন্ন টেবিলে ধারাবাহিকভাবে নামকরণ করা উচিত । এটি করা না যারা কেউ বীট আইনি হতে হবে। নির্ধারিত বৈদেশিক কী সীমাবদ্ধতা প্রায়ই গুরুত্বপূর্ণ যখন আমি জমা দেব, সামঞ্জস্যপূর্ণ বিদেশী কী নামকরণ সবসময় গুরুত্বপূর্ণ
  • আপনি ডাটাবেস অভ্যন্তরীণ কনভেনশন থাকতে হবে। যদিও পরবর্তী বিভাগগুলিতে আপনি আমাকে খুব নমনীয় দেখবেন, একটি ডাটাবেস নামকরণের মধ্যে খুব সামঞ্জস্যপূর্ণ হতে হবে। গ্রাহকদের জন্য আপনার টেবিলটিকে গ্রাহক বা গ্রাহক বলা হয় কিনা তা একই ডেটাবেস জুড়ে একই ভাবে করা থেকে কম গুরুত্বপূর্ণ। এবং আপনি আন্ডারস্কোরগুলি কীভাবে ব্যবহার করবেন তা নির্ধারণ করতে একটি মুদ্রা ফ্লিপ করতে পারেন, তবে তারপরে আপনাকে অবশ্যই একইভাবে ব্যবহার করতে হবে । যদি আপনি এটি না করেন তবে আপনি এমন একজন খারাপ ব্যক্তি যিনি কম স্ব-সম্মান থাকা উচিত।

(2) আপনি সম্ভবত কি করতে হবে।

  • বিভিন্ন টেবিলের একই ধরনের তথ্য প্রতিনিধিত্বকারী ক্ষেত্রগুলিকে একই নাম দেওয়া উচিত । এক টেবিলের জিপ এবং অন্য কোনও জিপকোড নেই।
  • আপনার টেবিলে বা কলামের নামগুলি আলাদা করার জন্য, পাসস্কালকিং ব্যবহার করুন। CamelCasing ব্যবহার অভ্যন্তরীণভাবে সমস্যাযুক্ত হবে না, কিন্তু যে কনভেনশন না এবং এটা মজার দেখতে হবে। আমি একটি মুহূর্তে underscores ঠিকানা করব। (আপনি পুরানো দিনের মতো ALLCAPS ব্যবহার করতে পারবেন না। 20 বছর আগে DB2 তে OBNOXIOUSTABLE.ANNOYING_COLUMN ঠিক ছিল, কিন্তু এখন নয়।)
  • Artifically শব্দ ছোট বা সংক্ষিপ্ত না। নামটি ছোট এবং বিভ্রান্তিকর থেকে দীর্ঘ এবং পরিষ্কার হতে ভাল। আল্ট্রা-ছোট নামগুলি গাঢ়, বেশি বর্বর বার থেকে একটি হোল্ডওভার। Cus_AddRef। যে পৃথিবীতে কি হয়? কাস্টডিয়াল অ্যাড্রেসেস রেফারেন্স? গ্রাহক অতিরিক্ত রিফান্ড? কাস্টম ঠিকানা রেফারেল?

(3) আপনি কি বিবেচনা করা উচিত।

  • আমি সত্যিই আপনি টেবিল জন্য বহুবচন নাম থাকতে হবে মনে হয়; কিছু একক মনে। অন্যত্র আর্গুমেন্ট পড়ুন। কলামের নামগুলি একবচন হওয়া উচিত। এমনকি যদি আপনি বহুবচন টেবিল নামগুলি ব্যবহার করেন তবে টেবিলে সমন্বয়কারী টেবিলগুলি একবচন হতে পারে। উদাহরণস্বরূপ, যদি আপনার কাছে একটি প্রচার এবং একটি আইটেম টেবিল থাকে তবে একটি উত্স একটি প্রচারের অংশ হিসাবে উপস্থাপিত একটি আইটেমকে প্রচার_আইটিম হতে পারে, তবে এটি বৈধভাবে প্রচারের (আই-টু-রিলেশনকে প্রতিফলিত করে) ভাবতে পারে।
  • অবিচ্ছিন্নভাবে এবং একটি বিশেষ উদ্দেশ্যে underscores ব্যবহার করুন। শুধু সাধারণ টেবিল নাম PascalCasing সঙ্গে যথেষ্ট পরিষ্কার করা উচিত; আপনি শব্দ আলাদা করতে underscores প্রয়োজন হয় না। আন্ডারস্কোরগুলি সংরক্ষণ করুন (ক) কোনও অ্যাসোসিয়েটেবল টেবিল বা (খ) উপসর্গের জন্য, যা আমি পরবর্তী বুলেটে সম্বোধন করব।
  • Prefixing না ভাল বা খারাপ। এটা সাধারণত ভাল হয় না। আপনার প্রথম ডিবি বা দুটিতে, আমি সাধারণ থিম্যাটিক গোষ্ঠীগুলির টেবিলের জন্য উপসর্গগুলি ব্যবহার করার পরামর্শ দিই না। টেবিলগুলি আপনার বিভাগগুলিকে সহজে ফিট করা পর্যন্ত শেষ হয় না এবং এটি আসলে টেবিলগুলি খুঁজে পাওয়া কঠিন করে তুলতে পারে। অভিজ্ঞতার সাথে, আপনি একটি পূর্বনির্ধারিত প্রকল্প পরিকল্পনা এবং প্রয়োগ করতে পারেন যা ক্ষতির চেয়ে আরও ভাল। ডেটা টেবিলগুলি টিবিএল দিয়ে শুরু হয়েছিল , সিটিবিএলের সাথে কনফিগারেশন টেবিল, ভিউ, প্রস এর স্প , এবং udf এর fn এবং কয়েকটি অন্যদের সাথে দেখা হয়েছিল , আমি একটি ডিবিতে কাজ করেছি; এটি meticulously ছিল, ধারাবাহিকভাবে প্রয়োগ তাই এটি ঠিক আছে কাজ করে। যখন আপনি উপসর্গগুলির প্রয়োজন তখনই কেবলমাত্র যখন আপনার কাছে আলাদা সমাধান থাকে তবে কিছু কারণে এটি একই ডিবিতে থাকে; তাদের prefixing টেবিল গ্রুপে খুব সহায়ক হতে পারে। Prefixing বিশেষ পরিস্থিতিতে জন্য ঠিক আছে, যেমন আপনি অস্থায়ী টেবিল জন্য স্ট্যান্ড আউট করতে চান।
  • খুব কমই (যদি কখনও) আপনি কলাম উপসর্গ করতে চান।

এখানে একটি লিঙ্ক যা কয়েক পছন্দ প্রস্তাব। আমি একটি আংশিক সংজ্ঞায়িত এক উপর নির্ভর করার পরিবর্তে অনুসরণ করতে পারে একটি সহজ স্পেক জন্য অনুসন্ধান করা হয়।

http://justinsomnia.org/writings/naming_conventions.html


ঠিক আছে, যেহেতু আমরা মতামত দিয়ে ওজন করছি:

আমি বিশ্বাস করি যে টেবিল নাম বহুবচন হতে হবে। টেবিল একটি সত্তা একটি সংগ্রহ (একটি টেবিল) হয়। প্রতিটি সারি একটি একক সত্তা প্রতিনিধিত্ব করে, এবং টেবিল সংগ্রহ প্রতিনিধিত্ব করে। তাই আমি ব্যক্তি সংস্থাগুলির একটি টেবিল কল করব (বা ব্যক্তি, যা আপনার অভিনবতা নেয়)।

যারা প্রশ্নগুলিতে একক "সত্তা নামগুলি" দেখতে চান তাদের জন্য, আমি এর জন্য টেবিল উপনামগুলি ব্যবহার করব:

SELECT person.Name
FROM People person

লিনক এর মত কিছু "ব্যক্তি নির্বাচিত ব্যক্তির নাম।" থেকে।

2, 3 এবং 4 এর জন্য, আমি @Lars এর সাথে একমত।


নামকরণের কনভেনশনগুলি উন্নয়ন দলটিকে প্রকল্পের হৃদয়তে আবিষ্কারযোগ্যতা এবং রক্ষণাবেক্ষণের নকশা করতে দেয়।

একটি ভাল নামকরণ কনভেনশনটি সময় কাটানোর সময় নেয় তবে একবার এটি স্থানান্তরিত হওয়ার পরে এটি একটি সাধারণ ভাষা দিয়ে এগিয়ে যেতে পারে। একটি ভাল নামকরণ কনভেনশন প্রকল্প সঙ্গে organically বৃদ্ধি। একটি ভাল নামকরণ কনভেনশন সহজেই সফটওয়্যার লাইফ সাইকেলটির দীর্ঘতম এবং সবচেয়ে গুরুত্বপূর্ণ পর্যায়ে পরিবর্তনের সাথে প্রতিবন্ধকতা তৈরি করে - উৎপাদন পরিষেবা পরিষেবা।

এখানে আমার উত্তর আছে:

  1. হ্যাঁ, টেবিলের নামগুলি বহুবচন হওয়া উচিত যখন তারা বাণিজ্য , সিকিউরিটিজ বা কাউন্টারপারিজের একটি সেট উল্লেখ করে।
  2. হ্যাঁ।
  3. হ্যাঁ। এসকিউএল টেবিলগুলি tb_ দিয়ে prefixed হয়, ভিউগুলি prefixed vw_ হয়, সংরক্ষিত পদ্ধতিগুলি usp_ prefixed হয় এবং ট্রিগারগুলি tg_ prefixed হয় ডাটাবেসের নাম অনুসারে।
  4. কলামের নাম আন্ডারস্কোর দ্বারা আলাদা আলাদা হওয়া উচিত।

নামকরণ কঠিন কিন্তু প্রতিটি সংস্থায় এমন ব্যক্তি রয়েছে যে নামগুলি এবং প্রত্যেক সফ্টওয়্যার টিমের মধ্যে এমন নাম থাকতে পারে যে নামকরণের মানদণ্ডের দায় নেয় এবং sec_id , sec_value এবং security_id নামে নামকরণের সমস্যাগুলিকে প্রকল্পে বেকড হওয়ার আগেই সমাধান করা হয় তা নিশ্চিত করে। ।

সুতরাং একটি ভাল নামকরণ কনভেনশন এবং মান মৌলিক তত্ত্ব কি: -

  • আপনার ক্লায়েন্ট এবং আপনার সমাধান ডোমেইন ভাষা ব্যবহার করুন
  • বর্ণনামূলক হতে
  • সামঞ্জস্যপূর্ণ হতে
  • Disambiguate, প্রতিফলিত এবং refactor
  • সংক্ষেপে ব্যবহার করবেন না যতক্ষণ না তারা সবার কাছে স্পষ্ট
  • কলাম নাম হিসাবে এসকিউএল সংরক্ষিত কীওয়ার্ড ব্যবহার করবেন না

অপরিহার্য ডাটাবেস নামকরণ কনভেনশন (এবং স্টাইল) (আরো বিস্তারিত বিবরণের জন্য এখানে ক্লিক করুন)

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


সারণির নাম: এটি একবচন হওয়া উচিত, কারণ এটি একটি একক একক যা প্রকৃত বিশ্ব বস্তুকে প্রতিনিধিত্ব করে এবং বস্তু নয়, যা একক।

কলামের নাম: এটি শুধুমাত্র একক হওয়া উচিত তবে এটি একটি পারমাণবিক মান ধরে রাখবে এবং স্বাভাবিকীকরণ তত্ত্ব নিশ্চিত করবে। যাইহোক, একই ধরণের বৈশিষ্ট্যের সংখ্যা আছে, তাহলে তাদের 1, 2, ..., এন, ইত্যাদির সাথে সম্পৃক্ত হওয়া উচিত।

পূর্বরূপ টেবিল / কলাম: এটি একটি বিশাল বিষয়, পরে আলোচনা হবে।

আবরণ: এটি উটের ক্ষেত্রে হওয়া উচিত

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



--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

এইগুলি আমাকে শেখানো হয়েছিল যে কনভেনশনগুলি, কিন্তু আপনি পায়ের পাতার মোজাবিশেষ ব্যবহার বিকাশ যাই হোক না কেন আপনি মাপসই করা উচিত।

  1. বহুবচন। এটা সত্তা একটি সংগ্রহ।
  2. হ্যাঁ। বৈশিষ্ট্য একটি সত্তা একবচন সম্পত্তি একটি উপস্থাপনা।
  3. হ্যাঁ, প্রিফিক্স টেবিলের নামটি সহজেই সমস্ত সীমা সূচী এবং টেবিল উপনামগুলির ট্র্যাকযোগ্য নামকরণের অনুমতি দেয়।
  4. টেবিল এবং কলামের নামগুলির জন্য প্যাসকাল কেস, সূচী এবং সূচকের জন্য উপসর্গ + সমস্ত ক্যাপ।

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName




naming-conventions