ডাটাবেসে কলামগুলি লেবেল করার কার্যকর উপায় কী?


30

আমি আমার ডাটাবেসে কলামগুলি লেবেল করতাম:

user_id
user_name
user_password_hash

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

ডাটাবেসে কলামগুলি লেবেল করার কার্যকর উপায় কী? কেন?


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

@ জো, ভাল, আমি সবসময় মাইএসকিউএল এবং এসকিউএলাইট 3 ব্যবহার করেছি তবে এটি অন্যান্য বেশিরভাগ ডাটাবেসে প্রয়োগ করা উচিত।
টমাস হে

@ জো কখনই লক্ষ্য করেন নি যে ওরাকল আলাদা। আপনি একটি লিঙ্ক দিতে পারেন?
bernd_k

@ বারেন্ড_ কে: আমি আমার উত্তরে কিছু লিঙ্ক যুক্ত করেছি , নীচে
জো

উত্তর:


33

আপনার ক্ষেত্রে, উপসর্গ ব্যবহারকারী অনর্থক। আমরা (দায়িত্বে থাকা দেবগণ) জানি যে এটি টেবিল ব্যবহারকারী, সুতরাং কেন user_প্রতিটি ক্ষেত্রের সামনে উপসর্গ যুক্ত করবেন ?

আমি আপনাকে যা পরামর্শ দেব তা হ'ল এটি আরও প্রাকৃতিক পদ্ধতির সাথে করা।

কোনও ব্যক্তির বৈশিষ্ট্যগুলি কী: শেষ নাম, প্রথম নাম, জন্ম তারিখ, জাতীয়তা ইত্যাদি ...

একটি গাড়ির বৈশিষ্ট্যগুলি কী: মডেল, বছর, রঙ, শক্তি ইত্যাদি ...

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


1
হ্যাঁ, লোকেরা যখন এটি করে তখন তা আমার মন খারাপ করে। এছাড়াও যখন তারা তাদের সমস্ত টেবিল টিবিএল_যাকে কল করে।
গাইউস

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

17

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


5
আমি একবার এমন একটি ডাটাবেসে কাজ করেছি যেখানে ডিবিএ কিছু টেবিলে আইডি এবং অন্যদের আইডি ব্যবহার করার সিদ্ধান্ত নিয়েছে এবং আমাদের মাইএসকিউএল কেস সেনসিটিভ ... মজাদার সময় হিসাবে সেট আপ করার জন্য প্রস্তুত করেছে!
টবি 21

6
আমরা সাধারণত টেবিলের নাম। টেবিলনাম_আইডি ব্যবহার করি। যেমন car.car_id; person.person_id। টেবিলের জন্য একক নাম।
glasnt

@ প্লাস্টার স্মার্ট সিদ্ধান্ত।
গারিক

1
এটি আসলে খুব খারাপ ধারণা এবং আপনি এসকিউএল USINGধারাটি ব্যবহার করার ক্ষমতা হারাবেন (এটি অনুমানের বিরুদ্ধে)।
ইভান ক্যারল

9

স্প্রেডজির দুর্দান্ত উত্তরের সাথে ডেভিড হলের সংযোজন সম্পর্কে আমি আরও একমত হতে পারি না। সহজ এবং প্রাকৃতিক উপায় হয়। আপনি টেবিলে প্রাকৃতিকভাবে নাম লেখালেও ছক বিভ্রান্তির বিষয়টি হওয়া উচিত নয়।

ব্যবহারকারীদের যখন ব্যবহারকারীর আইডি এবং কারস.আইডি থাকতে পারে তখন কোনও বুদ্ধি নেই


7

