লোকেরা কেন পরিচয় কলামের জন্য "আইডি" নামটি ব্যবহার না করার পরামর্শ দেয়?

68

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

আমি লোকেরা Idটেবিলের নামটি উপস্থাপনের পরামর্শ দিয়েছি , তবে এটি এসকিউএল কোয়েরিগুলি লিখেছেন (বা প্রোগ্রামার যদি আপনি সত্তা ফ্রেমওয়ার্কের মতো কোনও ওআরএম ব্যবহার করে থাকেন) বিশেষত দীর্ঘ টেবিলের নামগুলিতে যেমন আরও কাজ করে তবে মনে হয় CustomerProductIdঅথবাAgencyGroupAssignementId

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

তাহলে লোকেরা কেন Idপরিচয় কলামের জন্য নামটি ব্যবহার না করার পরামর্শ দেয় ?

সম্পাদনা: পরিষ্কার করার জন্য, আমি কোন নামকরণের কনভেনশনটি ব্যবহার করব বা অন্যের নামে একটি নামকরণ কনভেনশন ব্যবহার করার পক্ষে যুক্তি জিজ্ঞাসা করছি না। আমি কেবল এটি জানতে চাই কেন এটি Idপরিচয় কলামের নাম ব্যবহার না করার পরামর্শ দেওয়া হচ্ছে ।

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

identity naming-convention

— রেচেল
সূত্র

10

এখানে ইতিমধ্যে বিএফ বন্দুকযুদ্ধ: প্রোগ্রামার্স.সটাকেক্সচেঞ্জ / কিউ / ১১47৪২৪ / ৫৯০৫ আমাদের বেশিরভাগ (পড়ুন: আমাকে) এতে

— চুষে ফেলেছে

পরিচয় কলামের নাম হিসাবে "আইডি" ব্যবহার করার বিরুদ্ধে আসলেই কি কোনও নিয়ম রয়েছে? অ্যাক্টিভেকর্ড, রেল অন রুবেলের স্ট্যান্ডার্ড ওআরএম, এটি কনভেনশন করে। ar.rubyonrails.org

— 200_success

1

@ 200_সাক্সেস ডাটাবেস পর্যায়ে, হ্যাঁ। এই ডাটাবেস সাইটটি, ORM সাইট নয়;)

— JNK

2

এছাড়াও, এসকিউএল সার্ভার জন্য বিশেষভাবে দেখতে dba.stackexchange.com/questions/124655/... এবং, আরো নির্দিষ্টভাবে, connect.microsoft.com/SQLServer/feedback/details/2178150

— হারুন বারট্রান্ড

46

সারণী নামের উপসর্গটির খুব ভাল কারণ রয়েছে।

বিবেচনা:

TableA (id int identity, stringdata varchar(max))

TableB (id int identity, stringdata varchar(max))

আমরা উভয় সারণীতে বিদ্যমান রেকর্ডগুলি DELETEথেকে চাই TableA। যথেষ্ট সহজ, আমরা কেবল একটি কাজ করব INNER JOIN:

DELETE a
FROM 
  TableA A
INNER JOIN 
  TableB B
    ON b.id = B.id

.... এবং আমরা কেবল সমস্তটি মুছে ফেলেছি TableA। আমরা অজান্তেই বি এর আইডিটিকে নিজের সাথে তুলনা করি - প্রতিটি রেকর্ড মেলে এবং প্রতিটি রেকর্ড মুছে ফেলা হয়।

ক্ষেত্রগুলির নাম দেওয়া থাকলে TableAIdএবং TableBIdএটি অসম্ভব ( Invalid field name TableAid in TableB)।

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

এটি এটিকে খুব প্রকট করে তোলে যেখানে ক্ষেত্রগুলি প্রচুর JOINগুলি সহ দীর্ঘ প্রশ্নের মধ্যে আসে ।

— JNK
সূত্র

10

