সঞ্চিত প্রক্রিয়াগুলির জন্য আপনার নামকরণের সম্মেলনটি কী? [বন্ধ]


122

সঞ্চিত প্রক্রিয়াগুলির নামকরণের জন্য আমি বিভিন্ন বিধি দেখেছি।

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

কেউ কেউ ক্রিয়া নামটি একটি ক্রিয়া দিয়ে শুরু করুন (পান, যোগ করুন, সংরক্ষণ করুন, সরান)। অন্যরা সত্তার নাম (গুলি) জোর দেয়।

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

আপনি কি নামকরণের কনভেনশন ব্যবহার করেন? দয়া করে এটি বর্ণনা করুন এবং ব্যাখ্যা করুন যে আপনি অন্য পছন্দগুলির চেয়ে কেন এটি পছন্দ করেন।

জবাবের সংক্ষিপ্তসার:

  • প্রত্যেকে নামকরণের ধারাবাহিকতার পক্ষে বলে মনে করছেন, যে কোনও নির্দিষ্ট নামটি ব্যবহার করা হয়েছে তার চেয়ে একই নামকরণ কনভেনশনটি ব্যবহার করা সবার পক্ষে বেশি গুরুত্বপূর্ণ।
  • উপসর্গ: যদিও অনেক লোক ইউএসপি_এর অনুরূপ কিছু ব্যবহার করে (তবে খুব কমই এসপি_) তবে অনেকেই ডাটাবেস বা অ্যাপের নাম ব্যবহার করেন। একজন চালাক ডিবিএ জেনারেল, আরপিটি এবং টিএসকি ব্যবহার করে জেনারেল সিআরইউডি স্প্রোককে রিপোর্টিং বা কাজের জন্য ব্যবহৃত থেকে আলাদা করতে পারে ish
  • ক্রিয়া + বিশেষ্যটি Noun + Verb এর চেয়ে কিছুটা বেশি জনপ্রিয় বলে মনে হচ্ছে। কিছু লোক ক্রিয়াপদের জন্য এসকিউএল কীওয়ার্ডগুলি (নির্বাচন করুন, সন্নিবেশ করান, আপডেট করুন, মুছুন) ব্যবহার করেন, অন্যরা গেট অ্যান্ড অ্যাডের মতো নন-এসকিউএল ক্রিয়াগুলি (বা সংক্ষিপ্ত বিবরণ) ব্যবহার করেন। এক বা একাধিক রেকর্ড পুনরুদ্ধার করা হচ্ছে কিনা তা বোঝাতে কেউ কেউ সিঙ্গলুয়ার এবং বহুবৃত্ত্য বিশেষ্যগুলির মধ্যে পার্থক্য করে।
  • একটি অতিরিক্ত বাক্যাংশ শেষে পরামর্শ দেওয়া হয়, যেখানে উপযুক্ত। গেটকাস্টমারবিআইআইডি, গেটকাস্টমারবিসাইলডেট।
  • কিছু লোক নাম বিভাগগুলির মধ্যে আন্ডারস্কোর ব্যবহার করে এবং কেউ কেউ আন্ডারস্কোরগুলি এড়িয়ে চলে। app_ get_Customer বনাম appGetCustomer - আমার ধারণা এটি পাঠযোগ্যতার বিষয় of
  • স্প্রোকের বৃহত সংগ্রহগুলি ওরাকল প্যাকেজগুলি বা ম্যানেজমেন্ট স্টুডিওতে (এসকিউএল সার্ভার) সমাধান এবং প্রকল্পগুলিতে, বা এসকিউএল সার্ভার স্কিমায় বিভক্ত করা যেতে পারে।
  • অনিচ্ছুক সংক্ষিপ্ত বিবরণ এড়ানো উচিত।

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

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

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

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


1
ইউএসপি কিসের পক্ষে দাঁড়ায়?
মিডহাট

