কেন একটি টেবিলের প্রাথমিক কী কলাম "আইডি" নামকরণ খারাপ অভ্যাস হিসাবে বিবেচিত হয়? [বন্ধ]

209

আমার টি-স্কয়ার শিক্ষক আমাদের বলেছিলেন যে আমাদের পিকে কলামের নামকরণ "আইডি" কোনও আরও ব্যাখ্যা ছাড়াই খারাপ অভ্যাস হিসাবে বিবেচিত হয়।

কেন একটি টেবিলের পিকে কলাম "আইডি" নামকরণ খারাপ অভ্যাস হিসাবে বিবেচিত হয়?

sql  naming  tsql 
— জিন-ফিলিপ লেক্লার্ক
সূত্র
27
ঠিক আছে, এটি আসলে কোনও বিবরণ নয় এবং আইডির অর্থ "পরিচয়" যা খুব স্ব-বর্ণনামূলক। এটা আমার মতামত।
— জিন-ফিলিপ লেকলার্ক
49
আমি নিশ্চিত যে প্রচুর দোকান রয়েছে যা পিকে নাম হিসাবে আইডি ব্যবহার করে। আমি ব্যক্তিগতভাবে আমার নামকরণ কনভেনশন হিসাবে টেবিল আইডি ব্যবহার করি তবে আমি কাউকে এর সত্যিকারের উপায়টি বলি না। মনে হচ্ছে আপনার শিক্ষক কেবল তার মতামতকে বহুলভাবে গৃহীত সেরা অনুশীলন হিসাবে উপস্থাপনের চেষ্টা করছেন।
22
অবশ্যই খারাপ অভ্যাসের ধরণ যা খারাপ নয় that কথাটি ধারাবাহিক হওয়া। আপনি যদি আইডি ব্যবহার করেন তবে এটি সর্বত্র ব্যবহার করুন বা এটি ব্যবহার করবেন না।
— ডেডালনিক্স
57
আপনার একটি টেবিল আছে ... এটিকে লোক বলা হয়, এটি একটি কলাম পেয়েছে, আইডি বলা হয়, আপনি আইডিটি কী বলে মনে করেন? একটি গাড়ী? একটি নৌকা? ... না এটি পিপল আইড, এটাই। আমি মনে করি এটি কোনও খারাপ অভ্যাস নয় এবং পিকে কলামের আইড বাদে অন্য কোনও নামকরণ করা প্রয়োজন নয়।
— জিম
38
তাই শিক্ষক ক্লাসের সামনে এসে আপনাকে বলে যে এটি একটি কারণ ব্যতীত খারাপ অভ্যাস? এটি একটি শিক্ষকের জন্য আরও খারাপ অনুশীলন।
— জেফো

উত্তর:

247

আমি বেরিয়ে এসে এটি বলতে যাচ্ছি: এটি আসলেই খারাপ অভ্যাস নয় (এবং এটি হলেও এটি এটি খারাপ নয়)।

আপনি এই যুক্তিটি তৈরি করতে পারেন ( চাদ নির্দেশ করেছেন) যে এটি নীচের ক্যোয়ারির মতো ত্রুটিগুলি মাস্ক করতে পারে:

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

তবে আপনার টেবিলের নামের জন্য ক্ষুদ্র এলিয়াস ব্যবহার না করে সহজেই এটি প্রশমিত করা যায়:

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

3 বর্ণের সংক্ষিপ্তকরণগুলি সর্বদা ব্যবহারের অনুশীলনটি কলামের নামটি ব্যবহার করার চেয়ে আমার কাছে আরও খারাপ id। (বিন্দু হিসাবে কে: সংক্ষিপ্তসার carsসঙ্গে টেবিলের নাম কে আসলে সংক্ষিপ্ত করবে car? এর শেষটি কী করে?)

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

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

সম্পাদকগণের জন্য একটি দ্রষ্টব্য: এই ক্যোয়ারিতে ত্রুটিটি ইচ্ছাকৃত এবং একটি বিন্দু তৈরি করার জন্য ব্যবহৃত হচ্ছে। সম্পাদনার পূর্বে দয়া করে পুরো উত্তরটি পড়ুন।