সুতরাং এটি মূলত ত্রুটিগুলি থেকে রক্ষা করার নামকরণের সম্মেলন? আমি মনে করি begin transactionএবং ব্যবহার করার commit transactionচেয়ে আরও ভাল অভ্যাস হবে (ইমো) আরও বেশি জঘন্য নামকরণের স্কিম

— রাচেল

13

@ রেচেল: এটি ১ স্পষ্টতার জন্য ২. অপ্রয়োজনীয় কলামের উপকরণ এড়িয়ে চলুন ৩. যোগ দিন..যাপনের অনুমতি দিন 4.. পিএইচপি বানরদের বিরক্ত করুন যারা একক বস্তুতে কাজ করেন, সেট নয়

— gbn

4

@ রাচেল যদি ক্যোয়ারী লেখার সময় আপনি ভুলটি লক্ষ্য করেন না এবং এটি সম্পাদন করার ঠিক আগে, এটি করার সম্ভাবনা কমই আপনি এটি করার আগে এটি লক্ষ্য করবেন। এই জিনিসগুলি ঘটে, কেন এটি আরও বেশি সম্ভাবনা তৈরি করে?

— অ্যান্ডি

7

@ অ্যান্ডি SELECTচালানোর আগে আমি আমার রেকর্ডগুলি সন্ধান করার জন্য সর্বদা চেষ্টা করি DELETEএবং একবার বিবৃতি চালানোর পরে আমি সর্বদা যাচাই করি যে প্রতিশ্রুতি দেওয়ার আগে সারি গণনাটি আমি প্রত্যাশা করি।

— রাহেল

5

@ রাচেল এটি আপনার পক্ষে কার্যকর এমন কিছু রয়েছে যা চমৎকার। আপনি কি সবাইকে তা করতে পারেন?

— অ্যান্ডি

36

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

এখন আপনার গ্রাহক আইডি গ্রাহক ঠিকানা থেকে রেফারেন্স করা প্রয়োজন। আপনি অবশ্যই কলাম আইডিটির নাম রাখতে পারবেন না, তাই আপনি গ্রাহক_ আইডির সাথে যান।

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

ON c.id = ca.id

উফফ, উচিত ছিল ON c.id = ca.customer_id। বা আরও ভাল, আপনার পরিচয় কলামগুলির বর্ণনামূলক নাম দিন, তাই এটি হতে পারে ON c.customer_id = ca.customer_id। তারপরে যদি আপনি দুর্ঘটনাক্রমে অন্য কোথাও ভুল সারণী উপন্যাসটি ব্যবহার করেন তবে গ্রাহক_আইডি সেই টেবিলের কোনও কলাম হবে না এবং খালি ফলাফল এবং পরবর্তী কোড স্কুইটিংয়ের পরিবর্তে আপনি একটি দুর্দান্ত সংকলন ত্রুটি পাবেন।

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

— DB2
সূত্র

27

সমস্ত প্রাথমিক কীগুলির জন্য একটি সাধারণ নাম ব্যবহার না করার জন্য কনভেনশন থেকে প্রাপ্ত সুবিধাগুলি সম্পর্কে সমস্ত উত্তরের সংক্ষিপ্তসার এখানে:

কম ভুল, কারণ পরিচয় ক্ষেত্রগুলির নাম একই থাকে না

আপনি ভুলভাবে B.Id = B.Idপরিবর্তে যোগদান করে এমন একটি ক্যোয়ারী লিখতে পারবেন না A.Id = B.Idকারণ পরিচয় ক্ষেত্রগুলি কখনই ঠিক একই নামকরণ করা হবে না।
পরিষ্কার কলামের নাম।

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

আপনি এখন লিখতে পারেন SELECT CustomerId, ProductIdএকটি ক্যোয়ারী যে যোগদান থেকে Customersসঙ্গে Productsপরিবর্তেSELECT Customer.Id as CustomerId, Products.Id as ProductId
JOIN..USINGসিনট্যাক্সের অনুমতি দেয়