2
আমি বিশ্বাস করি যে ইউএসপি "ব্যবহারকারী পদ্ধতি" এর জন্য স্বল্প। এটি "এসপি_" উপসর্গযুক্ত সিস্টেম পদ্ধতি থেকে পৃথক করে। এটি একটি গুরুত্বপূর্ণ পার্থক্য, কারণ আপনি উত্তরগুলিতে পড়তে পারেন।
ডক

ধন্যবাদ ডক grazie mille
মিডহাট


1
এটি বন্ধ হওয়ার কারণেই আমি এটিকে উত্সাহ দিচ্ছি, আশা করি যে শক্তিগুলি এই জাতীয় প্রশ্নগুলির জন্য কার্যকর তা প্রমাণ করতে to
tsilb

উত্তর:


66

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

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

নতুন ফর্ম্যাটটি নিম্নরূপ

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

এটি পরে সহজে অনুসন্ধানের জন্য জিনিসগুলিকে গোষ্ঠী করতে সহায়তা করে বিশেষত যদি প্রচুর পরিমাণে স্প্রোক থাকে।

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


3
একাধিক অবজেক্ট জড়িত থাকলে কী হবে? উদাহরণস্বরূপ, যদি স্প্রোক গ্রাহক এবং অর্ডার সারণী উভয় থেকে তথ্য অনুসন্ধান করে?
ডোক

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

2
3 টি অ্যাপ্লিকেশানের জন্য আপনি কেন প্রতি পদ্ধতিটি 3 বার নকল করবেন? স্টোর প্রক্রিয়াগুলির পুরো বিন্দুতে এমন কোনও একক স্থান থাকা উচিত যেখানে প্রদত্ত ক্রিয়া ঘটে। "আইসিএ_প্রডাক্ট_এড, সিআরএম_প্রডাক্ট_এড এবং বিপিএস_প্রডাক্ট_ অ্যাড" এটি ধ্বংস করে।
জেসন কেস্টার

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

1
আপনার যদি একই পদ্ধতিতে কল করার একাধিক অ্যাপ্লিকেশন থাকে তবে আপনার অতিরিক্ত সতর্কতা অবলম্বন করা দরকার, সেই প্রোকের কোনও পরিবর্তন সেই একাধিক অ্যাপ্লিকেশনকে ভেঙে দিতে পারে। নামকরণ বুদ্ধিমান, এটি ধূসর অঞ্চল, তবে আপনি এটিকে সাধারণ / বিশ্বব্যাপী বা আপনার পছন্দ মতো কোনও কিছুর নাম দিতে পারেন। @ লোকালঘোস্টস: তথ্যপূর্ণ হওয়ার জন্য ধন্যবাদ।
dnolan

36

এসকিউএল সার্ভারে sp_ উপসর্গ সমস্যা সম্পর্কে কিছু স্পষ্টতা এখানে।

প্রিফিক্স এসপি-র সাথে নামের সঞ্চিত পদ্ধতিগুলি হ'ল মাস্টার ডাটাবেসে থাকা সিস্টেম স্প্রোকগুলি।

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

Sp_ উপসর্গটি ইঙ্গিত দেয় যে স্প্রোকটি সমস্ত ডাটাবেস থেকে অ্যাক্সেসযোগ্য তবে এটি বর্তমান ডাটাবেসের প্রসঙ্গে কার্যকর করা উচিত।

এখানে একটি দুর্দান্ত ব্যাখ্যা দেওয়া হয়েছে, যার মধ্যে পারফরম্যান্স হিটটির একটি ডেমো অন্তর্ভুক্ত রয়েছে।

একটি মন্তব্যে এন্টের দেওয়া আরও সহায়ক উত্স এখানে


হুম আমি বুঝতে পারছি না। কেন এসপি একটি পারফরম্যান্স হিট দেয়? ইউএসপি বা জিএসপি ঠিক আছে?
এরউইন রুইজাকার্স

1
@ user2609980 ডুক বলেছেন যে এসকিউএল সার্ভার sp_প্রথমে মাস্টার ডিবিতে প্রিফিক্সড প্রোক্ট অনুসন্ধান করে , তারপরে বর্তমান ডিবিতে যদি খুঁজে না পায়
GôT

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