— রিওয়াল্ক
সূত্র
1
@ চ্যাড, এটি এই বিষয়টির একটি উল্লেখ ছিল যে সেই নির্দিষ্ট প্রশ্নের মধ্যে আপনি টেবিলের নামগুলির জন্য এলিয়াসের জন্য 3 টি অক্ষর ব্যবহার করেছিলেন, এমনকি যখন এটি কোনও বুদ্ধিমান ছিল না ( cars-> Godশ্বরকে carধন্যবাদ - আপনি আমার আঙ্গুলগুলি সংরক্ষণ করেছিলেন)। এর মধ্যে খুব গভীরভাবে পড়বেন না।
— রিওয়ালক
3
আমার উরফের নামগুলির চেয়ে খারাপটি ছিল আমার বহুত্বের মিশ্রণ carsএবং manufacturer। একটি বহুবচন, অন্যটি নয়। লোকেরা যদি ডিবিতে বাছাই করতে চায় তবে এটিই খারাপ অভ্যাস যা বেছে নেওয়া উচিত।
— ক্যাফগিকে
3
আমি মনে করি এটি খারাপ অভ্যাস। স্পষ্টতই, খারাপ অভ্যাস যতদূর যায় তা ভয়ঙ্কর নয় .. তবে এড়ানো এত সহজ, কেন এমন করবেন না? এখন, আমি সম্মত হচ্ছি, একটি অন্তর্ভুক্ত শ্রেণীর জন্য, এই বিষয়টির দিকে কি মনোযোগ দেওয়া উচিত? সম্ভবত তা নয় ....
— ব্যবহারকারী 606723
2
@ ব্যবহারকারী 606723, আসলে, আমি মনে করি একটি ইন্ট্রো ক্লাসের জন্য এটি একটি গুরুত্বপূর্ণ বিষয়। সেরা অনুশীলন শেখানো মৌলিক হওয়া উচিত। আপনি পরিণতি এবং ট্রেড অফগুলি বুঝতে পেরেছেন এবং সর্বোত্তম অনুশীলনগুলি থেকে নিজেকে বিচ্যুত করার আগেই আপনি অভিজ্ঞ না হয়ে থাকেন।
— ক্যাফগিকে
5
@ চাদ, একমত পোষন করতে রাজি সেগুলি কেন সর্বোত্তম অনুশীলন তা অনুধাবন না করে শিক্ষার্থীদের "সেরা অনুশীলন" শেখানোর চেষ্টা করা নিরর্থক প্রচেষ্টা। এবং যেহেতু আপনি সমস্ত কিছু কভার করতে পারবেন না, "আপনাকে কেবল এটি করা উচিত নয়, আপনি এই কারণেই বুঝতে পারবেন যে পরে কেন" প্রফেসরের দৃষ্টিকোণ থেকে বেশ বুদ্ধিমান পছন্দ। কৌতূহলী শিক্ষার্থীরা এখানে পোস্ট করতে পারে বা আশা করা যায় যে এই প্রশ্নের উত্তর ইতিমধ্যে উত্তর পেয়েছে। (বা শ্রেণীর পরে জিজ্ঞাসা করুন)
— ব্যবহারকারী 606723
123

কারণ যখন আপনার কাছে একটি বিদেশী কী সহ কোনও টেবিল থাকে আপনি সেই বিদেশী কী "আইডির" নাম রাখতে পারবেন না। আপনার টেবিলের নাম এটি টেবিলআইডি রয়েছে

এবং তারপরে আপনার যোগদানের মতো দেখাচ্ছে

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

এবং আদর্শভাবে, আপনার অবস্থার প্রতিটি পক্ষের একই ক্ষেত্রের নাম হওয়া উচিত

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

সুতরাং আইডিটির নাম উত্পাদনকারক হিসাবে রাখা অপ্রয়োজনীয় মনে হলেও ভুলগুলি সুস্পষ্ট হয়ে যাওয়ার কারণে আপনার যোগদানের শর্তে আপনার ত্রুটি রয়েছে less

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

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

যথাযথ নামকরণের সাথে সাথে ত্রুটিটি আটকে যায় ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

তাদের "আইডি" নামকরণের আরেকটি কারণ হ'ল আপনি যখন বেশ কয়েকটি টেবিল থেকে তথ্যের জন্য জিজ্ঞাসা করছেন তখন আপনাকে আইডি কলামগুলির নাম পরিবর্তন করতে হবে যাতে আপনি তাদের আলাদা করতে পারেন।

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

সঠিক নাম সহ এটি কোনও সমস্যা কম

— রেভস ক্যাফগিকে
সূত্র
174
নিশ্চিত না যে এটি আমার পক্ষে যথেষ্ট ভাল ব্যাখ্যা। বলার কিছু নেই SELECT * FROM cars c JOIN manufacturer m ON manufacturer.Id = c.ManufacturerId। আমি idবছরের পর বছর ধরে ব্যবহার করেছি এবং আপনি যা সত্যই সমস্যা হিসাবে বর্ণনা করেছেন তা কখনও পাইনি।
— রিওয়ালক
61
আমি বলব যে এখানে খারাপ অভ্যাসটি এমএফজি বা মোডের মতো নামের সাথে থাকা টেবিলগুলি। প্রস্তুতকারক.আইডি = গাড়ি.মানুচার্ড_আইডি খুব পঠনযোগ্য এবং ত্রুটিটিও আটকে থাকবে।
— ডেডালনিক্স
5
@ চ্যাড> আমি ইতিমধ্যে বোবা ভেরিয়েবলের নাম নিয়ে সমস্যা পেয়েছি। অনেক বার. রেকর্ডার জন্য, আমি এখানে এমন কোনও দেবকে কী বলব যা এটি আমার দলে does এমএফজি করে এটি নির্মাতাকে বোঝায় না, এর অর্থ আপনি নির্মাতা type টাইপ করতে অলস হন »
— ডেডালনিক্স
9
@ স্টারগাজার 12১২: 2 টি টেবিল থেকে নির্বাচন করুন * 2 এক্স আইডি কলাম দেয়। আইডি এখন অস্পষ্ট: আপনারা অর্ডিনাল বা নাম দিয়ে রেফারেন্স করেন? নির্বাচন করুন * ভাল অনুশীলন না। দুর্বল যুক্তি। ভঙ্গুর কোড। চাদ সঠিক: মূলত ডিফেন্সিভ কোডিং
— gbn
6
@ জিবিএন, আবারও, আপনি যদি সহজভাবে করেন তবে সমস্ত অস্পষ্টতা দূর হয়ে যায় SELECT manufacturer.id FROM ...। ফলে প্রাপ্ত প্রতিটি অসুবিধা idখুব সহজেই কাটিয়ে উঠতে পারে, এটি কেবল স্বাদের বিষয় হিসাবে।
— রিওয়ালক
66

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