আপনি Customer JOIN Products USING (CustomerId)পরিবর্তে বাক্য গঠন সহ টেবিলগুলিতে যোগদান করতে পারেনCustomer JOIN Products ON Customer.Id = Products.Id
কীগুলি অনুসন্ধানগুলিতে সন্ধান করা সহজ

আপনি যদি কোনও বৃহত সমাধানে কোনও গ্রাহকের পরিচয় ক্ষেত্রের সন্ধান করে থাকেন CustomerIdতবে অনুসন্ধান করা অনুসন্ধানের চেয়ে অনেক বেশি কার্যকরId

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

আপনি পরিচয় ক্ষেত্রগুলির জন্য অনন্য বা অভিন্ন কলামের নামগুলি ব্যবহার করা চয়ন করুন আপনার উপর নির্ভর করে, তবে আপনি যা চয়ন করেন তা নির্বিশেষে দয়া করে সামঞ্জস্য থাকুন :)

— রেচেল
সূত্র

12

সংযুক্ত প্রশ্ন থেকে আমার উত্তর অনুলিপি করতে:

এমন একটি পরিস্থিতি রয়েছে যেখানে প্রতিটি টেবিলে "আইডি" লাগানো সেরা ধারণা নয়: USINGমূলশব্দটি যদি এটি সমর্থন করে। আমরা এটি প্রায়শই মাইএসকিউএলে ব্যবহার করি।

উদাহরণস্বরূপ, যদি আপনার কাছে fooTableকলাম fooTableIdএবং barTableবিদেশী কী রয়েছে fooTableId, তবে আপনার প্রশ্নগুলি যেমন তৈরি করা যেতে পারে:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

এটি কেবল টাইপিং সংরক্ষণ করে না, তবে বিকল্পের তুলনায় অনেক বেশি পঠনযোগ্য:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

— Izkata
সূত্র

9

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

উদাহরণস্বরূপ, কোনও ব্লগের ডাটাবেসটি তার অস্বাভাবিক আকারে দেখতে পারে, যা লেখক_নাম নামটিতে অনন্য বাধা ধরে।

| Author_Nickname | Author_Email | Post_Title | Post_Body |
+-----------------+--------------+------------+-----------+
| dave            | dave@x.com   | Blah       | Bla bla   |
| dave            | dave@x.com   | Stuff      | I like    |
| sophie          | s@oph.ie     | Lorem      | Ipsum     |

এটি সাধারণকরণের ফলে দুটি টেবিল পাওয়া যাবে:

লেখক:

| Author_Nickname | Author_Email |
+-----------------+--------------+
| dave            | dave@x.com   |
| sophie          | s@oph.ie     |

পোস্ট

| Author_Nickname | Post_Title | Post_Body |
+-----------------+------------+-----------+
| dave            | Blah       | Bla bla   |
| dave            | Stuff      | I like    |
| sophie          | Lorem      | Ipsum     |

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

অনেক ক্ষেত্রে আসল ক্ষেত্রগুলিতে কোনও অনন্য বাধা থাকতে পারে না, সুতরাং এর পরিবর্তে একটি সংখ্যাসূচক কৃত্রিম ক্ষেত্রটি প্রাথমিক কী হিসাবে ব্যবহৃত হয়। এটি প্রতিটি কলামের নাম এখনও একটি একক ক্ষেত্রের প্রতিনিধিত্ব করে এমনটি সত্য পরিবর্তন করে না। Traditionalতিহ্যগত ডাটাবেস ডিজাইনে, পৃথক কলামের নামগুলি কী না হলেও একক ক্ষেত্রের সাথে সামঞ্জস্য করে। (যেমন, এক ব্যবহার করেন part.partname এবং client.clientname বদলে part.name এবং client.name )। এটি INNER JOIN ... USING <key>এবং NATURAL JOINসিনট্যাক্সগুলির অস্তিত্বের কারণ ।

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