পারফরম্যান্স হিটের ডেমোটির লিঙ্কটি ২০০১ সালে লেখা একটি নিবন্ধ থেকে is
মাইকেল জে স্বার্ট

16

সিস্টেম হাঙ্গেরীয় (উপরের "ইউএসপি" উপসর্গের মতো) আমাকে কাঁপিয়ে তোলে।

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

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

পিঁপড়ার মন্তব্যের প্রতিক্রিয়া:

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

1
সুও, আপনি কীভাবে জানবেন যে আপনি কোনও প্রক্রিয়া, একটি ফাংশন, একটি দৃশ্য, একটি টেবিল বা অন্য কোনও কিছুর সাথে ইন্টারেক্ট করছেন কিনা?
এন্টি

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

3
তবে এটি হাঙ্গেরীয় নয়। "ইউএসপি" হাঙ্গেরীয় পরিবর্তনীয় ঘোষণা নয়। "ইউ" "আপডেট" এর পক্ষে দাঁড়ায় না, এটি "ব্যবহারকারী" হিসাবে দাঁড়িয়েছে, যেমন "ব্যবহারকারী সংজ্ঞায়িত সঞ্চিত পদ্ধতি" এবং এটি কেবলমাত্র এসকিউএল সার্ভার থেকে রক্ষিত হয় যখনই আপনি আপনার সঞ্চিত পদ্ধতিটি অনুসন্ধান করছেন ততবারই মাস্টার ডিবিতে সন্ধান করছেন। স্বাভাবিকভাবেই, অন্যান্য উপায় রয়েছে, তবে "ইউএসপি" সাধারণত বহু কর্পসে সাধারণত একটি স্ট্যান্ডার্ড হিসাবে বিবেচিত হয় এবং যা আমি দেখেছি তা এটি ভালভাবে কাজ করে। এছাড়া Microsoft দ্বারা শেখানো, এবং একটি Microsoft নামকরণ সম্মেলন সুপারিশ করেছে: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx
asus3000

10

আমি কয়েক বছর ধরে বিভিন্ন সিস্টেমের বেশিরভাগ ব্যবহার করেছি। অবশেষে আমি এটির বিকাশ করেছি, যা আমি আজও ব্যবহার করে চলেছি:

উপসর্গ:

  • জেন - জেনারেল: সিআরইউডি, বেশিরভাগ ক্ষেত্রে
  • rpt - রিপোর্ট: স্ব-ব্যাখ্যামূলক
  • tsk - কার্য: সাধারণত পদ্ধতিগত যুক্তিযুক্ত কিছু, তফসিলযুক্ত কাজের মাধ্যমে চালিত

