প্রাথমিক কী হিসাবে ইমেল ঠিকানা ব্যবহার করবেন?


234

স্বয়ংক্রিয় বর্ধন সংখ্যার তুলনায় ইমেলের ঠিকানাটি কি প্রাথমিক প্রার্থীর পক্ষে খারাপ প্রার্থী?

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

ইমেলটিকে প্রাথমিক কী হিসাবে ব্যবহার না করা কি বৈধ কারণ?

আমরা ব্যবহার করছি PostgreSQL


5
'প্রাথমিক' বলতে কী বোঝ? যদি ইমেল ঠিকানাটি স্বতন্ত্র হওয়া প্রয়োজন তবে এটি একটি চাবিকাঠি এবং এর জন্য একটি অনন্য বাধা দরকার requires আপনি যদি এটি 'প্রাথমিক' হওয়াকে 'প্রচার' করার সিদ্ধান্ত নেন তা স্বেচ্ছাচারী, যদি না এটির জন্য কার্যকরী কারণ থাকে যেমন দরিদ্র পরিবেশ সম্পাদনকারী সিস্টেমটির অনুকূলকরণ।
onedaywhen

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

104
@ আরবার্ট যদি কেউ তার ইমেল ঠিকানা পরিবর্তন করতে চায় তবে কী হবে? আপনি কি সব বিদেশী কীগুলি পরিবর্তন করতে চলেছেন?
সিস্টেমে

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

3
@ জেমস ওয়েস্টগেট: এফওয়াইআই, পোস্টগ্রাইএসকিউএলে স্বয়ংক্রিয় ক্লাস্টারিংয়ের মতো জিনিস নেই। একটি প্রাথমিক কী ডিস্কের উপর প্রয়োগ করা হয় ঠিক যেমনটি ইউনিক ইন্ডেক্সের যেখানে সমস্ত ক্ষেত্র শূন্য নয়।
ম্যাথু উড

উত্তর:


283

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

আপনি যদি একাধিক সারণীতে ব্যবহারকারীদের সম্পর্কে তথ্য সঞ্চয় করেন তবে ব্যবহারকারীদের সারণীর বিদেশী কীগুলি ইমেল ঠিকানা হবে be এর অর্থ আপনি ই-মেইল ঠিকানা একাধিকবার সঞ্চয় করেন store


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

@ স্টেফানস্টেইগার হার্ড ড্রাইভের জায়গা সম্পর্কে কে কিছু বলেছেন? আপনার সঞ্চয় করা যেকোনো কিছুই র‍্যামে স্থান নিতে চলেছে।
জোনাথন অ্যালেন

যদি কেউ কেউ আশ্চর্য হয় তবে আমি যেমন করেছি, একটি জিইউইডি কী আমার মনে হয় এমন ইমেল কী এর সমতুল্য।
তোফুটিম

178

আমি আরও উল্লেখ করব যে ইমেলটি একটি অনন্য ক্ষেত্র তৈরি করার জন্য খারাপ পছন্দ, এমন লোক এবং এমনকি ছোট্ট ব্যবসাগুলি রয়েছে যারা ইমেল ঠিকানা ভাগ করে নেয়। এবং ফোন নম্বরগুলির মতো ইমেলগুলি পুনরায় ব্যবহার করতে পারে। Jsmith@somecompany.com সহজেই এক বছর জন স্মিথ এবং দুই বছর পরে জুলিয়া স্মিথের অন্তর্ভুক্ত হতে পারে।

ইমেলগুলির সাথে আর একটি সমস্যা হ'ল এগুলি ঘন ঘন পরিবর্তিত হয়। যদি আপনি কী হিসাবে এটির সাথে অন্য টেবিলগুলিতে যোগ দিচ্ছেন, তবে আপনাকে অন্য টেবিলগুলিও আপডেট করতে হবে যা পুরো ক্লায়েন্ট সংস্থা তাদের ইমেলগুলি পরিবর্তন করে (যা আমি দেখেছি)