— stilgar
সূত্র

7

তৃতীয় পক্ষের একজন বিক্রেতা যাঁরা আমাদের জন্য কিছু তৈরি করার জন্য ভাড়া নিয়েছিলেন তারা কেবল আইডি ব্যবহার এড়ানোর জন্য তাদের সমস্ত পরিচয় কলাম আইডেন্টের নাম দিয়েছে।

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

সেখানে একটি ভাল নিবন্ধ এর Drupal এর সাইটে SQL এর কোডিং নিয়মাবলী যে এই পরিস্থিতির জন্য একটি ভাল অনুশীলন ইঙ্গিত:

সম্ভাব্য নেমস্পেসের বিরোধগুলি রোধ করতে মডিউল নামের সাথে সারণির নামগুলি উপস্থাপন করা একটি ভাল অনুশীলন।

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

— হারুন
সূত্র

7

আমি আইডি এর পরিবর্তে আমার কলামগুলির গ্রাহক আইডি রাখি, তাই যখনই আমি টাইপ করি

FROM dbo.Customers AS c JOIN dbo.CustomerOrders AS o

এসকিউএল প্রম্পট অবিলম্বে নিম্নলিখিতটি প্রস্তাব করে

ON c.CustomerID = o.CustomerID

এটি আমার কয়েকটি কীস্ট্রোক সংরক্ষণ করে। তবুও আমি মনে করি নামকরণের সম্মেলনগুলি খুব সাবজেক্টিভ এবং যেমন আমার একরকম বা অন্য কোনও পক্ষে দৃ opinion় মতামত নেই।

— এ কে
সূত্র

5

আপনি একইভাবে আপনার সমস্ত ভারচার ক্ষেত্রের নাম "ইউজারটেক্সট" এবং "ইউজারটেক্সট 1" এর মতো না রাখেন বা আপনি "ইউজারডেট" এবং "ইউজারডেট 1" ব্যবহার করবেন না কেন।

সাধারণত যদি কোনও টেবিলে আপনার পরিচয় ক্ষেত্র থাকে তবে এটি আপনার প্রাথমিক কী। যদি উভয় টেবিলের প্রাথমিক কীটি আইডি থাকে তবে আপনি কীভাবে পিতামাতার টেবিলে একটি বিদেশী কী দিয়ে শিশু টেবিলটি তৈরি করবেন?

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

— DForck42
সূত্র

5

মূলত একই কারণে আপনি প্যারামিটার 1, পরামিতি 2 নামকরণ করেন না ... এটি সঠিক, তবে বর্ণনামূলক নয়। আপনি যদি টেবিলআইডিটি দেখেন তবে আপনি সম্ভবত নিরাপদে ধরে নিতে পারেন যে এটি টেবিলের জন্য কোনও পিকে রাখার জন্য ব্যবহৃত হয়েছে, প্রসঙ্গ নির্বিশেষে।

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

প্রসঙ্গত, আইডিকে কিছু টেবিলের প্রাথমিক কী হিসাবে ধরে নেওয়া যেতে পারে (আইডিটি গাইড না হওয়া পর্যন্ত চূড়ান্ত কার্যকর নয়) তবে আইডেন্ট আপনাকে (বা কমপক্ষে আমাকে) তাও জানায় না। আমি অবশেষে বুঝতে পারি যে আইডেন্ট পরিচয়ের জন্য স্বল্প (এক উপায় বা অন্য), তবে আমি যে সময়টি বের করেছিলাম তা নষ্ট হবে।

— jmoreno
সূত্র

3

একটি উপসর্গ ব্যবহার করুন যাতে প্রাথমিক কী এবং বিদেশী কী উভয় প্রসঙ্গে একই নাম ব্যবহার করা যায়, যাতে আপনি সম্পাদনা করতে পারেন natural join/ join ... using।

— DrPizza
সূত্র