একাধিক বিদেশী কী কী কমা দ্বারা পৃথক করা ব্যবহার ভুল এবং যদি তাই হয় তবে কেন?

31

দুটি টেবিল রয়েছে: Dealএবং DealCategories। একটি ডিলের অনেকগুলি বিভাগের বিভাগ থাকতে পারে।

সুতরাং সঠিক উপায়টি হ'ল DealCategoriesনিম্নলিখিত কাঠামো সহ একটি টেবিল তৈরি করা উচিত :

DealCategoryId (PK)
DealId (FK)
DealCategoryId (FK)

তবে, আমাদের আউটসোর্স টিম একাধিক বিভাগগুলি এইভাবে Dealটেবিলের মধ্যে সঞ্চয় করেছে :

DealId (PK)
DealCategory -- In here they store multiple deal ids separated by commas like this: 18,25,32.

আমি অনুভব করি যে তারা কী করেছে তা ভুল, তবে কেন এটি সঠিক নয় তা স্পষ্টভাবে ব্যাখ্যা করতে জানি না।

আমি কীভাবে তাদের বোঝাতে পারি যে এটি ভুল? বা হতে পারে আমিই সেই ব্যক্তি যা ভুল এবং এটি গ্রহণযোগ্য?

database-design foreign-key

— সরওট পসিটওয়িনিয়ু
সূত্র

20

তুমি ঠিক. একটি ডাটাবেস কলামে কমা দ্বারা পৃথক করা তালিকাটি কি সত্যিই খারাপ? । সংক্ষিপ্ত উত্তর: হ্যাঁ, এটি খারাপ।

— ypercubeᵀᴹ

7

তাদের আরও কোনও ক্ষতি করার আগেই দলটিকে আউটসোর্স করে আগুন ... (-_-)

— রাফা

49

হ্যাঁ এটি একটি ভয়ঙ্কর ধারণা।

যাওয়ার পরিবর্তে:

SELECT Deal.Name, DealCategory.Name
FROM Deal
  INNER JOIN
     DealCategories ON Deal.DealID = DealCategories.DealID
  INNER JOIN
     DealCategory ON DealCategories.DealCategoryID = DealCategory.DealCategoryID
WHERE Deal.DealID = 1234

আপনাকে এখন যেতে হবে:

SELECT Deal.ID, Deal.Name, DealCategories
FROM Deal
WHERE Deal.DealID = 1234

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

SELECT DealCategory.Name
FROM DealCategory
WHERE DealCategory.DealCategoryID IN (<<that list from before>>)

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

এসকিউএল অ্যান্টিপ্যাটার্নস ( কারভিন , ২০১০) এই অ্যান্টিপ্যাটার্নগুলিকে (যাকে তিনি 'জয়ওয়ালিং' বলেছেন) পৃষ্ঠাগুলির 15-23 পৃষ্ঠায় একটি সম্পূর্ণ অধ্যায় নিবেদিত করেছেন। এছাড়াও, লেখক এসও তে অনুরূপ প্রশ্ন পোস্ট করেছেন । তিনি উল্লেখ করেছেন যে মূল পয়েন্টগুলি (এই উদাহরণ হিসাবে প্রয়োগ করা হয়):