আমি যুক্তি দেব যে একটি ডাটাবেস স্কিমাতে, প্রতিটি কলামের সারণী জুড়ে একটি অনন্য নাম থাকা উচিত। যে জন্য বেশ কয়েকটি কারণ আছে:

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

  • আপনি এই সিনট্যাক্স যোগদানের ব্যবহার করতে পারেন: a JOIN b USING (a_id) JOIN c USING (a_id)। খুব সুবিধাজনক এবং নিম্নলিখিত পয়েন্টটি সাহায্য করে।

  • যদি আপনি প্রচুর যোগদানের সাথে কোয়েরি চালান বা এর সাথে বস্তুগত দৃষ্টিভঙ্গি তৈরি করেন তবে SELECT *আপনার কখনই (ভাল, সম্ভবত খুব কমই) কোনও বিরোধ হবে না। যোগদান সম্পর্কে চিন্তা করুন person.name, product.name, country.name, ইত্যাদি Urgh।

  • সাধারণভাবে, যদি আপনার কাছে বড় প্রশ্ন থাকে তবে idসর্বত্র কী অর্থ তা ট্র্যাক করা শক্ত ।


আপনি কীভাবে কোনও কর্মীর নাম এবং কোনও সাইটের নামের জন্য কলামটির নাম রাখবেন? কীভাবে আপনি নাম লেবেল কলামটির অপ্রয়োজনীয়তা এড়াতে পারবেন?
স্প্রেডজি

@ স্প্রেডজি: আমি কেবল অতিরিক্ত কাজ করে যাব go
পিটার আইসেন্ট্রাট

1
এই উদ্বেগের উত্তর: উপাধি।
সমস্ত ট্রেডের জন

7

আসুন দেখুন, আপনার উদাহরণ সহ এটি দেখতে এরকম কিছু দেখাবে:

USERS
----
id
username,
password
registration_date

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

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


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

5

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

আমি সম্প্রতি একটি সংস্থা রেখেছি যেখানে একজন বিকাশকারী প্রাথমিক কী এবং বিদেশী কী কলামগুলি পিকে এবং এফকে দিয়ে উপসর্গ করা পছন্দ করে। এটি কিছু ঘৃণ্যতার দিকে নিয়ে যায় যেখানে pkfk দিয়ে কলামগুলি শুরু হয়েছিল (সাধারণত 2 টি কলামের উপর ভিত্তি করে একটি যৌগিক প্রাথমিক কী, যার মধ্যে একটি কলাম অন্য টেবিলে বিদেশী কী ছিল)।


4
একটি fk_cluster হিসাবে গণনা না?
কাজি

5

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

আদর্শভাবে কলামের নামগুলি ডাটাবেসের সমস্ত টেবিলের তুলনায় অনন্য।

কিছু পর্যবেক্ষণ:

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

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


3

আমি স্প্রেডজির উত্তরের সাথে একমত হই তবে এটি যুক্ত করব যে পছন্দ হিসাবে বিবেচনা করে আমি আন্ডার_স্কোরের পরিবর্তে উটকেস ব্যবহার করব।

ফার্স্টনাম, লাস্টনাম ইত্যাদি


2
-1 কারণ ক্যামেলকেস সমস্ত ডাটাবেস সিস্টেমে কাজ করে না এবং আপনি একটি ডাটাবেস সিস্টেম নির্দিষ্ট করেন নি। উদাহরণস্বরূপ, ওরাকলে ক্যামেলকেস ব্যবহার করার জন্য এটির খারাপ খবর (এটি তৈরি করতে এটির জন্য ডাবল-কোট ব্যবহার করা প্রয়োজন তবে তার পরে, এটিকে অ্যাক্সেস করতে / ব্যবহার করতে প্রত্যেককে হুপের মধ্য দিয়ে ঝাঁপিয়ে পড়তে হবে)। কি একটা দুঃস্বপ্ন.
স্কটচের

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

3

ওরাকল ক্ষেত্রে, আপনি চাইবেন না নাম কলাম হল 'id' বা 'নাম' কিছু জেনেরিক।

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