— কেভিন ক্লাইন
সূত্র
30
"আরও পড়ার জন্য ক্লান্তিকর" জন্য +1। - নামকরণের কনভেনশনগুলি মড়াল কোডের জন্য ব্যান্ড-সহায়তা হিসাবে ভাবা উচিত নয়, তাদের প্রাথমিক উদ্বেগ হিসাবে পঠনযোগ্যতা উন্নত করা উচিত।
— অক্টোডো
12
আইডি পড়তে আরও ক্লান্তিযুক্ত
— এইচএলজিইএম
5
@ এইচএলজিইএম: টেবিলের নাম সহ যে কেউ কলামের নামটি সর্বদা যোগ্যতা অর্জন করতে পারে।
— কেভিন cline
2
আমি পড়ার জন্য আরও ক্লান্তিকর ছাড়া রাজি হব। আমি আসলে আরও বর্ণনামূলক কলামের নামগুলি পড়া এবং সেই কলামটি আসলে কী তা খুঁজে বের করার জন্য কম সময় ব্যয় করতে পছন্দ করি।
— ডেভিন ডিকসন
2
+1, পোস্ট.পোস্টআইডি, পোস্টস.পোস্টনামের মতো কলামগুলির সাথে ঘৃণ্য সারণী দেখার জন্য যেখানে কেবল পোস্ট.ইড এবং পোস্ট.নাম ব্যবহার করা খুব সুন্দর।
— ডগ
40

"নাম" বা "আইডি" এর মতো সাধারণ বা মূল কলামের নামগুলি টেবিলনামের সাথে উপসর্গ করা উচিত।

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

কম ব্যবহৃত বা নিরীক্ষণ কলাম বা নন-কী (লাস্টআপডেটডেটটাইম বলুন) তাতে কিছু আসে যায় না

— gbn
সূত্র
57
আপনি যদি এটি করেন তবে আমাকে অতিরিক্ত টাইপিং করানোর জন্য আমি আপনাকে ঘৃণা করি !!!! টেবিলটির নাম ব্যক্তি, আপনি কী ভাবেন আইডিটি হতে চলেছে? কার? না, এটা ব্যক্তি।
— জিম
16
@ জিম, আমি আপনার সম্পর্কে জানিনা, তবে অতিরিক্ত 6 টি অক্ষর টাইপ করতে আমার প্রায় অর্ধেক সেকেন্ড সময় লাগে। এবং বিবেচনা করে আমি খুব কমই একটি টেবিল থেকে নির্বাচন করেছি, এবং এভাবে 'আইডি' নামের দুটি কলাম দিয়ে শেষ হবে এবং টেবিল / ওরফে নামটি কোনওভাবে অন্তর্ভুক্ত করতে হবে, টাইপ করা অক্ষরের সংখ্যাতে কোনও সঞ্চয় নেই।
— ক্যাফগিকে
21
@ চাদ আমি এটিকে অতিমাত্রায় খুঁজে পাই। আমি যদি একটি যোগদান করছি, c.id = মি। ম্যানুয়্যারচার্ড, আমার সাথে ঠিক আছে। এই কলামগুলি কোনওভাবে কোনও শ্রেণিতে সাধারণত "ম্যাপ করা" থাকে এবং ব্যক্তির সাথে একটি ক্লাস করা হয় ers পার্সনআইডি আমাকে বমি করতে চায় Yes হ্যাঁ, আমি সমস্যাগুলি সম্পর্কে সম্পূর্ণ সচেতন।
— জিম
20
আমিও এর সাথে একমত নই। কেন থামবে nameএবং id? কেন প্রতিটি কলামটি তার টেবিলের নামের সাথে উপসর্গ করা হয়নি? একটি উপসর্গ আদেশ করার জন্য এই দুটি নাম বাছাই করা স্বেচ্ছাচারী বলে মনে হচ্ছে। ধারণামূলকভাবে, যাইহোক কোনও কলামের প্রসঙ্গ থাকতে আপনার অবশ্যই টেবিলটি থাকা উচিত। কেন কেবল এই টেবিলের নামটি ক্যোয়ারীটি পরিষ্কার করতে ব্যবহার করবেন না: পার্সন.নাম, এনিমেল.নাম, পার্ট.নাম, ...
— থমাস
11
@ বিল লিপার, ডিআরওয়াই ডেটাবেস বিকাশে সর্বদা উপযুক্ত নয়। ডাটাবেসগুলিতে যা গুরুত্বপূর্ণ তা হল পারফরম্যান্স এবং ডেটাবেস তৈরি করা ফুলফিল ডিআরওয়ান নীতিগুলিতে অতিরিক্ত কাজ করে (যেমন স্কেলার ফাংশন বা ভিউগুলি কল করে এমন ভিউ বা কোয়েরি দেখায় যা প্রচুর কলাম ফিরে আসে বা একটি কার্সার ব্যবহার করে একটি বিদ্যমান প্রকর ব্যবহার করতে 1000000 রেকর্ড যুক্ত করতে পারে) প্রায়শই contraindicated হয়। অবজেক্ট-ওরিয়েন্টেড বিশ্বে যে কোনও কিছু ভাল, কারণ এটি ডাটাবেস ডিজাইনে উপযুক্ত is আপনার ডাউনভোটটি অনুপযুক্ত ছিল। আইডি ব্যবহার করা একটি পরিচিত এসকিউএল অ্যান্টিপেট্টার tern
— এইচএলজিইএম
31

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

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

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

