ডাটাবেস, টেবিল এবং কলাম নামকরণ কনভেনশন? [বন্ধ]


790

আমি যখনই কোনও ডেটাবেস ডিজাইন করি তখন আমি সর্বদা ভাবছি যে আমার ডাটাবেজে কোনও আইটেমের নামকরণের সর্বোত্তম উপায় আছে কিনা। প্রায়শই আমি নিম্নলিখিত প্রশ্নগুলি নিজেকে জিজ্ঞাসা করি:

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

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


7
আমি মনে করি আমাদের টেবিলের জন্য বহুবচন এবং কলামগুলির জন্য একক হিসাবে নামকরণ করা উচিত।
এজেড_

7
আমি একাধিক আইটেম সহ "স্টোরেজ" হিসাবে একটি টেবিল দেখতে পাচ্ছি, একক "সত্তা" নয় তাই আমি এটিকে বহুবচন বলি। আমি যখন বস্তুগুলিতে টেবিলগুলি ম্যাপ করি তখন আমি বস্তুর নাম একবাক্য করি। এই মাত্র আমার ব্যক্তিগত মতামত।
ডিপিপি

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

উত্তর:


315

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

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

  1. টেবিলের জন্য একক নাম
  2. কলামগুলির একক নাম
  3. সারণী উপসর্গের জন্য স্কিমার নাম (উদা: স্কীমনাম। টেবিলনাম)
  4. পাস্কেল কেসিং (ওরফে উটের কেস)

14
wilsonmar.com/sql_adचरworks.htm অ্যাডভেঞ্চার ওয়ার্কস স্কিমার একটি দুর্দান্ত বিশ্লেষণ।
ড্যানিয়েল ট্রেবিয়েন

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

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

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

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

278

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

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

বিবরণাদি:

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

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

(২) আপনার সম্ভবত যা করা উচিত।

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

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

  • আমি সত্যিই মনে করি আপনার টেবিলগুলির বহুবচন নাম থাকা উচিত; কিছু একক মনে হয়। যুক্তি অন্য কোথাও পড়ুন। কলামের নামগুলি তবে একক হওয়া উচিত। এমনকি যদি আপনি বহুবিধ টেবিলের নাম ব্যবহার করেন, অন্য সারণীর সংমিশ্রণগুলি উপস্থাপন করে এমন টেবিলগুলি এককথায় থাকতে পারে। উদাহরণস্বরূপ, আপনার যদি প্রচার এবং আইটেম সারণী থাকে তবে প্রচারের অংশ হিসাবে কোনও আইটেমকে প্রতিনিধিত্ব করে এমন একটি সারণী প্রচার-আইটেম হতে পারে, তবে এটি বৈধভাবে প্রচার_ আইটেমগুলিও হতে পারে বলে আমি মনে করি (একাধিক সম্পর্কের প্রতিফলন)।
  • ধারাবাহিকভাবে এবং নির্দিষ্ট উদ্দেশ্যে আন্ডারস্কোরগুলি ব্যবহার করুন। পাসক্যালসেসিংয়ের সাথে কেবল সাধারণ টেবিলের নামগুলি যথেষ্ট পরিষ্কার হওয়া উচিত; পৃথক শব্দের জন্য আপনার আন্ডারস্কোরের দরকার নেই। একটি (মিশ্রণমূলক) টেবিল বা (খ) উপসর্গের জন্য ইন্ডারস্কোরগুলি সংরক্ষণ করুন, যা আমি পরবর্তী বুলেটে সম্বোধন করব।
  • উপসর্গটি ভাল বা খারাপ নয়। এটি সাধারণত সবচেয়ে ভাল হয় না। আপনার প্রথম ডিবি বা দুইটিতে, আমি টেবিলগুলির সাধারণ থিম্যাটিক গোষ্ঠীকরণের জন্য উপসর্গগুলি ব্যবহার করার পরামর্শ দেব না। টেবিলগুলি সহজেই আপনার বিভাগগুলিতে ফিট না করে এবং টেবিলগুলি খুঁজে পাওয়া এটি আরও শক্ত করে তুলতে পারে। অভিজ্ঞতার সাথে আপনি কোনও উপসর্গের পরিকল্পনা করতে এবং প্রয়োগ করতে পারেন যা ক্ষতির চেয়ে আরও ভাল কাজ করে। আমি একটি ডিবি কাজ একবার যেখানে ডাটা টেবিল সঙ্গে শুরু tbl সঙ্গে টেবিল কনফিগ ctbl সঙ্গে মতামত vew , proc এর SP , এবং ইউডিএফ এর FN, এবং আরও কয়েকজন; এটি সাবধানতার সাথে প্রয়োগ করা হয়েছিল, ধারাবাহিকভাবে প্রয়োগ করা হয়েছিল তাই এটি ঠিক আছে। কেবলমাত্র যখন আপনার উপসর্গের প্রয়োজন হয় তখনই যখন আপনার সত্যিই পৃথক সমাধান হয় যে কোনও কারণে একই ডিবিতে থাকে; সেগুলি পূর্বনির্ধারণ করা সারণীগুলি গোষ্ঠীকরণে খুব সহায়ক হতে পারে। আপনি যেমন দাঁড়াতে চান এমন অস্থায়ী টেবিলগুলির মতো বিশেষ পরিস্থিতির জন্যও উপসীকরণ ঠিক আছে।
  • খুব কমই (যদি কখনও হয়) আপনি কলামগুলি উপসর্গ করতে চান।

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

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

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

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