47
ক্যাসকেডিং আপডেট সমস্যার উল্লেখ করার জন্য +1। যে কারণে বন্ধুরা কেবলমাত্র সরোগেট কী ব্যবহার করতে দেয় ;-)।
সেলসেকে

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

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

15
@ এইচএলজিইএম: আমি অন্তহীন যুক্তিতে যেতে চাই না, তবে আপনি বলতে পারবেন না যে প্রপোজিক কীটি প্রসঙ্গটি না জেনে অনুমানের ভিত্তিতে অনন্য নয়। উদাহরণস্বরূপ ফোন সংস্থার দৃষ্টিকোণ থেকে, একটি টেলিফোন নম্বর সংজ্ঞা অনুসারে একটি গ্রাহককে স্বতন্ত্রভাবে সনাক্ত করে। হ্যাঁ, আপনি বলতে পারেন, "তবে আপনি যদি এই নাম্বারে কল করলে উত্তর দিতে পারে এমন দু-তিন জন লোক থাকে তবে কী হবে?" তবে এটি অপ্রাসঙ্গিক। ফোন সংস্থার দৃষ্টিকোণ থেকে, সংজ্ঞা অনুসারে এটি একজন গ্রাহক। (অব্যাহত ...)
জে

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

99

প্রাথমিক কীটি অনন্য এবং ধ্রুবক হওয়া উচিত

emailতুগুলির মতো ইমেল ঠিকানাগুলি পরিবর্তন হয়। দেখার জন্য গৌণ কী হিসাবে কার্যকর তবে প্রাথমিক কীটির জন্য পছন্দ কম।


17
একটি ভাল কী এর একটি সম্পত্তি হ'ল স্থিতিশীল হওয়া উচিত তবে অগত্যা অপরিবর্তনীয়।
onedaywhen

5
@ মাফানোয়হেন: হ্যাঁ! অন্যথায় এসকিউএল কেন ক্যাসকেডিং আপডেটগুলিকে সমর্থন করবে?
বিল কারভিন

18
আপনার যদি পছন্দ থাকে তবে ধ্রুবক / অপরিবর্তনীয় কীগুলির জন্য যান; রাস্তায় আপনার জন্য কম কাজ; এসকিউএল কেবল ক্যাসকেডিং আপডেটগুলিকে সমর্থন করে বলেই এটি সর্বদা একটি ভাল ধারণা নয়!
স্টিভেন এ লো।

7
@ ভিনসেন্ট মালগ্র্যাট: "ক্যাসকেডিং আপডেটস ... ব্রেক ডিবি নরমালাইজেশন" - মিথ্যাচারস যে আপনি সাধারণীকরণের ধারণাটি ভুল বুঝেছেন!
onedaywhen

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

64