অ্যাকশন স্পেসিফায়ার:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(প্রক্রিয়াটি অনেকগুলি কাজ করে এমন ক্ষেত্রে, সামগ্রিক লক্ষ্যটি ক্রিয়া সুনির্দিষ্ট চয়ন করার জন্য ব্যবহৃত হয় instance উদাহরণস্বরূপ, কোনও গ্রাহক INSERT এর জন্য প্রস্তুতিমূলক কাজের একটি ভাল চুক্তির প্রয়োজন হতে পারে, তবে সামগ্রিক লক্ষ্য INSERT হয়, সুতরাং "ইনস" বেছে নেওয়া হয়।

অবজেক্ট:

জেনের জন্য (সিআরইউডি), এটি হ'ল টেবিল বা দেখার নামটি প্রভাবিত হচ্ছে। আরপিটি (প্রতিবেদন) এর জন্য এটি প্রতিবেদনের সংক্ষিপ্ত বিবরণ। Tsk (টাস্ক) এর জন্য এটি কার্যটির সংক্ষিপ্ত বিবরণ।

Ptionচ্ছিক স্পেসিফিক্স:

এগুলি পদ্ধতির বোঝাপড়া বাড়ানোর জন্য ব্যবহৃত তথ্যের alচ্ছিক বিট। উদাহরণগুলির মধ্যে রয়েছে "বাই", "জন্য", ইত্যাদি include

বিন্যাস:

[উপসর্গ] [অ্যাকশন স্পেসিফায়ার] [সত্তা] [ptionচ্ছিক স্পেসিফায়ার]

পদ্ধতির নামের উদাহরণ:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

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

10

TableName_WhatItDoes

  • Comment_GetByID

  • Customer_List

  • UserPreference_DeleteByUserID

কোনও উপসর্গ বা মূর্খ হানি বাজে কথা নয়। এটি সর্বাধিক ঘনিষ্ঠভাবে যুক্ত টেবিলের নাম এবং এটি কী করে তার একটি দ্রুত বিবরণ।

উপরের দিক থেকে একটি সতর্কতা: আমি ব্যক্তিগতভাবে সবসময় আমার সমস্ত অটো-জেনারেটেড সিআরইউডকে zCRUD_ এর সাথে উপসর্গ করি যাতে এটি তালিকাটির শেষে যেখানে আমার এটি দেখার দরকার নেই তা সাজায়।


বাকিগুলি থেকে "z" আইটেমগুলি আলাদা করা একটি দুর্দান্ত ধারণা বলে মনে হচ্ছে।
ডক

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

1
এবং যদি আপনার বেশ কয়েকটি টেবিলগুলিতে যোগদানের কোনও প্রশ্ন থাকে?
leandronn

10

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

সঞ্চিত প্রক্রিয়াগুলির জন্য, সিস্টেম স্প্রোকগুলি থেকে অ্যাপ্লিকেশন স্প্রোকগুলি সনাক্তকরণের উদ্দেশ্যে উপসর্গটি কার্যকর। up_বনাম sp_। ডেটা অভিধান থেকে অ-সিস্টেম সঞ্চিত পদ্ধতিগুলি সনাক্ত করা তুলনামূলকভাবে সহজ করে তোলে।


2
স্প্রোকের নামকরণ "এসপি_" গতির পক্ষেও খুব খারাপ ধারণা, কারণ এসকিউএল সার্ভার সেগুলির পদ্ধতিগুলির অনুমানের ভিত্তিতে তাদের অনুসন্ধানগুলি অনুকূল করতে চেষ্টা করে। এখানে দেখুন, 5 ম পয়েন্টটি নীচে: rakph.wordpress.com/2008/04/19/tips-store-procedure
এন্টি

4

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

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


প্যাকেজগুলি ভাল। এসকিউএল সার্ভার ২০০৫ থেকে শুরু করে, ম্যানেজমেন্ট স্টুডিও সম্পর্কিত স্প্রোকস এবং অন্যান্য এসকিউএল স্টেটমেন্টগুলিকে সঞ্চয় করতে "সমাধান" তৈরি করতে সক্ষম করে।
ডোক ২

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

4

ছোট ডাটাবেসগুলির জন্য, আমি uspTableNameOperationName ব্যবহার করি, উদাহরণস্বরূপ uspCustomerCreate, uspCustomerDelete ইত্যাদি। এটি 'প্রধান' সত্তা দ্বারা গ্রুপিংয়ের সুবিধার্থে।

বৃহত্তর ডাটাবেসের জন্য একটি স্কিমা বা সাবসিস্টেমের নাম যুক্ত করুন, যেমন গ্রহন করা (যেমন, এসকিএল সার্ভার তাদের বর্ণানুক্রমিকভাবে দেখায়)

আমি নামগুলিতে সংক্ষিপ্ত বিবরণ এড়াতে চেষ্টা করি, স্পষ্টতার জন্য (এবং প্রকল্পের নতুন লোকেরা 'UNAICFE' এর অর্থ কী তা ভাবতে হবে না কারণ স্প্রোকটির নাম uspUsingNoAbbraviationsIncreasesClarity forEveryone)


হ্যাঁ, সংক্ষিপ্তসারগুলি সম্বোধন করার জন্য বিশেষত ধন্যবাদ।
ডোক ২

@ [ডক]: আপনি স্বাগত - কি, কোন অগ্রগতি? ;-)
স্টিভেন এ। লো