16
@ এরিক আমার অর্থ আপনি টেবিল CustomerIDথেকে প্রাথমিক কী Customerবা অন্য কোনও টেবিলে একটি বিদেশী কী আছে তা জানেন না । এটি একটি ছোটখাটো সমস্যা। আপনি কেন খারাপ নাম ব্যবহার করতে চান c? CustomerID = Customer.IDএটি খুব স্পষ্ট যে আপনি দেখতে পেয়েছেন যে আপনি একটি প্রাথমিক কী দিয়ে কোনও বিদেশী কীতে যোগদান করছেন; উভয় পক্ষ দুটি ভিন্ন জিনিস হওয়ায় এটি নিরর্থক নয়। একক চরিত্রের নামকরণ হ'ল দুর্বল অনুশীলন আইএমও।
ডেভ কাজিনো 22

100

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

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

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

SELECT person.Name
FROM People person

কিছুটা লিনকিউ'র মতো "ব্যক্তি ব্যক্তি থেকে ব্যক্তি নির্বাচন করুন N নাম"।

2, 3 এবং 4 হিসাবে, আমি @ লার্সের সাথে একমত।


17
@ এম্টুসিফোর: ইংরেজিতে আমরা বলি না যে "লোকের ভিড়ে সেখানে উপস্থিত সমস্ত ব্যক্তিকে দেখুন!" একক শব্দ দ্বারা একাধিক উল্লেখযোগ্য জিনিসগুলির সাথে ধারণাগত সমস্যা থাকার আশা করা যায়। এটি স্বাভাবিক বা যথাযথ নয়। "ডেটা" ব্যতিক্রমী এবং প্রায়শই "কেক" এর মতো পদার্থের ভলিউমের একটি অংশকে ব্যবহার করতে ব্যবহৃত হয়। "আপনি কি (এক টুকরো) পিঠা পছন্দ করবেন?" একটি টেবিলের নামকরণ "লোক" কারণ এতে একাধিক ব্যক্তির উপর তথ্য রয়েছে এটি "ব্যক্তি" নামকরণের চেয়ে অনেক বেশি অর্থবোধ করে। ROW এর জন্য "ব্যক্তি" নামে একটি ডেটা ক্লাসটি একক কলামের নামগুলির মতোই অর্থবোধ করে।
ট্রায়ঙ্কো

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

3
এম্টুসিফোর: হ্যাঁ, লোল। সারণীর নামকরণ "পার্সোনকলেশন" এটি "জনগণ" নামকরণের সমতুল্য হবে। এর বিপরীতে এ জাতীয় সংগ্রহকে কেবল "ব্যক্তি" হিসাবে নামকরণের সাথে বোঝা যায় না যা বোঝায় না :)
ত্রিঙ্কো

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

5
@Josh এম ভাল, না পারেন উপায় আপনি যান। আপনি যদি আমার পথে যান তবে আপনি পিপল টেবিলটিকে "ব্যক্তি" হিসাবে উপস্থাপন করতে পারেন এবং ব্যক্তি নির্বাচন করুন ame সমস্যা সমাধান. ;-)
ম্যাট হ্যামিল্টন

73

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

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