— রেভ ব্যবহারকারীর 23157
সূত্র
2
যদি কেবলমাত্র আপনার প্রাথমিক কী কোনও যৌগিক কী না হয়, যা দুর্ভাগ্যক্রমে, খুব বেশি ক্ষেত্রে ঘটে। একটি বিশেষ পরিস্থিতিতে শুধুমাত্র সরোগেট কী ব্যবহার করা উচিত।
— নিকোডেমাস 13
6
আইডির মতো ব্যবহার করে আপনি এমন পরিস্থিতি শেষ করেন যেখানে বিকাশকারীরা তাদের তৈরি প্রতিটি টেবিলে প্রাথমিক কী আইডি যুক্ত করে। রিলেশনাল ডাটাবেসের অন্যতম ভিত্তি হ'ল অর্থবহুল এবং সমষ্টিগত প্রাথমিক কীগুলি ব্যবহার করা এবং আইডি ব্যবহার করা কোনও উপকারে আসে না।
— পিটার বি
এই উত্তরটি দেখে মনে হচ্ছে আপনি মতামত যুক্তি দিয়ে "আমি আইডি পছন্দ করি" বলছি। আপনার যুক্তিটি হ'ল আপনি তাত্ক্ষণিকভাবে আইডি নামক একটিটিকে সন্ধান করে কোন কীটি প্রাথমিক কী তা তাত্ক্ষণিকভাবে দেখতে পারবেন। ঠিক আছে, এটি টেবিলআইডির সাথে হুবহু একই । আমি আপনাকে গ্যারান্টি দিতে পারি আমি কোনটিই মূল কীটি কোনটি বিভ্রান্ত হই না get আমি কেবল আইডিটির আগে টেবিলের নামটি পেয়েছি। শুধু তা-ই নয়, যেখানে প্রথম কলামটি প্রাথমিক কী নয় সেখানে আপনি কী ধরণের টেবিলগুলি নিয়ে কাজ করছেন? আমি এই উত্তরে আপনার সমস্ত যুক্তিগুলি নিখুঁতভাবে পছন্দসই ভিত্তিক এবং "টেবিল আইডি আমার কাছে খারাপ লাগছে" এর মতো বলে মনে হচ্ছে।
— ডালিন
@ ডালিন সমস্ত উত্তর মতামতযুক্ত, অন্যথায় কেউ কেবল সরকারী মানের সাথে লিঙ্ক করবে, এবং একটি নেই!
— জেমস
@ জেমস আমি মনে করি স্ট্যাকএক্সচেঞ্জ সাইটের লক্ষ্য মতামত উত্তর হ্রাস করা। এ কারণেই প্রশ্নগুলি খুব বেশি মতামতযুক্ত হয়ে বন্ধ হয়ে যায়। মঞ্জুর, এই ধরণের প্রশ্নটি কেন বন্ধ হয়ে গেল বলে আমি মনে করি - কারণ এটি মতামত উত্তরগুলি প্রকাশ করে, তবে আমি অনুভব করি যে এই নির্দিষ্ট উত্তরটি সত্য ভিত্তিক কোন তথ্য বা তর্কের ভিত্তিতে যুক্তি ছাড়াই অত্যধিক মতামতযুক্ত ছিল। আমার মতামত, আপনার আইডি ব্যবহার করা উচিত, কারণ এটি আমার পছন্দ। এটি কোনও মূল্যবান উত্তর নয়।
— ডালিন
24

আমি এটাকে খারাপ অভ্যাস বলে বিবেচনা করি না। ধারাবাহিকতা যথারীতি রাজা।

আমি মনে করি এটি সমস্ত প্রসঙ্গে। নিজস্ব টেবিলে প্রসঙ্গে "আইডি" এর অর্থ হ'ল আপনি যা প্রত্যাশা করেন ঠিক তার অর্থ অন্যদের বিরুদ্ধে এটি অনন্যভাবে সনাক্ত করতে সহায়তা করার জন্য একটি লেবেল যা অন্যথায় অভিন্ন (বা উপস্থিত হতে পারে) হতে পারে।

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

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

— lotsoffreetime
সূত্র
5
রিলেশনাল ডাটাবেস টেবিলগুলি ক্লাস নয় ।
— অ্যাডাম রবিনসন
1
এগুলি তবে ডেটা স্ট্রাকচার এবং সেগুলি পিওডো ক্লাসগুলির সাথে সমান। নামকরণের একই সমস্যাগুলি প্রযোজ্য।
— অক্টোডো
4
@ স্লোমোজো: না, তারা সাধারণ বস্তুর সাথে সাদৃশ্য নয়। অবজেক্ট-ওরিয়েন্টেড ডিজাইন এবং ডাটাবেস ডিজাইন এক নয় এবং এমনকি সম্পর্কিত নয়। যদিও তারা কিছু ক্ষেত্রে একই রকম (বা এমনকি একই) নকশার ফলন করতে পারে, এটি তাদের সম্পর্কিত কিনা তা বোঝায় না। উদাহরণস্বরূপ, মি: মি সম্পর্কগুলি ক্লাসে তুচ্ছ, তবে তৃতীয় সংযুক্তি টেবিল ছাড়াই দুটি টেবিলের মধ্যে থাকা অসম্ভব।
— অ্যাডাম রবিনসন
1
এই নামকরণ কৌশলটির সাথে কীভাবে সম্পর্কিত, আমি জানি না। আমার উপমাটি (স্পষ্টভাবে?) কেবলমাত্র সেই পরিমাণে বিস্তৃত।
— অক্টোডো
2
আমি দুঃখিত আমার বোঝানো অর্থ খুব স্পষ্ট ছিল না, আমার " এই অর্থে তারা ক্লাসের সাথে সাদৃশ্যপূর্ণ " বলেছিলেন । যেভাবেই হোক, আমি মনে করি না যে এটি সম্পর্কে অত্যধিক পেডেন্টিক হওয়া বিশেষভাবে গঠনমূলক। নামকরণের ক্ষেত্রে, সারণী এবং শ্রেণিগুলিতে উল্লেখযোগ্য পরিমাণে মিল রয়েছে। সিল-ডি-স্যাকের বিকাশকারী সেরা অনুশীলনগুলি সংশোধন করার জন্য উপযুক্ত খেলা বা খুব কমপক্ষে আলোচনার জন্য উন্মুক্ত। এই প্রশ্নোত্তরের মধ্যে প্রচুর রয়েছে যা এটিকে কার্যকরভাবে চিত্রিত করে, আমার কাছে যোগ করার মতো নোটের আর কিছু নেই।
— অক্টোডো
24