কিন্তু এমনকি যদি আপনি করছি না ওরাকল ব্যবহার করে, নাম একাধিক টেবিল প্রদর্শিত chosing না করে, এটি উপায়ে তারপর আপনি প্রত্যেক সময় আপনাকে যা করতে হবে aliasing কষ্ট মধ্য দিয়ে যেতে দুই টেবিল জুড়ে একটি নির্বাচন হবে না:

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

সুতরাং, যদি বহু-সারণী নির্বাচনগুলি আদর্শ হয় তবে দীর্ঘ কলামের নামগুলি আপনার টাইপিং সংরক্ষণ করে। (আপনি যদি একবারে কেবল একটি টেবিল ব্যবহার করেন ... আপনার কি সত্যিই এমনকি একটি সম্পর্কিত ডেটাবেস প্রয়োজন?)

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

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

...

বিষয়গুলি অন্য যেভাবে চলে:

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

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

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

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


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

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

1
প্রাকৃতিক যোগদানের জন্য -1। কোনও সম্পর্কযুক্ত স্কিমা পরিবর্তন যখন যোগ দিতে পারে বা আরও খারাপ হতে পারে তখন কোনও ত্রুটি না ঘটিয়ে এগুলি পরিবর্তন করতে পারেন, আপনি ব্যথার জগতে রয়েছেন। দয়া করে, বাচ্চাদের কথা চিন্তা করুন এবং সর্বদা আপনার যোগদানের ক্ষেত্রগুলি নির্দিষ্ট করুন।
সমস্ত ব্যবসায়ের জোন

2
@ স্কটচের: "সিদ্ধান্ত নেওয়ার জন্য এটি ডাটাবেসের উপর ছেড়ে দেওয়া" - প্রথমে সম্ভবত সম্ভবত আপনি "ডাটাবেস" না দিয়ে "ডিবিএমএস" বোঝাচ্ছেন। দ্বিতীয়ত, ওরাকলে কোনও এআই বা নৃতাত্ত্বিক ব্যবস্থা নেই; বরং নির্বিচারবাদী NATURAL JOINis
onedaywhen

1
@ জো cross joinহলেন, ছিলেন এবং সর্বদা 'ডিফল্ট' থাকবেন। স্পষ্টভাবে ব্যবহৃত না হলে ওরাকল কখনই কলামের নামের সাথে মেলে নাnatural join
জ্যাক ডগলাস

1
  1. কখনও ডাবল-কোট ব্যবহার করবেন "না কারণ এটি করার মাধ্যমে আপনি ডাটাবেসের নেটিভ কেস-ফোল্ডিংকে ওভাররাইড করে। এসকিউএল স্পেকটি দাবি করে যে সমস্ত সনাক্তকারীকে আপার কেস করতে হবে। কিছু ডাটাবেস যেমন পোস্টগ্রিসকিউএল এগুলি লোয়ার কেটে ফোল্ড করে। যদি কোনও কিছুই উদ্ধৃত না হয় তবে এটি সমস্ত ডাটাবেসে কাজ করবে এবং তারা সেগুলি ফাকে বা rdbms- নির্দিষ্ট ডিফল্টে ফোল্ড করতে পারে।
  2. একটি আন্ডার_স্কোর ( _) ব্যবহার করুন , কারণ উপরের হিসাবে - আপনার উট কেস ব্যবহার করা উচিত নয়।
  3. {entity}_idআইডির জন্য ব্যবহার করুন (এবং বিদেশী কীগুলি এই আইডির দিকে নির্দেশ করে)। কারণ তখন আপনি এই USINGধারাটি ব্যবহার করতে পারেন । জয়েন্ট-কন্ডিশনে ব্যবহৃত বিশ্বব্যাপী-অনন্য মূল নামগুলি হ'ল মহাকাশে প্রতিষ্ঠিত একটি সম্মেলন।

    SELECT *
    FROM employee
    INNER JOIN department
      USING (department_id);
    
      -- compare to
      ON employee.department_id = department.department_id;

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