স্টিভ, আপনি একটি upvote পেয়েছিলাম। আমি উত্তর এবং মন্তব্যের ঝাঁকুনি পড়তে খুব ব্যস্ত ছিলাম এবং কোন উত্তরটি "সেরা" তা নিয়ে বেদনার্ত ছিলাম।
ডক

@ [ডক]: ধন্যবাদ; 'সেরা' উত্তর সম্ভবত আপনার সংস্থার জন্য অর্থবোধ করে এমন সংমিশ্রণ।
স্টিভেন এ। লো

4

আমি বর্তমানে একটি ফর্ম্যাট ব্যবহার করি যা নীচের মতো

স্বরলিপি:

[প্রিফিক্স] [অ্যাপ্লিকেশন] [মডিউল] _ [NAME]

উদাহরণ:

P_CMS_USER_UserInfoGet

আমি কয়েকটি কারণে এই স্বরলিপিটি পছন্দ করি:

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

2

আমি সবসময় ব্যবহার:

ইউএসপি [সারণির নাম] [ক্রিয়া] [অতিরিক্ত বিশদ]

"TblUser" নামে একটি সারণী দেওয়া হয়েছে, যা আমাকে দেয়:

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

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

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


2

অ্যাপ্লিকেশন উপসর্গ_ অপারেশন প্রিফিক্স_ জড়িত ডাটাবেস অবজেক্টের বিবরণ (আন্ডারস্কোরগুলির মধ্যে বিয়োগ ফাঁক করে - তাদের উপস্থিতির জন্য স্পেস রেখে দিতে হয়েছিল)

অপারেশন উপসর্গগুলি আমরা ব্যবহার করি -

  • " পেতে " - একটি রেকর্ডসেট দেয়
  • " ইনস " - তথ্য সন্নিবেশ করে
  • আপডেট " - Updates ডেটা
  • " ডেল " - ডেটা মুছে দেয়

যেমন

wmt_ ins _ গ্রাহক _ বিবরণ _

"কর্মশক্তি পরিচালনার সরঞ্জাম, গ্রাহক সারণিতে বিশদ inোকান"

সুবিধাদি

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

এই সিস্টেমটি আমাদের পক্ষে প্রায় ভাল কাজ করে। আমার মাথার উপরের অংশে একটি ডাটাবেসে 1000 সঞ্চিত পদ্ধতি।

এখনও পর্যন্ত এই পদ্ধতির কোনও অসুবিধা দেখা যায়নি।


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

2

গেটএক্সএক্সএক্স - @ আইডি এর উপর ভিত্তি করে XXX পায়

গেটআলএক্সএক্সএক্স - সমস্ত XXX পায়

পুটএক্সএক্সএক্স - @ আইডি -1 পাস হলে XXX সন্নিবেশ করায়; অন্য আপডেট

ডেলএক্সএক্সএক্স - @ আইডি এর উপর ভিত্তি করে XXX কে মুছে ফেলে


1

আমি মনে করি ইউএসপি_নামিং কনভেনশনটি কারও ভাল হয় না।

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


1
প্রতিটি স্প্রোককে _ শুক্রের সাথে উপসর্গ করা তাদের মধ্যে পার্থক্য করতে সহায়তা করে না। আমি মনে করি কিছু ডিবিএর মতো উপসর্গ রয়েছে কারণ এটি ডাটাবেস অবজেক্টের ধরণকে নির্দেশ করে। আমরা যারা পছন্দ করি তাদের মধ্যে থেকে শুনব।
ডোক

1

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

আমাদের যদি উত্তরাধিকারের সীমাবদ্ধতা না থাকে তবে আমি নিশ্চিত যে আমরা একটি উপসর্গ ব্যবহার করব না।

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