ডেটা.স্ট্যাকেক্সেঞ্জ ডটকম থেকে

পোস্টগুলিতে আইডি

বুম, প্রশ্নের উত্তর।
এখন আপনার শিক্ষককে যান যে খারাপ ডাটাবেস ডিজাইনের অনুশীলন করুন

— সিরিল গ্যান্ডন
সূত্র
8
FKs আমার অনুমান, নাম উপর ভিত্তি করে: PostTypeId -> PostTypes.Id; AcceptedAnswerId -> Answers.Id; OwnerUserId -> Users.Id। এমন একটি অনুশীলনকে কেন 'খারাপ' বলে বিবেচনা করা উচিত?
— শোয়ার্ড
3
এটি সর্বোত্তম অনুশীলন সম্পর্কে ঠিক কীভাবে প্রমাণ করে?
— জিবিএ
5
কিছু স্ট্যাক ব্যবহার করা হয় বা না তা ভাল বা খারাপ অনুশীলন কিনা তা প্রমাণ করে না।
— পিটার বি
2
এটি যা প্রমাণ করে তা হ'ল এই অনুশীলন কোনওভাবেই কোনও অ্যাপ্লিকেশনটির স্কেলাবিলিটি এবং উপযোগিতা নিষিদ্ধ করে।
— সাইফার
1
আসলে এসও অনুশীলন নিখুঁত নয়। আমি এই নামকরণটি ব্যবহার করব: পোস্টটাইপ -> পোস্টটাইপ.আইডি; AcceptedAnswer -> উত্তর.আইডি; OwnerUser -> User.Id
— alpav
17

এটি টেবিলে প্রাকৃতিক যোগদান করতে শক্ত (এবং বিভ্রান্তিকর) করে তোলে, তাই হ্যাঁ, খুব খারাপ না হলে এটি খারাপ।

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

ঠিক আছে, আপনি যদি আপনার সমস্ত প্রাথমিক কী এর আইডি নামকরণ করেন তবে আপনি প্রাকৃতিক যোগদানের স্বাচ্ছন্দ্য এবং সরলতা হারাবেন। select * from dudes natural join carsলিখতে হবে select * from dudes inner join cars where cars.dudeid = dudes.idবা select * from dudes inner join cars where dudes.carid = cars.id। আপনি যদি প্রাকৃতিক যোগদান করতে সক্ষম হন তবে সম্পর্কটি আসলে কী তা আপনি এড়িয়ে যাবেন, যা আমি বিশ্বাস করি যে এটি দুর্দান্ত।

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

এমন একটি পরিস্থিতি রয়েছে যেখানে প্রতিটি টেবিলে "আইডি" লাগানো সেরা ধারণা নয়: 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
সূত্র
এই উত্তরটি আমার জন্য সবচেয়ে বেশি টিকে আছে। USINGশব্দ postgres / MySQL / SQLite ডাটাবেস দ্বারা সমর্থিত হয়, কম টাইপিং যা ব্যবহার করার জন্য একটি কারণ হিসাবে অন্যান্য উত্তর তালিকার কিছু মানে id, এবং পরিশেষে আমার বিষয়ী মতামত আরও পাঠযোগ্য।
— মাইকেল বার্টন
11

কেন শুধু আপনার শিক্ষককে জিজ্ঞাসা করবেন না?

এটি সম্পর্কে চিন্তা করুন, যখন আপনার সমস্ত টেবিলের পিকে কলামগুলির নাম দেওয়া হয় IDএটি বিদেশী কী হিসাবে তাদের দুঃস্বপ্নের সাহায্যে ব্যবহার করে।

কলামের নামগুলি শব্দার্থগতভাবে তাৎপর্যপূর্ণ হওয়া দরকার। IDজেনেরিক হয়।

