কলামের নাম উপসর্গ করা কেন খারাপ অভ্যাস হিসাবে বিবেচিত হয়?


25

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

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

ব্যক্তি_প্রথম_নাম
বা হতে পারে
ব্যক্তি_প্রেসন_ প্রথম_নাম (আপনি 2x ব্যক্তিকে কেন দেখেন তা জিজ্ঞাসা করবেন না)

কেন কলামের নামগুলি পূর্ব-ঠিক করা খারাপ অভ্যাস হিসাবে বিবেচিত হয়? আন্ডারস্কোরগুলি এসকিউএল-তেও মন্দ হিসাবে বিবেচিত হয়?


দ্রষ্টব্য: আমার প্রো এসকিউএল সার্ভার ২০০৮ - সম্পর্কিত ডেটাবেস ডিজাইন এবং বাস্তবায়ন implementation সেই বইয়ের উল্লেখগুলি স্বাগত।


2
দেখে মনে হচ্ছে এই নিয়মগুলি কে তৈরি করেছে এলিয়জিং ফাংশন সম্পর্কে সচেতন ছিল না।
বায়োফ্রেন্ড

@ ড্যানিয়েল প্রাইডেন - আমি খারাপ শব্দ ব্যবহার করেছি। প্রশ্ন আপডেট হয়েছে।
পি। ব্রায়ান.ম্যাকি

একই ধরণের পোস্ট এখানে স্ট্যাকওভারফ্লো.com

@ বাবু বন্ধু - আপনি কি আমাকে এই মন্তব্যে কিছু বিশদ দিতে পারেন?
পি। ব্রায়ান.ম্যাকি

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

উত্তর:


44

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

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

তবে, একটি পরিপক্ক ডাটাবেসে এটি বিদ্যমান মান পরিবর্তন করার পক্ষে যত বেশি মূল্যবান তার চেয়ে বেশি কাজ। কেবল এটিই মানক এবং এগিয়ে যান, আরও অনেক সমালোচনামূলক বিষয় রয়েছে যা প্রথমে স্থির করা দরকার need


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

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

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

7
@ জেসন, আমি একজন ডাটাবেস ব্যক্তি, আমাদের কাছে কোনও সাহসিকতার কোনও ধারণা নেই বলে ব্যাপকভাবে পরিচিত!
এইচএলজিইএম

2
টেবিলনামের সাথে সম্পূর্ণরূপে সম্মত হন Iএন্টিপ্যাটার্ন হয় d এই নিদর্শনটির মধ্যে এবং তার বাইরে দীর্ঘ সময় কাজ করেছি যা আমি দৃid়ভাবে বলতে পারি যে টেবিলনেমের সাথে ভুল / বিভ্রান্তি ঘটে dযে টেবিলনেমটি হবে না। টেবিলনামআইডি
অ্যারোনলএস

16

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

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

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

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

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

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

6
আমি পছন্দ করতাম যদি বিভিন্ন টেবিলের একই তথ্যের সাথে সমস্ত কলামগুলির একই নাম হত এবং আপনি যখনই আরও বেশি ব্যবহার করেন তখন 1 টেবিল এলিয়াসিং প্রয়োগ করা হয় be কোন টেবিলটিতে প্যাটিড, পেন্টিয়েন্টড, প্যাট_আইডি, আইডি_প্যাট বা ptatient_id মানচিত্রের কথা মনে করে বেশ ক্লান্ত হয়ে পড়ছে।
পিটার বি

1
আমি সমস্ত কলামগুলি অপরিবর্তিত না করে কোনও প্রযোজনা কোয়েরি লিখি না। এটি মেনটেনেসকে এত সহজ করে তোলে। অবশ্যই আমি জটিল প্রতিবেদন / রফতানির প্রকারের প্রশ্নগুলি 10-20 পর্যন্ত যোগ দিয়ে এবং 30-50 কলামগুলিতে লিখি এবং ছয় মাস পরে সেই কলামটি কোন টেবিল থেকে এসেছে তা মনে রাখা শক্ত।
এইচএলজিইএম

8

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


4

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

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

এগুলির সাথে তুলনা করুন: কোনটি চোখে সহজ?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

3
অবশ্যই প্রথমটি ... :)
এরিক

3
কি হবে SELECT name, salary FROM dbo.Person? : পি
সিএইচও

1
@ সিএইচও: এর উপর স্কাইমেন্ডিংয়ের সাথে একটি ভিউ তৈরি করার চেষ্টা করুন ...
জিবিএন