আমরা টেবিলগুলির জন্য একক নাম ব্যবহার করি। টেবিলগুলি সিস্টেমের (বা এর সংক্ষিপ্ত রূপ) নামের সাথে উপসর্গ করা থাকে। এটি কার্যকর যদি সিস্টেম জটিল হিসাবে আপনি উপস্থাপনাটিকে এক সাথে যুক্ত করে টেবিলগুলিকে গোষ্ঠীতে পরিণত করতে পারেন (যেমন, Reg_customer, reg_booking এবং regadmin_limits)।

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

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

অর্থাত

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

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


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

40
অবশ্যই এসকিউএলকে অপঠনযোগ্য করে তোলে; তবে আমি মনে করি আমি অনুবাদ করতে পারি। cust_nm হওয়া উচিত CustomerName , booking_dt হওয়া উচিত BookingDate । reg_customer, ভাল কি তা আমি জানি না।
ইয়ান বয়ড

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

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

17
বছরের পর বছর ধরে, আমি আমার টেবিলের শেষে আমার বিকাশকৃত এবং বাজারজাতকরণগুলিতে নতুন কলামগুলি যুক্ত করেছি। কখনও কখনও, আমি আমার কলামগুলিতে ইংরেজি নামগুলি ব্যবহার করি, কখনও কখনও আমি স্প্যানিশ ব্যবহার করি এবং কখনও কখনও আমি অন্য কোনও কলামের জন্য কলামগুলি আবার মুছে ফেলার পরিবর্তে পুনরায় ব্যবহার করি যা ব্যবহার করা হয় তার জন্য সঠিক বর্ণনামূলক নামের সাথে একটি নতুন কলাম যুক্ত করি। আমি অন্য কেউ আমার কোড হ্যাক বা বিপরীত ইঞ্জিনিয়ার চেষ্টা করার ক্ষেত্রে আমার উত্স কোডটি OBFUSCATE করার জন্য উদ্দেশ্যমূলকভাবে এটি করেছি did আমি কেবল এটি বুঝতে পারি, অন্য কেউ হতাশ হবে! .. এইভাবে, তাদের সর্বদা যে কোনও কিছুর জন্য আমার উপর নির্ভর করতে হবে!
ফ্র্যাঙ্ক আর।

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

ঠিক আছে. আমার 0.02 ডলার


5
3 নম্বরে কিছু স্পষ্টতা যুক্ত করা - উপসর্গগুলি কলামের নামটিতে মেটাডেটা এম্বেড করার একটি উপায়। (অতিরিক্ত ব্যবহারের) হাঙ্গেরীয় স্বরলিপি হিসাবে একই কারণে আধুনিক কোনও ডিবিতে এটি করার দরকার নেই।
মার্ক ম্যাকডোনাল্ড

21
order অর্ডার থেকে শীর্ষ 15 নির্বাচন করুন 'বা' আদেশ থেকে শীর্ষ 15 নির্বাচন করুন '? দ্বিতীয়টি আমার (মানুষের) পছন্দ ference
ইয়ান বয়ড

8
@ আইয়ান বয়ড: হ্যাঁ: শীর্ষ 100 নির্বাচন করুন * র প্রতিবেদন থেকে অন্তর্ভুক্ত করুন ভিজিটর রিপোর্টে ভি.আর.আরপোর্টিড = ভিআর.রপোর্টআইডি। এটি কীভাবে আপনি এটি সম্পর্কে ভাবেন তার উপর নির্ভর করে। আপনি যদি কোনও ক্যানিস্টারে একটি লেবুর ছবি রাখেন, তবে আপনি জানতে পারবেন যে ভিতরে বহু লেবু রয়েছে, এটি বাহুতে হতে পারে তা বোঝাতে বাইরে দুটি লেবুর প্রয়োজন ছাড়াই। অবশ্যই, আপনি এটি লিখিত শব্দ "লেবু" দিয়ে লেবেল করতে পারেন। তবে এটি ঠিক পাশাপাশি "লেবু" হতে পারে। "লেবু" নামের রিসোর্স অর্জন করতে এখানে যান।
এরিক

6
কলামের নামগুলিতে আপারকেস ব্যবহার করার জন্য 0.01 ডলার যুক্ত করুন এবং কলামের নামগুলিতে আন্ডারস্কোর ব্যবহারের জন্য আরও একটি 0.01 ডলার যুক্ত করুন যাতে কলামের নামগুলি সরল দৃষ্টিতে পৃথক করা সহজ। মোট = আপনাকে আমার 0.02 ডলার দান!
ফ্রাঙ্ক আর।