আমাদের দলে সাধারণত সঞ্চিত পদ্ধতির নামগুলি হ'ল:

shopGetCategories
shopUpdateItem

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

1

আপনি মনে করেন না যে আপনার উপসর্গটি এত দীর্ঘ যে আপনি যুক্তিযুক্ত এবং ধারাবাহিকভাবে নিখুঁতভাবে এটি যথাযথভাবে গুরুত্বপূর্ণ। ব্যক্তিগতভাবে আমি ব্যবহার করি

স্পু_ [ক্রিয়া বিবরণ] [প্রক্রিয়া বিবরণ]

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

spu_archiveCollectionData 

অথবা

spu_setAwardStatus

আমি আমার ফাংশনগুলির নাম একইভাবে রাখি, তবে udf_ এর সাথে উপসর্গ

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


স্পু_, আকর্ষণীয় এসকিউএল সার্ভার sp_ সমস্যাটি ডজ করে।
ডক

1

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

সুতরাং আপনি যদি sp_ ব্যতীত অন্য কিছু দিয়ে শুরু করেন তবে জিনিসগুলি সহজ হয়ে যায়।

সুতরাং আমরা প্রোক_এর শুরুতে সাধারণ নামকরণ ব্যবহার করি। এটি যদি একটি বড় স্কিমা ফাইলের সাথে উপস্থাপিত হয় তবে পদ্ধতিগুলি সনাক্ত করা সহজ করে তোলে।

এছাড়াও আমরা একটি উপসর্গ নির্ধারণ করি যা ফাংশন চিহ্নিত করে। মত

Proc_Poll_Interface, Proc_Inv_Interface প্রভৃতি

এটি আমাদের সমস্ত স্টোরেজ প্রোকগুলি সন্ধান করতে দেয় যা পিওএলএল বনাম যা ইনভেন্টরি ইত্যাদি করে কাজ করে does

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

অন্যান্য যেমন ফাংশন এর।

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

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

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

আশা করি এইটি কাজ করবে.


1

আমি দেরিতে থ্রেডে যোগ দিয়েছি তবে আমি এখানে আমার উত্তরটি লিখতে চাই:

আমার শেষ দুটি প্রকল্পে বিভিন্ন প্রবণতা রয়েছে যেমন একটিতে আমরা ব্যবহার করেছি:

ডেটা পেতে: s <টেবিল নাম> _ জি
ডেটা মুছতে: s <টেবিল নাম> _D
ডেটা সন্নিবেশ
করতে: গুলি <টেবিলনাম> _ আই তথ্য আপডেট করতে: এস <টেবিলনাম> _ ইউ

এই নামকরণের সম্মেলনগুলিও dt শব্দের উপসর্গ দ্বারা সম্মুখ-প্রান্তে অনুসরণ করা হয় ।

উদাহরণ:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

আমাদের প্রয়োগে উপরের নামকরণের কনভেনশনের সাহায্যে আমাদের নামগুলি মনে রাখা সহজ এবং সহজ have

দ্বিতীয় প্রকল্পে থাকাকালীন আমরা লিল পার্থক্য সহ একই নামকরণের সম্মেলনগুলি ব্যবহার করেছি:

ডেটা পেতে: sp_ <tablename> G
ডেটা মুছতে: sp_ <tablename> D
তথ্য সন্নিবেশ করতে: sp_ <tablename> আমি
ডেটা আপডেট করতে চাই : sp_ <tablename> ইউ

উদাহরণ:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

মজাদার. আমি এটি কখনও এইভাবে বেশ কার্যকরভাবে দেখিনি, তবে সঠিক নামগুলি মনে রাখা বা অনুমান করা সহজ।
ডেকে

1
ধন্যবাদ ডোক, হ্যাঁ, এটি মনে রাখা সহজ এবং আমরা বিকাশকারীরা নামগুলির যে কোনও জটিলতা থেকে মুক্ত বোধ করি
গৌরব অরোরা

9
_ সি _ আর _ ইউ _ডি কেন নয়?
onedaywhen

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

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