একটি নির্দিষ্ট বিভাগে সমস্ত ডিলের জন্য জিজ্ঞাসা করা বরং জটিল (সমস্যাটি সমাধানের সবচেয়ে সহজ উপায় একটি নিয়মিত প্রকাশ, তবে একটি নিয়মিত প্রকাশটি নিজের এবং নিজেই একটি সমস্যা)।
আপনি বিদেশী কী সম্পর্কগুলি ছাড়া রেফারেন্সিয়াল অখণ্ডতা প্রয়োগ করতে পারবেন না। যদি আপনি ডিলক্যাটগরী এনআরআরটি মুছে ফেলেন। # 26, আপনাকে তখন আপনার অ্যাপ্লিকেশন কোডটিতে, # 26 বিভাগের রেফারেন্সগুলি অনুসন্ধান করতে প্রতিটি চুক্তি করতে হবে এবং সেগুলি মুছতে হবে। এইটি এমন কিছু বিষয় যা ডেটা স্তর এ পরিচালনা করা উচিত, এবং আপনার অ্যাপ্লিকেশনের মধ্যে এটি পরিচালনা করতে হচ্ছে খুব খারাপ জিনিস ।
মোট প্রশ্নের ( COUNT, SUMইত্যাদি), আবার, থেকে 'জটিল' 'প্রায় অসম্ভব' পরিবর্তিত হয়। আপনার বিকাশকারীদের জিজ্ঞাসা করুন কীভাবে তারা আপনাকে এই বিভাগে থাকা ডিলের সংখ্যা গণনা করে সমস্ত বিভাগের একটি তালিকা পেতে চাইবে। একটি উপযুক্ত নকশা সহ, এটি এসকিউএলের চারটি লাইন।
আপডেটগুলি আরও জটিল হয়ে ওঠে (যেমন আপনার কাছে পাঁচটি বিভাগে একটি চুক্তি রয়েছে তবে আপনি দুটি সরিয়ে অন্য তিনটি যুক্ত করতে চান)। এটি একটি উপযুক্ত নকশা সহ এসকিউএল এর তিনটি লাইন।
পরিণামে আপনি VARCHARতালিকার দৈর্ঘ্যের সীমাবদ্ধতায় চলে যাবেন । যদিও আপনার কাছে 4000 টিরও বেশি অক্ষরের অধীনে কমা-বিভাজিত তালিকা রয়েছে, তবে সম্ভাবনাটি পার্স করছে যে দানব যেভাবেই নরক হিসাবে ধীর হয়ে চলেছে।
ডাটাবেস থেকে একটি তালিকা টানতে, এটিকে বিভক্ত করা এবং তারপরে অন্য ক্যোয়ারির জন্য ডাটাবেসে ফিরে যাওয়া এক প্রশ্নের চেয়ে আস্তে আস্তে ধীর।

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

— সাইমন রিঘর্টস
সূত্র

1

সাইমন, কেউ একই প্রশ্ন করেছিল ( dba.stackexchange.com/questions/17824/… ), তবে একই এফকে এবং পিকে একই টেবিলে কেন রয়েছে তা আমার স্পষ্ট নয়, যা 3 এফএন ভেঙেছে।

— jcho360

2

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

— সাইমন রিঘার্টস

4

তবে, আমাদের আউটসোর্স টিম এইভাবে একাধিক বিভাগগুলি ডিল সারণীতে সংরক্ষণ করেছে:

ডিলআইডি (পিকে) ডিলকোটাগরী - এখানে তারা একাধিক ডিল আইডি এই জাতীয় কমা দ্বারা আলাদা করে রাখে: 18,25,32।

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

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

এবং এটি আপডেট করা, গণনা, যোগ দেওয়া ইত্যাদির মতো - অন্য কোনও কিছু করা সত্যিই কঠিন এবং ত্রুটি-প্রবণ করে তোলে

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

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

— বিল কারভিন
সূত্র

1

আপনি কি সত্যিই মনে করেন কমা দ্বারা পৃথক করা শিশু আইডি সহ একটি স্ট্রিং সহায়ক? আমি বলতে চাচ্ছি, আবেদন হলে তো পড়তে হয়, তারপর মতো আইডিগুলি এবং সব ক্যোয়ারী শিশু পার্স ছিল select * from DealCategories where DealId in (1,2,3,4,...)। আমার চেয়ে ডাটাবেস ডিজাইনের বিষয়ে আপনার আরও অভিজ্ঞতা আছে, তাই খুব নির্দিষ্ট ক্ষেত্রে এই জাতীয় "চরম টিউনিং" এর জন্য আপনার কিছু ক্ষেত্রে সঠিক কারণ থাকতে পারে। এটি প্রমাণ করার জন্য আমার একমাত্র ধারণা selectহ'ল ডিল / ডিলক্যাটগরিতে খুব বেশি লোড। এটি আমার কাছে অনেকটা আউটসোর্স টিমের মতো দেখতে কোনও ডিবি ডিজাইনের জ্ঞান ছাড়াই টেবিল তৈরির বাইরে তৈরি করেছে।

— এরিক হার্ট

1

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

— বিল কারভিন

1

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

— বিল কারভিন

1

একটি কলামে একাধিক মান 1 ম সাধারণ ফর্মের বিপরীতে।

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

সঠিক প্রয়োগটি হ'ল ডিলআইড এবং ডিলক্যাটরি আইডির সাথে "ডিলডিলক্ল্যাশগুলি" এর মতো একটি জংশন সারণি।

খারাপ শ্রেণিবিন্যাস বাস্তবায়ন?

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

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

— এরিক হার্ট
সূত্র