6
"সারণীর প্রতিনিধিত্ব করে এমন সত্তার নাম অনুসারে একটি টেবিলের নাম রাখা উচিত" একটি সারণী সত্তার সংকলন। যদিও একটি টেবিলটিও একটি সত্তা, এটি "টেবিল" টাইপের একটি সত্তা যা এর নামে যুক্ত করা অর্থহীন।
ট্রাইপড

34

আমি একটি আইএসও / আইসিসি 11179 স্টাইলের নামকরণ কনভেনশনের পক্ষেও আছি, উল্লেখ করে যে তারা নির্দেশনা নির্দেশ না করে বরং নির্দেশিকা।

উইকিপিডিয়ায় ডেটা উপাদানটির নাম দেখুন :

"সারণি হ'ল সংস্থাগুলির সংগ্রহ এবং সংগ্রহের নামকরণের নির্দেশিকা অনুসরণ করে I আদর্শভাবে, একটি সম্মিলিত নাম ব্যবহৃত হয়: উদাহরণস্বরূপ, কর্মী। বহুবচনটিও সঠিক: কর্মচারী es ভুল নামগুলির মধ্যে রয়েছে: কর্মচারী, tblEmployee এবং কর্মচারী টেবিল।"

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


-1: রেফারেন্সযুক্ত পাঠ্যের আইএসও / আইইসি 11179 এর সাথে কোনও সম্পর্ক নেই reference রেফারেন্সযুক্ত উইকিপিডিয়া পৃষ্ঠায় বিশ্বাস করা উচিত নয়; পরিবর্তে প্রকৃত মানটি পড়ুন ( মেটাডেটা- স্ট্যান্ডার্ডস.
org

@ মাওনদয়াহেন: উইকিপিডিয়া পৃষ্ঠা সংশোধন করার জন্য বিষয় সম্পর্কে আমি যথেষ্ট পরিমাণে জানি না; এছাড়াও, উইকিপিডিয়া পৃষ্ঠাটি এতটা ভুল নয় যেহেতু এটি বিভ্রান্তিকর - এটি স্পষ্টভাবে বলে না যে আইএসও / আইসিআই 11179 ডাটাবেস নামকরণ কনভেনশন অন্তর্ভুক্ত করে, এটি কেবলমাত্র বলে যে "আইএসও / আইইসি 11179 প্রযোজ্য যখন কোনও টেবিল এবং কলামগুলির নামকরণের সময় নামকরণ করা হয়" সম্পর্কিত তথ্য ভাণ্ডার". এরপরে এটি নামকরণের একটি উদাহরণ প্রদান করে যা সম্পর্কিত ডেটাবেসের জন্য ব্যবহৃত হতে পারে। এটি আপনাকে ভাবতে দেয় যে উদাহরণটি আদর্শ থেকে নেওয়া এমন কিছু, যখন এটি সত্যই উইকিপিডিয়া নিবন্ধের লেখক দ্বারা তৈরি করা হয়।
এমকেডাঙ্ক

27

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

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

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

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

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

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


26

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

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

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

  2. কলামের নামগুলি একক হওয়া উচিত?
    সাধারণত, হ্যাঁ, যেখানে আপনি সাধারণীকরণের নিয়মগুলি ভঙ্গ করছেন except

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

    কীওয়ার্ডের সংঘর্ষ এড়ানো একটি দুর্দান্ত উপায় (ডেলিভারি.ফর্ম ব্রেক, তবে ডেলিভারি_ফ্রোম হয় না)।

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

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

    customer.customer_customer_type_id

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

    বা যেখানে আপনার গ্রাহক_প্রকার এবং গ্রাহক_ বিভাগের মধ্যে এমএম সম্পর্ক রয়েছে (কেবলমাত্র নির্দিষ্ট ধরণের কয়েকটি নির্দিষ্ট ক্ষেত্রে পাওয়া যায়)

    customer_category_customer_type_id

    ... লম্বা দিকে একটু (!)।

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

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


1
SELECT * FROM people AS person WHERE person.name = 'Greg'আমার কাছে সবচেয়ে স্বাভাবিক লাগছে।
কেনমোর

1
@ জুকো বেশিরভাগ ক্ষেত্রে, টেবিল প্রাইমারি কী এর নামকরণ কনভেনশন হ'ল <table name><id>উদাহরণস্বরূপ PersonIDবা Person_IDইত্যাদি Therefore সুতরাং, এটি আরও বোধগম্য হয় যে আপনি নিজের টেবিলগুলিকে বহুবচনায় নাম দেবেন না কারণ প্রতিটি রেকর্ড পৃথক ব্যক্তি নয়।
মিঃ blond

20

আইএসও 11179-5 দেখুন: নামকরণ এবং সনাক্তকরণের নীতিগুলি আপনি এটি এখানে পেতে পারেন: http://metadata-standards.org/11179/#11179-5

আমি এটি সম্পর্কে কিছুক্ষণ আগে এখানে ব্লগ করেছি: আইএসও -11179 নামকরণ কনভেনশন


19
যদি আপনি এখানে একটি সংক্ষিপ্ত বিবরণ দেন তবে আপনার উত্তরটি আরও অ্যাক্সেসযোগ্য (= আরও ভাল) হবে। দুর্দান্ত পয়েন্টার, যদিও!
ওলা এল্ডি

15

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

সমস্ত কলামগুলির একটি উপসর্গ দিয়ে নামকরণ করা উচিত যা তারা সংজ্ঞায়িত করা সারণীর সাথে অনন্য।

যেমন প্রদত্ত টেবিলগুলি "গ্রাহক" এবং "ঠিকানা", আসুন যথাক্রমে "কাস্টম" এবং "সংযোজক" এর উপসর্গগুলি নিয়ে যান। "গ্রাহক" এর মধ্যে "কাস্টম_আইডি", "কাস্টম_নাম" ইত্যাদি থাকবে। "ঠিকানা" এর মধ্যে "অ্যাডার_আইডি", "অ্যাডার_কাস্ট_আইডি" (গ্রাহকের কাছে এফকে ফিরে), "অ্যাড্রেটার_স্ট্রিট" ইত্যাদি থাকবে।

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

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

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

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

আরেকটি, এটির তুলনামূলকভাবে সামান্য সুবিধা that

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%';

1
তারপরে আপনি আর পারবেন না reliably find every line of code that touches a particular column... এটাই কি কথা নয়?
রাভেরেন

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

আমি কৌতূহল বোধ করবো কি পরিস্থিতিতে SELECT * প্রয়োজন? আমি অবশ্যই চাইব না যে কেউ প্রডাকশন কোডে এটি ব্যবহার করবে। হ্যাঁ এটি অ্যাডহক প্রশ্নের জন্য এবং কোন একাধিক ডেটা আপনার একাধিক যোগদানের ক্যোয়ারির ফলাফলকে বিজোড় করে তুলছে তা সন্ধানের জন্য দরকারী তবে আমি যেখানে প্রয়োজন সেখানে প্রোডাকশন কোডের কোনও স্থানের কথা ভাবতে পারি না।
এইচএলজিইএম

2
আপনি যদি আপনার সম্পূর্ণ অ্যাপটিকে অ-ওও ভাষায় কোডিং না করেন তবে একটি শালীন ORM স্তর থাকা এই যুক্তিটিকে অপ্রয়োজনীয় করে তোলে।
আদম

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

15

এ সম্পর্কে আমার মতামতগুলি হ'ল:

1) না, টেবিলের নামগুলি একবচন হওয়া উচিত।