— রেভস , 2 জন ব্যবহারকারী 80% ব্যবহারকারী 7519
সূত্র
8
কি জেনেরিক জন্য? একটি টেবিলের আইডি?
— জিম
3
@ জিম কোন টেবিলের? idএকাকী কিছু বোঝায় না, বিশেষত অন্য টেবিলে বিদেশী কী প্রসঙ্গে। এর সাথে কিছু করার নেই classesএবং ভাল বুনিয়াদি মৌলিক সম্পর্কযুক্ত ডাটাবেস ডিজাইনের সাথে করার মতো সমস্ত কিছুই ।
10
কিছুটা চর্বিযুক্ত হতে, এটি যে টেবিলের সাথে সম্পর্কিত। ক্ষেত্রের table.idউল্লেখ করার idক্ষেত্রে এটি একটি গ্রহণযোগ্য উপায় । সারণীর নামের সাথে ক্ষেত্রের নামটি উপস্থাপন করা অপ্রয়োজনীয়।
— অক্টোডো
2
@ স্লোমোজ এটি কলামের নাম অন্তর্ভুক্ত করা ছাড়া আর টাইপিংয়ের চেয়ে বেশি নয় যখন দৈত্যের সাথে একক বা ডাবল বর্ণের সংক্ষিপ্তসারগুলিতে টেবিলের নামগুলি অ্যালিজ করে।
6
কোন দুঃস্বপ্নের কথা আপনি উল্লেখ করছেন? ধরুন আপনার কাছে কর্মীদের একটি স্ব-রেফারেন্সিং কাঠামো রয়েছে যার সাথে তাদের পরিচালকের প্রতিনিধিত্বকারী একটি কলাম রয়েছে। বিদেশী কী বলে? আপনি এটিকে এমপ্লয়আইড বলতে পারেন না কারণ এটি সম্ভবত আপনার পিকে। এফকে নামটি পিকে-র সাথে মেলে না। এটি এতে থাকা সত্তাকে কী প্রতিনিধিত্ব করে তার নামকরণ করা উচিত।
— থমাস
7

নিম্নলিখিত কারণে আইডি খারাপ:

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

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

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

— এইচএলজিইএম
সূত্র
+1: এগুলি আমার মতে বাধ্যতামূলক কারণ, অন্য বিরোধী উত্তরগুলি IDআমাকে মোটেও বোঝায় না।
— ফুগ
পুনরায়: "যদি আপনি একটি জটিল কোয়েরি তৈরি করতে অনুলিপি করছেন তবে" তাই আপনার সমস্যাটি অনুলিপি করুন এবং পেস্ট করুন। অনুলিপি এবং পেস্ট বন্ধ করুন এবং আপনি দেখতে পাবেন গাড়ী.আইড নামকরণ কতটা সুবিধাজনক। এফ কে যোগদানের জন্য car.mfg = mfg.id, car.color = color.id, car.model = Model.id ব্যবহার করুন - খুব সহজ এবং আপনি লিনিক-এ কী লিখবেন তা মেলে।
— alpav
30 টিতে যোগ দিয়ে কিছু লেখার চেষ্টা করুন এবং আপনি দেখতে পাবেন এটি কেন অ্যান্টিপ্যাটার্ন।
— এইচএলজিইএম
এলিয়াসিং হ'ল প্রথম এবং সর্বাগ্রে কারণ - বড় জটিল রিপোর্টগুলি করার সময় এ জাতীয় মাথাব্যথা হয়। প্রাকৃতিক যোগদান শুধুমাত্র একটি মিষ্টি বোনাস। অন্যান্য উত্তরগুলি কীভাবে এই পয়েন্টগুলি উপেক্ষা করে তা অবাক করে দেয় amazing আমি মনে করি কিছু উদাহরণ যুক্ত করা পয়েন্টটি আরও পরিষ্কার করবে এবং এই উত্তরটি যেখানে হওয়া উচিত সেখানে উঁচু হবে।
— লুলু
5

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

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

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

হ্যাঁ, এর অনেক কিছুই "আইডি" থাকা এবং এটি সর্বদা "টেবিলনামআইডি" হিসাবে ব্যবহার করা জেনার স্ট্যান্ডার্ড দ্বারা অর্জন করা যেতে পারে, তবে এর অনুশীলনটি ঠিক আছে এবং মূল বিকাশকারীদের উপর নির্ভর করে কিছুটা কম করে অনুসরণ করতে হবে উভয়েরই প্রয়োজন requires স্বজ্ঞাত মান অনুশীলন।

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

কয়েকশো টেবিল সহ বড় প্রকল্পগুলি বজায় রাখতে বেশ কয়েক বছর ব্যয় করেছেন এমন কেউ হিসাবে, আমি সারণীগুলির জুড়ে একটি কীটির জন্য দৃ consistent়সংখ্যক নাম পছন্দ করব।

— মালাখি
সূত্র
ধরুন কোনও Companiesটেবিলের একটি টেবিলের কাছে দুটি বিদেশী কী Personsরয়েছে। একজন কোম্পানির রাষ্ট্রপতির প্রতিনিধিত্ব করেন; অন্যটি কোম্পানির ট্রেজারার উপস্থাপন করে। আপনি কি সত্যিই কলামগুলিতে কল করবেন PersonID1এবং PersonID2? তাদের কল করা PresidentIDএবং আরও অনেক বেশি বর্ণনামূলক হবে TreasurerID। আমি পড়তে খুব সহজ inner join Person AS Presidents ON Company.PresidentID = Presidents.IDমনে করিinner join Person AS Person1 ON Company.PersonID1 = Person1.PersonID
— ফুগ
1
না। আপনার উদাহরণে আমার সম্ভবত একটি CompanyOfficerবা CompanyPersonটেবিল থাকবে যা সম্পর্কের প্রকৃতি সম্পর্কে অতিরিক্ত তথ্যের সাথে Companyএবং এর Personসাথে অনেকগুলি থেকে বহু সম্পর্কের মঞ্জুরি দেয় । যদি আমি মধ্যে তা বাস্তবায়ন ছিল Companyটেবিল, আমি কলাম নামে ব্যবহার করেন PresidentPersonIDএবং TreasurerPersonIDযখন অতিরিক্ত বর্ণনাকারী যোগ * PersonID নামের অংশ সংরক্ষণ করা। inner join Person as Presidents on Company.PresidentPersonID = Presidents.PersonID
— মালাচি
5

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