প্রাথমিক কী হিসাবে কোনও ইমেল ঠিকানা ব্যবহারের অসুবিধা:

  1. যোগ দেওয়ার সময় ধীর।

  2. পোস্ট করা বিদেশী কী সহ অন্য যে কোনও রেকর্ডের এখন আরও বেশি ডিস্কের জায়গা নিয়ে একটি বড় মান রয়েছে। (আজ ডিস্কের জায়গার ব্যয় বিবেচনা করে, এটি সম্ভবত একটি তুচ্ছ সমস্যা, রেকর্ডটি এখন যে পরিমাণ পড়তে আরও বেশি সময় নিয়েছে তা ব্যতীত See দেখুন # 1 টি))

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

প্রাথমিক কী হিসাবে ইমেল ঠিকানা ব্যবহারের সুবিধা:

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

  2. আপনি যখন এডহক প্রশ্নগুলি করছেন, কোনও মাস্টার রেকর্ডটি কী রেফারেন্স করা হচ্ছে তা কোনও মানুষের পক্ষে সহজ। ডেটা সমস্যাগুলি ট্র্যাক করার চেষ্টা করার সময় এটি একটি বড় সহায়তা হতে পারে।

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

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


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

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

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

2
সুবিধা 1 এবং 3 অকালীন অপটিমাইজেশন, সুবিধা 2 খুব সামান্য সুবিধা এবং কোনও শালীন ক্যোয়ারী সরঞ্জাম দ্বারা সম্পূর্ণরূপে পরাস্ত হয়।
অ্যাশ

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

12

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

... এবং আমি পারফরম্যান্স বিবেচনার বিষয়ে কথা বলতে শুরু করি নি।


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

2
সংজ্ঞা অনুসারে একটি বিদেশী কী উল্লেখ, এতে উল্লেখ করা সারিটির প্রাথমিক কীটির মান থাকে। অন্যভাবে রাখুন, এটি প্রাথমিক কীটির মানটিকে নকল করে। (সুতরাং সদৃশটি মান পরিবর্তনের কারণে হয় না But তবে এই অনুলিপিটির কারণে পরিবর্তন আরও শক্ত হয়, এবং এটি কার্যকর করা বাধা)।
মেরিটন

5
লাইনের জন্য +1 "ধরে নিন কিছু ইমেল সরবরাহকারীর ব্যবসায়ের বাইরে চলে যায়।"
রেড্ডি

এটা কোন সমস্যা না। এই সমস্যাটি সমাধান করার জন্য বিদেশী-কী ক্যাসকেডিং বিদ্যমান। যদি কোনও ব্যবহারকারী তাদের ইমেল পরিবর্তন করে, পরিবর্তনটি বিদেশী কী হিসাবে এটি ব্যবহার করে সমস্ত টেবিলগুলিতে ক্যাসকেড করবে।
রাফা

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

12

আপনার সেটআপে এটি সমস্যা হতে পারে কিনা তা আমি জানি না, তবে আপনার আরডিবিএমএসের উপর নির্ভর করে কলামগুলির মানগুলি সংবেদনশীল হতে পারে । পোস্টগ্রিএসকিউএল ডক্স বলছে: "আপনি যদি কলামটি অনন্য বা প্রাথমিক কী হিসাবে ঘোষণা করেন তবে প্রকাশিত উত্পন্ন সূচকটি কেস-সংবেদনশীল"। অন্য কথায়, আপনি যদি প্রাথমিক কী হিসাবে ইমেলযুক্ত কোনও টেবিলের অনুসন্ধানের জন্য ব্যবহারকারীর ইনপুট গ্রহণ করেন এবং ব্যবহারকারী "John@Doe.com" সরবরাহ করেন তবে আপনি "john@doe.com" পাবেন না।


7
এই সংযোগে উল্লেখ করা জরুরী যে জন@ডয়ে ডট কম এবং জন@ডো.কম একই মেলবক্স হতে পারে বা বিভিন্ন মেলবক্স হতে পারে এবং আপনার বলার উপায় নেই - স্থানীয় অংশটি কেস- কিনা তা বলার মত কিছু নেই spec সংবেদনশীল।
তেঁতুল

এটি ইমেল ঠিকানাগুলির স্বতন্ত্রতা প্রয়োগের সাথে এগুলিকে প্রাথমিক কী হিসাবে ব্যবহার করা উচিত কিনা এর চেয়ে আরও সাধারণ সমস্যা - একই সমস্যাটি উভয়ভাবেই রয়েছে। +1 কারণ এটি এখনও খুব দরকারী পয়েন্ট

11

ইমেল ঠিকানাগুলি ব্যক্তিগত হিসাবে বিবেচনা করা যেতে পারে এমন কোনও সম্ভাব্য সমস্যা কেউ উল্লেখ করেছেন বলে মনে হয় না। যদি ইমেল ঠিকানাটি প্রাথমিক কী হয় তবে একটি প্রোফাইল পৃষ্ঠার ইউআরএলটি সম্ভবত এর মতো দেখতে হবে ..../Users/my@email.com। আপনি যদি ব্যবহারকারীর ইমেল ঠিকানাটি প্রকাশ করতে না চান তবে কী হবে? ইউআরএল পছন্দ করার জন্য আপনাকে একটি অনন্য পূর্ণসংখ্যার মান দ্বারা ব্যবহারকারীর শনাক্তকরণের অন্য কোনও উপায় খুঁজে পেতে হবে ..../Users/1। তারপরে আপনি সর্বোপরি একটি অনন্য পূর্ণসংখ্যার মানটি দিয়ে শেষ করতে পারেন।


9

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

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

পদ্ধতি জিজ্ঞাসা,

কেউ যদি তার ইমেল ঠিকানা পরিবর্তন করতে চান? আপনি কি সব বিদেশী কীগুলি পরিবর্তন করতে চলেছেন?

এর কি যে ক্যাসকেডিং জন্য।

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

বিকল্প কী হিসাবে স্ট্রিংটি ব্যবহার করার সময় আরেকটি বিষয় বিবেচনা করতে হবে, তা হ'ল আপনি যে প্রকৃত স্ট্রিংটি চান সেটি হ্যাশ ব্যবহার করা দ্রুত হতে পারে, কিছু অক্ষরের উপরের এবং নিম্নের মতো জিনিসগুলি এড়ানো যায়। (আমি সবেমাত্র কী বলেছিলাম তা নিশ্চিত করার জন্য একটি রেফারেন্স খুঁজতে গিয়ে আমি আসলে এখানে পৌঁছেছি; এখনও খুঁজছি ...)


4

হ্যাঁ, আপনি যদি পরিবর্তে কোনও পূর্ণসংখ্যা ব্যবহার করেন তবে ভাল। আপনি নিজের ইমেল কলামটি অনন্য সীমাবদ্ধ হিসাবে সেট করতে পারেন।

এটার মত:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

8
কেন এটি "ভাল"? কোন কারণ বা উত্স?
সুজায়ার্ড

20
আপনি কি এ সম্পর্কে বিস্তারিত বলতে পারেন?
সুজয়ের্ড

4

হ্যাঁ, এটি একটি খারাপ প্রাথমিক কী কারণ আপনার ব্যবহারকারীরা তাদের ইমেল ঠিকানাগুলি আপডেট করতে চান।


1
ভেবেছিলাম আমি উল্লেখ করতে পারি যে এখন আমাদের ক্যাসকেড হয়েছে এটি কোনও সমস্যা নয়
মলহাল

3

আপনি যখন আলাদা টেবিলের ইমেল ঠিকানাটি উল্লেখ করেন তখন পূর্ণসংখ্যার প্রাথমিক কীটি কেন আরও ভাল Another যদি ঠিকানাটি নিজেই একটি প্রাথমিক কী হয় তবে অন্য টেবিলে আপনাকে কী হিসাবে এটি ব্যবহার করতে হবে। তাই আপনি একাধিকবার ইমেল ঠিকানাগুলি সঞ্চয় করেন।


3

পোস্টগ্রিসের সাথে আমি খুব বেশি পরিচিত নই। প্রাথমিক কীগুলি একটি বড় বিষয়। আমি এই সাইটে কয়েকটি চমৎকার প্রশ্নোত্তর দেখেছি (স্ট্যাকওভারফ্লো.কম)।

আমি মনে করি একটি সংখ্যক প্রাথমিক কী থাকলে আপনার আরও ভাল পারফরম্যান্স থাকতে পারে এবং ইমেল কলামে একটি ইউনিক ইন্ডেক্স ব্যবহার করতে পারেন। ইমেলগুলি দৈর্ঘ্যে পরিবর্তিত হয় এবং প্রাথমিক কী সূচক জন্য উপযুক্ত নাও হতে পারে।

কিছু এখানে এবং এখানে পড়া


3

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


2

আপনার সহকর্মী সঠিক: আপনার প্রাথমিক কী এর জন্য একটি স্বতঃসংশোধক পূর্ণসংখ্যা ব্যবহার করুন।

আপনি অ্যাপ্লিকেশন পর্যায়ে ইমেল-স্বতন্ত্রতা বাস্তবায়ন করতে পারেন, বা আপনি নিজের ইমেল ঠিকানা কলামটি অনন্য হিসাবে চিহ্নিত করতে এবং সেই কলামটিতে একটি সূচক যুক্ত করতে পারেন।

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

অবশ্যই, আপনার অবশ্যই লক্ষ্য রাখতে হবে যে ডাটাবেস পর্যায়ে আপনার অ্যাপ্লিকেশনটিতে কোনও বাধা যুক্ত করার ফলে আপনার অ্যাপ্লিকেশনটি জটিল নয়। আপনি যে কোনও ক্ষেত্রকে "অনন্য" বা "নাল নয়" তৈরি করার আগে সর্বদা যথাযথ বিবেচনা করুন কারণ আপনার অ্যাপ্লিকেশনটির প্রয়োজন অনন্য বা খালি নয়।


1
"আপনার প্রয়োজনের এক্স প্রয়োগ করার আগে সর্বদা যথাযথ বিবেচনা করুন কারণ আপনার অ্যাপ্লিকেশনটির দরকার হয় x।" - বেশিরভাগ পরামর্শের সবচেয়ে খারাপ অংশ আমি পড়েছি।
onedaywhen

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

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

1
নেকড়ে হও: আমি একবার এমন এক মহিলাকে জানতাম যার নিজের ফোন নম্বর ছিল না। তারপরে তুমি কি করবে?
ডেভিড থর্নলি

@ ডেভিডথর্নলে সাউন্ডগুলি আপনার মতো আরও বেশি করে কাজ করা উচিত, অথবা সম্ভবত বন্ধুত্বপূর্ণ আচরণের সাথে মানিয়ে নিতে হবে।
ফিলিপ শিফ

2

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


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

না ... দেখুন ডেভিব্রিয়ন.com
blog/

3
সত্যিকারের মাইক্রোসফ্ট-কুল-এইড-পানীয় পানীয়তে বলেছিলেন!
গ্যারি চেম্বারস

2

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

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

আপনার যদি রেকর্ডগুলি মুছতে হয় এবং সেগুলি স্থানীয় আইনের উপর নির্ভর করে ব্যবসায়ের আর্থিক ইতিহাসের সাথে সম্পর্কিত হয় তবে আপনি নিজেকে গরম পানিতে খুঁজে পেতে পারেন।

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


2

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

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


1

আপনি পূর্ণসংখ্যার প্রাথমিক কী ব্যবহার করে পারফরম্যান্সটি বাড়িয়ে দিতে পারেন।


1

আপনার একটি পূর্ণসংখ্যার প্রাথমিক কী ব্যবহার করা উচিত। আপনার যদি ইমেল-কলামটি অনন্য হওয়ার প্রয়োজন হয় তবে আপনি কেন এই কলামটিতে অনন্য-সূচক সেট করেন না?


1

আপনার যদি প্রাথমিক কী হিসাবে মানহীন মান থাকে তবে সন্নিবেশ এবং পুনরুদ্ধারগুলি বড় ডেটাতে খুব ধীর হবে।


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

1

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


0

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


0

যদি এটি ইমেলটি অনন্য হওয়ার প্রয়োজন হয় তবে আপনি কেবলমাত্র সেই কলামটি দিয়ে একটি অনন্য সূচক তৈরি করতে পারেন।


0

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


0

ইমেল ঠিকানাটিকে প্রাথমিক কী হিসাবে ব্যবহার করবেন না, ইমেলটিকে অনন্য হিসাবে রাখুন তবে এটি প্রাথমিক কী হিসাবে ব্যবহার করবেন না, ব্যবহারকারীর আইডি বা ব্যবহারকারীর নামটি প্রাথমিক কী হিসাবে ব্যবহার করবেন না

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