এটি সাধারণ নির্বাচনের ( select * from Orders) জন্য অর্থবোধ করে বলে মনে হচ্ছে এটি OO সমতুল্য ( Orders x = new Orders) এর জন্য কম বোঝায় ।

কোনও ডিবিতে একটি সারণী আসলে সেই সত্তার সেট, আপনি সেট-লজিকটি ব্যবহার করার পরে এটি আরও অর্থবোধ করে:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

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

আমি সর্বদা একটি উপনাম ব্যবহার সম্পর্কে নিশ্চিত নই (যেমন ম্যাট পরামর্শ দেয়) এটি পরিষ্কার করে দেয়।

2) তারা একক হতে হবে কারণ তারা কেবল 1 সম্পত্তি রাখে

3) কখনই নয়, যদি কলামের নাম অস্পষ্ট হয় (উপরে যেখানে তাদের উভয়কেই [কী] বলে একটি কলাম থাকে) সারণির নাম (বা তার উপনাম) তাদের যথেষ্ট পরিমাণে পার্থক্য করতে পারে। আপনি ক্যোয়ারীগুলি টাইপ করার দ্রুত এবং সহজ হতে চান - উপসর্গগুলি অপ্রয়োজনীয় জটিলতা যুক্ত করে।

4) আপনি যা চান, আমি ক্যাপিটাল কেস পরামর্শ দেব