এবং এজন্য আইডি ব্যবহার করা খারাপ অভ্যাস: আইডি হ'ল তথ্য কেবল একটি স্বতঃসংশোধন নয়।

নিম্নলিখিত সারণি বিবেচনা করুন:

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

এই টেবিলটিতে যা ভুল তা হ'ল এটি ব্যবহারকারীকে অন্য একটি লাইন যুক্ত করতে সক্ষম করে: মার্কিন যুক্তরাষ্ট্র, দেশকোড 840 দিয়ে। অবশ্যই আপনি স্বতন্ত্র কলামগুলিতে স্বতন্ত্রতা প্রয়োগ করতে পারেন বা আপনি ইতিমধ্যে উপলব্ধ একটি প্রাথমিক কী ব্যবহার করতে পারেন:

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

এইভাবে আপনি আপনার কাছে ইতিমধ্যে থাকা প্রাথমিক কী হিসাবে তথ্যটি ব্যবহার করেন যা সম্পর্কিত ডেটাবেস ডিজাইনের কেন্দ্রস্থলে।

— পিটার বি
সূত্র
1
আপনি বুঝতে পারবেন যে লোকেরা কেন প্রতিটি টেবিলে জেনেরিক কী কলামটি যুক্ত করে যখন আপনাকে ভিন্ন সিস্টেমের মধ্যে ডেটাবেসগুলি স্থানান্তর করতে হয়েছিল বা ডাটাবেসগুলি একত্রে মার্জ করার আনন্দ পেয়েছিল।
— সাইফার
1
এটি মাঝেমধ্যে ক্ষেত্রে হয় তবে আমার অভিজ্ঞতায় একটি দুর্দান্ত অনন্য অপরিবর্তনীয় কী থাকা খুব অস্বাভাবিক। এমনকি আপনার উদাহরণে দেশগুলি সনাক্ত করার জন্য আপনার কাছে অর্থহীন অনন্য সংখ্যা রয়েছে, কেবলমাত্র একটি যা আপনার ডেটাবেস দ্বারা নয় আইএসও দ্বারা বরাদ্দ।
— কোডসইনচাউস
এবং এখন যখন দেশের নাম পরিবর্তন হয়, ঠিক করার জন্য আপনার পুরো ডাটাবেস জুড়ে এটি আপডেট করতে হবে। আপনি যদি সরোগেট কী (যেমন ... "আইডি") ব্যবহার করেন তবে আপডেটটি তুচ্ছ। প্রাকৃতিক কীগুলি দুর্দান্ত - যখন এগুলি সম্পূর্ণরূপে অপরিবর্তনীয় এবং কখনই পরিবর্তন হয় না। সত্যিই খুব কম কেস রয়েছে যেখানে এটি সত্য।
— Gerrat
@ জিরাট: যদি কোনও দেশের নাম পরিবর্তন হয় তবে আইএসও 3166-1 সংখ্যার কোড একই থাকে, কেবল আইএসও 3166-1 আলফা -2 এবং আলফা -3 কোড পরিবর্তন হয়। উদাহরণস্বরূপ, বার্মা / মিয়ানমারের ক্ষেত্রে এটি ঘটেছে। তেমনিভাবে, যদি কোনও দেশ তার অঞ্চল পরিবর্তন করে তবে তার নাম রাখে, আইএসও 3166-1 সংখ্যার কোড পরিবর্তন হয় তবে আইএসও 3166-1 আলফা -2 এবং আলফা -3 কোড থেকে যায়। এটি ঘটেছিল যখন দক্ষিণ সুদান সুদান থেকে বিচ্ছিন্ন হয় এবং ইরিত্রিয়া ইথিওপিয়া থেকে বিভক্ত হয়। পূর্ব এবং পশ্চিম জার্মানি পুনরায় একত্রিত হলে তারা পশ্চিম জার্মানির আলফা -২ এবং আলফা -৩ কোড রেখেছিল তবে একটি নতুন সংখ্যার কোড পেয়েছে। যখন দেশগুলি সম্পূর্ণরূপে দ্রবীভূত হয় বা রূপান্তরিত হয় (মনে করুন ...
— জার্গ ডব্লু মিটাগ
… নব্বইয়ের দশকের বলকান যুদ্ধের ফলাফল), তারা নতুন সংখ্যাসূচক এবং আলফা -২ এবং আলফা -3 কোড উভয়ই পেয়ে যায়।
— জার্গ ডব্লু মিট্টাগ
4

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

এটি আমার জন্য একাডেমিক কারণে মারবে না।

— Sfynx
সূত্র
2

আমি মনে করি না এটি যদি সঠিকভাবে ব্যবহার করা হয় তবে এটি একটি খারাপ অভ্যাস। "আইডি" নামে একটি স্বতঃবৃদ্ধি আইডি ক্ষেত্র থাকা আপনার সাধারণ যা আপনার কখনও স্পর্শ করতে পারে না এবং অ্যাপ্লিকেশনটির জন্য বন্ধুবান্ধব শনাক্তকারী ব্যবহার করতে পারে। কোডটি লেখার জন্য এটি কিছুটা জটিল হতে পারে from tableA a inner join tableB b on a.id = b.a_idতবে সেই কোডটি কেটে ফেলা যায়।

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

— ওয়েইন এম
সূত্র
আপনি কখনও এচ প্রাইমারি কী বিশেষত একটি অটো-ইনক্রিমেন্ট আইডি দিয়ে দুটি টেবিলগুলিতে যোগদান করতে পারবেন না। উপরের নমুনাটি টেবিলএ থেকে অভ্যন্তরীণ টেবিলে বি তে a.id = b.table_a_id এ থাকবে।
— বিল লিপার
হ্যাঁ, এটাই আমি বোঝাতে চাইছিলাম প্রায় দুপুরের খাবার সময় এবং শক্তি প্রয়োজন।
— ওয়েইন মোলিনা
2

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