@ জিবিএন: আমার পক্ষে ভাল কাজ করে। CREATE VIEW [dbo].[vwMeritPercentage] with schemabinding AS SELECT [Performance Score] as dblMinScore, ISNULL(( SELECT TOP 1 [Performance Score] FROM dbo.Budget b WHERE b.[Performance Score] > budget.[Performance Score] ORDER BY [Performance Score] ), 100.00) as dblMaxScore, [Merit Minimum] as dblMinPercentage, [Merit Midpoint] as dblBudgetPercentage, [Merit Maximum] as dblMaxPercentage FROM dbo.Budget;
সিএইচও

1
প্রাসঙ্গিক ডকুমেন্টেশন ( msdn.microsoft.com/en-us/library/ms187956(v=SQL.105).aspx ): "আপনি যখন SCHEMABINDING ব্যবহার করেন, तब সিলেক্ট_স্টেটমেন্টে অবশ্যই টেবিলগুলির দ্বি-অংশের নাম (স্কিমা.অবজেক্ট) অন্তর্ভুক্ত থাকতে হবে, দেখুন, বা ব্যবহারকারী-সংজ্ঞায়িত ফাংশন যা উল্লেখ করা হয়। " নোট করুন যে কলামগুলিতে বিন্দুযুক্ত নামগুলির প্রয়োজন নেই (যদি না তারা অন্যথায় ক্যোয়ারিতে অস্পষ্টতাগুলি সমাধান করার প্রয়োজন হয় না) ... কেবল সারণী, দর্শন এবং ফাংশন।
সিএইচও

3

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

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


2

টিএসকিউএলে আপনি টেবিলনাম.ফিল্ডনাম ফর্মের ক্ষেত্রগুলি উল্লেখ করতে পারেন যদি আপনি অস্পষ্টতা এড়াতে চান তবে ক্ষেত্রের নামগুলিতে সারণির নামগুলি যুক্ত করতে পঠনযোগ্যতা থেকে টেবিলের নামটি তৈরি করে নিতে সক্ষম হয় T টেবিলনাম_ফিল্ডনাম বা অনুরূপ। আমি মনে করি আন্ডারস্কোর ব্যবহার করা বা না করা ব্যক্তিগত পছন্দ বেশি। আমি ক্যামেলকেস পছন্দ করি এবং আমি যখন যুক্ত প্রত্যয় বা অনুরূপ উদাহরণস্বরূপ টেবিলনাম_টেম্প যুক্ত করতে চাই তখন আমি _ ব্যবহার করি তবে এটি কেবল আমারই।


2

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


1

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

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


1

অনেক ডাটাবেসের কলামের নাম (যেমন ওরাকল) এর অক্ষরের সংখ্যার উপর কঠোর সীমা থাকে।

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

যদিও আপনি এখন এসকিউএল সার্ভারের সাথে কাজ করছেন, কেউই ভবিষ্যতের পূর্বাভাস দিতে পারে না এবং ভবিষ্যতে আপনার সফ্টওয়্যারটি একাধিক ডাটাবেসে কাজ করতে পারে।


0

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

একটি পদ্ধতির হ'ল আন্তর্জাতিক মানের আইএসও / আইইসি 11179 এর নির্দেশিকা অনুসরণ করা - সর্বোপরি, চাকাটি পুনরায় উদ্ভাবন কেন? মূল কাঠামোটি হ'ল:

[Object] [Qualifier] Property RepresentationTerm

উপাদানগুলির মধ্যে ডিলিমিটারগুলির সাথে: এসকিউএল কলামের নামগুলির ফাঁকা জায়গাগুলির সাথে ভাল খেলতে পারে না এবং আন্ডারস্কোরটি ভিজ্যুয়ালি ভাল কাজ করে।

আমার অনুভূতি আছে যে আপনার সংস্থার কেউ যখন এই জাতীয় নির্দেশাবলীর মতো নাম নিয়ে আসে তারা এই নির্দেশিকাগুলি অনুসরণ করার চেষ্টা করছে Person_Person_First_Name

উদাহরণস্বরূপ আমি শো করতে চান যুক্তরাজ্যের জাতির হেলথ সার্ভিস (এনএইচএস) ডেটা অভিধান

সুতরাং আমি মনে করি না যে নামকরণের কনভেনশনটি আপনাকে কাজ করতে হবে তা খুব খারাপ শোনাচ্ছে।

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

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


0

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

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

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