আমি মনে করি না যে এগুলির কোনওটির জন্য একের পরম নির্দেশিকা রয়েছে।

যতক্ষণ আপনি যা বেছে নিন অ্যাপ্লিকেশন বা ডিবি জুড়ে সামঞ্জস্যপূর্ণ আমি মনে করি এটি সত্যিই গুরুত্বপূর্ণ matters


3
হেক কি CapitalCase?
ViRuSTriNiTy

@ ভাইরস্ট্রিনি আপনার সম্ভবত তিনি বোঝাতে চেয়েছিলেনpascal case
'18-18

কেইথ, সংখ্যা 3 নম্বরে আমি উভয়ই করি, এবং আমি বেমানান (তবে আমি খনন করি), তবে যতক্ষণ না ওভারবোর্ড না হয় ততক্ষণ একটি বর্ণনামূলক কলামের নাম রাখা খারাপ কেন আমি পাই না, একটি টেবিলের সাথে একই, পরিবর্তনশীল, ইত্যাদি
জনি

@ জোহনি এটি খারাপ নয়, যেমন প্রয়োজন ঠিক নয়। আপনার কী করতে হবে না এমন জিনিস কেন টাইপ করুন? সবচেয়ে intellisense প্রধানত নাম শুরুর ব্যবহার করে, তাই যদি আপনি Product.ProductName, Product.ProductID, Product.ProductPriceইত্যাদি টাইপ Product.Pতোমাদের সকলের পূর্বে সমাধান ক্ষেত্র দেয়।
কিথ

13

আমার মতে:

  1. সারণীর নামগুলি বহুবচন হওয়া উচিত।
  2. কলামের নাম একক হতে হবে।
  3. না।
  4. হয় ক্যামেলকেস (আমার পছন্দসই) বা টেবিলের নাম এবং কলামের নাম উভয়ের জন্য আন্ডারস্কোর_সেটেপড।

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


1
, PascalCase ... ক্যামেলকেস ... snake_case ... # 4 সংক্রান্ত
অ্যান্ড্রু

11

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

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

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

সেক্ষেত্রে আমার উত্তরগুলি এখানে:

  1. হ্যাঁ. একটি সারণী রেকর্ডের একটি দল , শিক্ষক বা অভিনেতা , তাই ... বহুবচন।
  2. হ্যাঁ.
  3. আমি সেগুলি ব্যবহার করি না।
  4. ফায়ারবার্ড - আমি যে ডেটাবেসটি প্রায়শই ব্যবহার করি তা সমস্ত ক্ষেত্রে বড় হাতের অক্ষরে রাখে তাই তাতে কোনও সমস্যা নেই। যাইহোক, আমি যখন প্রোগ্রামিং করি আমি নামগুলি এমনভাবে লিখি যাতে রিলিজ ইয়ারের মতো পড়া সহজ ।

11
  1. অবশ্যই টেবিলের নাম একক রাখুন, ব্যক্তি নয়
    1. একই অবস্থা
    2. না I've এটির পরে ডাটাবেসের নাম ... এটি করবেন না!
    3. হ্যাঁ. আমি আমার সমস্ত টেবিলের নাম পাস্কেলকেসে ঝোঁক

28
ঈশ্বর. কোন। সারণীর নামগুলি নির্দিষ্টভাবে বহুবচন। এটি একটি সংগ্রহ। এটিতে একাধিক জিনিস রয়েছে। "পিপল থেকে * নির্বাচন করুন"। আপনি একটি একক ব্যক্তি থেকে নির্বাচন করছেন না, আপনি একাধিক ব্যক্তি থেকে নির্বাচন করছেন!
ট্রায়ঙ্কো

4
আমি নির্বাচনী বিবৃতিটি বহুবচনের ক্ষেত্রে আরও ভাল শোনার উপায়টি আমি সর্বদা পছন্দ করেছি। SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'টেবিল বহুবচন, কলাম একক। আবার সর্বদা ব্যক্তিগত মতামত একটি বিষয়।
স্কানলিফ

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