শুধু আশা করি কেউ আইডি একটি সংরক্ষিত শব্দ যেখানে স্কয়ার ডাটাবেস বিকাশ করে না। 

CREATE TABLE CAR (ID);

ক্ষেত্রের নাম, প্রাথমিক কী এবং অটো বর্ধনের জন্য 1 দ্বারা 1 দিয়ে শুরু করে একটি দুর্দান্ত ছোট 2 অক্ষরের প্যাকেজটি যত্ন করে। ওহ, এবং আমি এটিকে CARS নামে ডাকতাম তবে আমরা কী-স্ট্রোকগুলিতে সঞ্চয় করতে যাচ্ছি এবং কে সত্যিই মনে করে যে CAR নামক একটি টেবিলটি কেবল একটি পাবে?

— JeffO
সূত্র
1
এটি দেখায় যে কেন আনুষ্ঠানিক সম্পর্ক সম্পর্কিত তত্ত্বের জ্ঞান গুরুত্বপূর্ণ, টেবিলের নামটি একটি একক সারি কী তা উপস্থাপন করে । সারণী এমন Carএক স্থানে প্রতিনিধিত্ব করে Tableযেখানে প্রতিটি Rowএকককে উপস্থাপন করে Car। Carsপরিবর্তনের আহ্বান সিমেটিক এবং আনুষ্ঠানিক সম্পর্কগত তত্ত্ব বেসিক প্রিন্সিপালগুলির সম্পূর্ণ বোঝার অভাব দেখায়। ব্যর্থতা এমন কারও একটি প্রধান উদাহরণ যা বিপজ্জনক বলে যথেষ্ট জানত ।
2

এই প্রশ্নটি বার বার মারধর করা হয়েছে তবে আমি ভেবেছিলাম যে আমিও আমার মতামত যুক্ত করব।

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

  2. আইডি ক্ষেত্রটি একটি স্ব-স্বীকৃতি, স্বাক্ষরবিহীন (মানে এর অর্থ আমাকে কখনই নির্ধারণ করতে হবে না এবং এটি নেতিবাচক হতে পারে না)

  3. বিদেশী কীগুলির জন্য, আমি টেবিলনামিড ব্যবহার করি (আবার শৈলীর বিষয়) তবে আমি যে প্রাথমিক কীটিতে যোগদান করি তা হ'ল টেবিলের আইডি ক্ষেত্র, সুতরাং ধারাবাহিকতার অর্থ আমি সর্বদা সহজেই অনুসন্ধানগুলি পরীক্ষা করতে পারি

  4. আইডি সংক্ষিপ্ত এবং খুব মিষ্টি

  5. অতিরিক্ত কনভেনশন - সমস্ত টেবিল এবং কলামের নামগুলির জন্য লোয়ার কেস ব্যবহার করুন, সুতরাং কেসের কারণে কোনও সমস্যা খুঁজে পাওয়া যায় না

— স্টিফেন সেনকোমাগো মুসোকে
সূত্র
1

আরেকটি বিষয় বিবেচনা করার বিষয় হ'ল যদি প্রাথমিক কী নামটি বিদেশী কী নামের থেকে আলাদা হয় তবে নির্দিষ্ট তৃতীয় পক্ষের সরঞ্জাম ব্যবহার করা সম্ভব নয়।

উদাহরণস্বরূপ, আপনি ভিসিওর মতো কোনও সরঞ্জামে আপনার স্কিমা লোড করতে অক্ষম হবেন এবং এটি সঠিক ERD তৈরি করতে পারবেন।

— মার্টিজন পিটার
সূত্র
যদিও এটি তৃতীয় পক্ষের সরঞ্জামের দোষ হবে। কলামের নামকরণের কনভেনশনগুলি প্রকৃত বিদেশী কীগুলির বিকল্প নয়, যা সরঞ্জামটির অন্তর্মুখী হওয়া উচিত।
— জেরাত
1

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

এটি কমবেশি কীভাবে লোকেরা সারণির ডেটা পড়বে এবং কীভাবে তারা তাদের কোড লিখবে। আমি ব্যক্তিগতভাবে এবং সম্ভবত এটি সর্বাধিক ঘন ঘন আমি দেখি যে কোডাররা সম্পূর্ণ রেফারেন্সটি লিখেন table.id, এমনকি তাদের ইউনিয়নের বা / এবং যোগদানের প্রয়োজন হয় না। উদাহরণ স্বরূপ:

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

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

সুতরাং আমি যুক্ত করতে চেয়েছি তা সংক্ষেপে এই যে এটি কেবলমাত্র পছন্দের বিষয় এবং এসকিউএল পড়ার বর্ণিত পদ্ধতিটি সর্বাধিক জনপ্রিয়।

যদিও, এমন কিছু ক্ষেত্রে রয়েছে যেখানে এটি ব্যবহার করা হয় না, যেমন (অনেক বেশি বিরল উদাহরণ) যখন আইডিটি এমন স্ট্রিং থাকে যা সত্যিই বর্ণনা করে। উদাহরণস্বরূপ id = "RedFordMustang1970"বা অনুরূপ কিছু। আমি সত্যিই আশা করি আমি কমপক্ষে ধারণা পেতে এটি ব্যাখ্যা করতে পারতাম।

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