9

নামকরণের সম্মেলনগুলি বিকাশকারী দলকে প্রকল্পের কেন্দ্রবিন্দুতে অযোগ্যতা এবং রক্ষণাবেক্ষণের নকশা তৈরি করতে দেয়।

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

আমার উত্তরগুলি এখানে:

  1. হ্যাঁ, টেবিল নাম বহুবচন হওয়া উচিত যখন তারা একটি সেট পড়ুন ব্যবসা , সিকিউরিটিজ বা কাউন্টারপার্টিসমূহের উদাহরণস্বরূপ।
  2. হ্যাঁ.
  3. হ্যাঁ. এসকিউএল টেবিলগুলি টিবি_এর সাথে উপসর্গ করা হয়, ভিউগুলি উপসর্গ করা হয় vw_, সঞ্চিত পদ্ধতিগুলি ইউএসপি_-এর উপসর্গ করা হয় এবং ডাটাবেসের নাম অনুসারে ট্রিগারগুলি টিজি_কে উপসর্গযুক্ত করা হয়।
  4. কলামের নাম নীচের কেসটি আন্ডারস্কোর দ্বারা পৃথক করা উচিত।

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

সুতরাং একটি ভাল নামকরণের কনভেনশন এবং মানকগুলির মূল শিক্ষাগুলি কী:

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

3
সারণি সংজ্ঞা সম্পর্ক দ্বারা হয়। যা প্রকৃতপক্ষে একবচন। উপসর্গ স্তন্যপান। আপনার কি কখনও কোনও টেবিলকে ভিউ বা তদ্বিপরীত রূপে পরিবর্তন করার দরকার পড়েছে? উপসর্গ সহ এটি চেষ্টা করুন। এটি কোনও দৃষ্টিভঙ্গি বা টেবিল হলে কী পার্থক্য করতে পারে?
উইলিয়াম জোনস

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

9

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

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


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

2
ব্যবহৃত মানগুলি নোট করুন: টেবিলগুলি একাধিক জিনিস রাখে, ব্যবহারকারীদের একটি প্রথম নাম থাকে, বড় হাতের টি-এসকিউএল কীওয়ার্ড থাকে, পাস্কাল ক্ষেত্রে টেবিল সংজ্ঞা থাকে।
ইয়ান বয়ড

3
টাইপো: Lastnameহওয়া উচিতLastName
অ্যামিনিম্যালনিমালিম

1
সারণীর নামটি একক হওয়া উচিত: ব্যবহারকারীদের পরিবর্তে ব্যবহারকারী
এজেড_

এবং নোট করুন টেবিলের নামগুলি বহুবচন কীভাবে; তারা রাখা ব্যবহারকারীরা না ব্যবহারকারী
ইয়ান বয়ড

5

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


2
একটি পশুপাল ভেড়ার দল । একটি Userহল না ব্যবহারকারীদের একটি গ্রুপ।
এরিকরবার্টব্রেয়ার

4

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

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

উপস্থাপন সারণী / কলামগুলি: এটি একটি বিশাল বিষয়, এটি পরে আলোচনা করা হবে।

কেসিং: এটি উটের ক্ষেত্রে হওয়া উচিত

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


2
সুতরাং আপনি বলছেন যে টেবিলটি সত্তা? নাকি সারণীতে সারিটি সত্তা? আমার কাছে একটি সারণী হ'ল সারিগুলির সংকলন - অতএব সত্তার সংকলন যা বহুবচনকে বোঝায়।
জেসন

4

পার্টিতে খুব দেরি হলেও আমি এখনও কলামের উপসর্গ সম্পর্কে আমার দুটি সেন্ট যুক্ত করতে চেয়েছিলাম

কলামের জন্য টেবিল_কলাম (বা টেবিল কলাম) নামকরণের মানটি ব্যবহার করার জন্য দুটি প্রধান যুক্তি রয়েছে বলে মনে হয়, কলামের নামটিই আপনার পুরো ডাটাবেসটিতে স্বতন্ত্র হবে fact

1) আপনাকে আপনার প্রশ্নের মধ্যে সার্বক্ষণিক সারণির নাম এবং / অথবা কলামের উপকরণ নির্দিষ্ট করতে হবে না

2) আপনি সহজেই কলাম নামের জন্য আপনার পুরো কোডটি অনুসন্ধান করতে পারেন

আমি মনে করি উভয় যুক্তি ত্রুটিযুক্ত। উপসর্গ ব্যবহার না করে উভয় সমস্যার সমাধান সহজ। আমার প্রস্তাবটি এখানে:

সর্বদা আপনার এসকিউএলে টেবিলের নামটি ব্যবহার করুন। উদাহরণস্বরূপ, সর্বদা কলামের পরিবর্তে টেবিল.কলাম ব্যবহার করুন।

এটি স্পষ্টতই 2 টি সমাধান করে) আপনি এখন টেবিল_কলামের পরিবর্তে কেবল টেবিল.কলিউম অনুসন্ধান করতে পারেন।

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

সম্পাদনা: হ্যাঁ, আমি সচেতন যে উপসর্গ সহ কলামগুলির নামকরণ সঠিক ব্যবহার প্রয়োগ করে যেখানে আমার পদ্ধতি প্রোগ্রামারগুলির উপর নির্ভর করে


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

2
@ জঞ্জব: আমি আপনার উত্তরটিকে সম্পূর্ণ সমর্থন করি। আমি আরও যোগ করতে চাই যে নির্ভরতাগুলি খুঁজে পেতে পাঠ্য অনুসন্ধান ব্যবহার করা কোড নেভিগেট করার বর্বর উপায়। লোকেরা একবার এই বর্বর অনুসন্ধান অনুশীলন থেকে মুক্তি পেয়ে যায় - তারা ভাল নামকরণ শুরু করবে, যা টেবিলের কলাম। সুতরাং সমস্যাটি নামকরণের স্টাইল নয়, সমস্যাটি বর্বরদের জন্য তৈরি খারাপ সরঞ্জাম।
alpav

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

3

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

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


1
যদিও ওরাকল এটি লিংকের লিঙ্কের সম্পূর্ণ বিপরীত পরামর্শ দেয় suggest ওরাকল এখানে কী বলে তা সন্ধান করুন .. ss64.com/ora/syntax-naming.html
এজেড_


ওরাকলের নামকরণের কনভেনশনটি ছিল তাদের সবার মজাদার .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
নওফাল

2

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


-4

--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. বহুবচন। এটি সত্ত্বার সংগ্রহ a
  2. হ্যাঁ. বৈশিষ্ট্যটি কোনও সত্তার একক বৈশিষ্ট্যের প্রতিনিধিত্ব।
  3. হ্যাঁ, উপসর্গের টেবিলের নামটি সমস্ত সীমাবদ্ধতার সূচিপত্র এবং সারণী উপকরণগুলির সহজে ট্র্যাকযোগ্য নামকরণের অনুমতি দেয়।
  4. সারণী এবং কলামের নামগুলির জন্য পাস্কেল কেস, সূচিপত্র এবং সীমাবদ্ধতার জন্য উপসর্গ + সমস্ত ক্যাপ।

6
খ্রিস্টাননাম ... এটি একটি বিজোড় সম্মেলন।
ববিশ্যাফটয়ে

3
আপনার টেবিলে সিরিয়াল নম্বর? কেউ কি গুরুত্ব সহকারে ভাবেন যে এটি বিকাশকারীদের পক্ষে কাজ করে?
এরিক

যেহেতু এই উদাহরণটি এনেছে ... আমি ব্যক্তিগতভাবে টেবিল বা কলামের নামগুলিতে বড় হাতের অক্ষরের বিরুদ্ধে, যেমনটি আমার মনে হয় এটি পড়তে আরও জটিল করে তোলে। সুতরাং এই ক্ষেত্রে, আমি বলব স্টুডালআইডি স্টুডেন্টআইডের চেয়ে পছন্দসই। সংক্ষিপ্ত রূপটি শেষ হওয়ার পরে কোনও বড় কথা নয়, তবে আমি আমার কাজটিতে এমন অসংখ্য উদাহরণ দেখেছি যেখানে সংক্ষিপ্ত নামগুলি নামের সম্মুখভাগে বা মাঝখানে ছিল এবং এটি আপনার মনে ভাগ করে নেওয়া আরও কঠিন করে তুলেছে। উদাঃ স্টুডেন্টএবসিএসএন বনাম স্টুডেন্টএবসিএসএন
red
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.