ڈیٹا بیس ڈیزائن میں تشکیل کردہ مشترکہ غلطیاں

چاہے آپ ڈیٹا بیس کے ساتھ کام کر رہے ہو، جس میں سینکڑوں ریکارڈ یا لاکھوں ریکارڈ کیے گئے ہیں، مناسب ڈیٹا بیس کا ڈیزائن ہمیشہ اہم ہے. نہ صرف یہ معلومات بہت زیادہ آسان بنائے گی، مستقبل میں اس ڈیٹا بیس کی توسیع بھی آسان ہوگی. بدقسمتی سے، کچھ نیٹ ورکوں میں گرنا آسان ہے جو مستقبل میں چیزوں کو مشکل بنا سکتی ہے.

ڈیٹا بیس کو عام کرنے کے موضوع پر لکھی ہوئی تمام کتابیں ہیں، لیکن اگر آپ کو عام طور پر ان غلطیوں سے بچنے کے لۓ، آپ کو اچھی ڈیٹا بیس کے ڈیزائن کا صحیح راستہ ملے گا.

ڈیٹا بیس کی غلطی # 1: ایک ٹیبل میں فیلڈ بار

اچھی ڈیٹا بیس کے ڈیزائن کے لئے انگوٹھے کا ایک بنیادی اصول دوبارہ بار بار ڈیٹا کو تسلیم کرنا اور ان کی اپنی میز میں ان کے بار بار کالم ڈالنا ہے. ایک میز میں ریفریجویٹ شعبوں کو عام طور پر اسپریڈ شیٹ کی دنیا سے آیا ہے، لیکن اس وقت اسپریڈشیٹس ڈیزائن کے ذریعہ فلیٹ ہوتے ہیں، ڈیٹا بیس متعلقہ ہونا چاہئے. یہ 2 ڈی سے 3D تک جا رہا ہے.

خوش قسمتی سے، تکرار شعبوں کو عام طور پر موقع دینا آسان ہے. بس اس میز پر ایک نظر ڈالیں:

جب ایک حکم میں چار مصنوعات شامل ہوتے ہیں تو کیا ہوتا ہے؟ ہمیں تین سے زائد مصنوعات کی حمایت کرنے کے لئے میز پر ایک اور فیلڈ شامل کرنے کی ضرورت ہوگی. اور اگر ہم نے ان پٹ کے اعداد و شمار میں مدد کے لئے میز کے ارد گرد ایک کلائنٹ کی درخواست بنائی ہے، تو ہم اسے نئے پروڈکٹ فیلڈ کے ساتھ نظر ثانی کرنے کی ضرورت ہوسکتی ہے. اور ہم جیلیبیئن کے ساتھ تمام آرڈر کیسے ترتیب دیں گے؟ ہم ہر پروڈکٹ فیلڈ کو ٹیبل میں SQL بیان کے ساتھ سوال کرنے کے لئے مجبور کیا جاسکیں گے جیسے ایسا لگتا ہے: منتخب کریں مصنوعات سے مصنوعات 1 = 'جیلی بینس یا پروڈکٹ 2 =' جیلی بینس 'یا' پروڈکٹ جیلی بیئن '.

ایک ٹیبل رکھنے کے بجائے جو تمام معلومات کو ایک دوسرے کے ساتھ جمع کرتی ہے، ہمیں تین میزیں بنانا چاہئے جو ہر ایک معلومات کا ایک مخصوص ٹکڑا رکھتا ہے. اس مثال میں، ہم آرڈر کی میز چاہتے ہیں کہ آرڈر خود کے بارے میں معلومات، مصنوعات کی میز، ہمارے سبھی مصنوعات اور پروڈکٹسڈر ٹیبلیٹ کے ساتھ معلومات جو حکم سے منسلک ہوجائے.

نوٹس کریں کہ ہر ٹیبل کا اپنا منفرد ID فیلڈ کیسے ہے. یہ بنیادی کلید ہے. ہم ایک دوسرے کی میز میں غیر ملکی کلید کے طور پر بنیادی کلیدی قدر کا استعمال کرتے ہوئے ٹیبلز سے لنک کرتے ہیں. بنیادی چابیاں اور غیر ملکی چابیاں کے بارے میں مزید پڑھیں.

ڈیٹا بیس غلطی # 2: ایک ٹیبل میں ٹیبل کو سراہا

یہ ایک اور عام غلطی ہے، لیکن یہ ہمیشہ تسلسل کے شعبوں کے طور پر زیادہ سے زیادہ نہیں کھڑا ہے. ڈیٹا بیس کو ڈیزائن کرتے وقت، آپ کو اس بات کا یقین کرنا ہوگا کہ تمام اعداد و شمار کسی میز میں خود سے متعلق ہو. ایسا ہے جیسے بچے کا کھیل مختلف ہے. اگر آپ کیلے ہے تو، ایک اسٹرابیری، ایک آڑو اور ٹیلی ویژن سیٹ، شاید ٹیلی ویژن سیٹ کہیں اور ہے.

اسی لائنوں کے ساتھ، اگر آپ کے سیلز لوگوں کی میز ہے تو، اس میز میں تمام معلومات خاص طور پر اس سیلز شخص سے متعلق ہونا چاہئے. کسی بھی اضافی معلومات جو اس سیلز شخص کے منفرد نہیں ہے آپ کے ڈیٹا بیس میں کہیں اور ہوسکتا ہے.

اگرچہ اس ٹیبل کو ایسا لگتا ہے کہ انفرادی فروخت کنندہ سے تعلق رکھنے والا ہے، اصل میں اس میز میں میز کے اندر اندر داخل ہونے والی میز ہے. نوٹس کریں کہ کس طرح آفس اور آفس نمبر کو "آسٹن ٹاؤن ٹاؤنٹ" کے ساتھ بار بار. کیا اگر کوئی فون نمبر تبدیل ہوجاتا ہے تو آپ کو معلومات کی ایک واحد ٹکڑا کے لئے اعداد و شمار کا ایک مکمل سیٹ اپ ڈیٹ کرنے کی ضرورت ہوگی، جو کبھی بھی اچھی چیز نہیں ہے. یہ شعبوں کو اپنی میز پر منتقل کیا جانا چاہئے.

اس قسم کی ڈیزائن آپ کو سیلز شخص کی میز میں غیر معمولی نظر انداز کرنے کے بغیر آفس کی میز پر مزید معلومات شامل کرنے کی صلاحیت بھی دیتا ہے. تصور کریں کہ اس سڑک کے ایڈریس، شہر، ریاست اور زپ کوڈ کا پتہ لگانے کے لئے کتنا کام کرنا ہوگا، اگر اس معلومات کو سیلز شخص کی میز میں تھا تو!

ڈیٹا بیس غلطی # 3: ایک سنگل فیلڈ میں معلومات کے دو یا زیادہ ٹکڑے ڈالنا

فروخت کی شخص کی میز میں دفتری معلومات کو سرایت کرنا اس ڈیٹا بیس کے ساتھ واحد مسئلہ نہیں تھا. ایڈریس فیلڈ معلومات کے تین ٹکڑے ٹکڑے پر مشتمل ہے: گلی کا پتہ، شہر اور ریاست. ڈیٹا بیس میں ہر فیلڈ کو صرف معلومات کا ایک ہی حصہ ہونا چاہئے. جب آپ کے پاس ایک فیلڈ میں ایک سے زیادہ ٹکڑے ٹکڑے ہیں تو معلومات کے لۓ ڈیٹا بیس سے سوال کرنا مشکل ہوسکتا ہے.

مثال کے طور پر، اگر ہم آسٹن کے تمام فروخت کے لوگوں پر سوال چلانا چاہتے ہیں تو کیا ہوگا؟ ہم ایڈریس فیلڈ کے اندر اندر تلاش کرنے کی ضرورت ہوگی، جو صرف ناگزیر نہیں ہے، لیکن خراب معلومات واپس آسکتی ہے. سب کے بعد، اگر کوئی شخص پورٹل لینڈ میں آسٹن گلی پر رہتا ہے تو کیا ہوتا ہے، اوگراون؟

یہاں کیا جدول کی طرح نظر آتی ہے:

یہاں نوٹ کرنے کے لئے کچھ چیزیں ہیں. سب سے پہلے، "ایڈریس 1" اور "ایڈریس 2" دوبارہ خطے کی غلطی کے تحت گر جائے گا.

تاہم، اس صورت میں وہ اعداد و شمار کے علیحدہ ٹکڑے ٹکڑے ٹکڑے کرنے کا حوالہ دیتے ہیں جو سیلز شخص سے براہ راست تعلق رکھتے ہیں بلکہ اعداد و شمار کے دوبارہ دہلی گروپ کے بجائے اس کی اپنی میز میں جانا چاہئے.

اس کے علاوہ، سے بچنے کے لئے بونس کی غلطی کے طور پر، نوٹس کے طور پر فون نمبر کے لئے فارمیٹنگ میز سے باہر اتار دیا گیا ہے. جب ممکن ہو تو آپ کو شعبوں کی شکل محفوظ کرنے سے بچنے کے لۓ. فون نمبروں کے معاملے میں، کئی ایسے طریقے ہیں جو لوگ فون نمبر لکھتے ہیں: 215-555-5858 یا (215) 555-5858. اس سے ان کے فون نمبر کے ذریعہ سیلز شخص کی تلاش کرنی پڑتی ہے یا اسی علاقہ کوڈ میں فروخت کے لوگوں کو تلاش کرنا مشکل ہے.

ڈیٹا بیس غلطی # 4: صحیح ابتدائی کلیدی کا استعمال نہیں کرتے

زیادہ تر صورتوں میں، آپ اپنی بنیادی کلید کیلئے خود کار طریقے سے بڑھتی ہوئی نمبر یا کچھ دوسرے پیدا کردہ نمبر یا الفانمارک کا استعمال کرنا چاہتے ہیں. آپ کو بنیادی کلید کے لئے کسی بھی حقیقی معلومات کا استعمال کرنے سے بچنے سے بچنے کے لۓ یہاں تک کہ اگر ایسا لگتا ہے تو یہ ایک اچھا شناختی کار بنائے گا.

مثال کے طور پر، ہم سب کے پاس انفرادی سماجی سیکورٹی نمبر ہے، لہذا ملازم ڈیٹا بیس کے لئے سماجی سیکیورٹی نمبر کا استعمال کرتے ہوئے ایک اچھا خیال کی طرح لگ سکتا ہے. لیکن نایاب ہونے کے باوجود، یہ بھی ممکن ہے کہ ایک سوشل سیکورٹی نمبر کو تبدیل کرنے کے لۓ، اور ہم اپنی بنیادی اہمیت کو تبدیل کرنے کے لئے کبھی نہیں چاہتے.

اور یہ کلیدی قدر کے طور پر حقیقی معلومات کا استعمال کرتے ہوئے مسئلہ ہے. یہ تبدیل کر سکتا ہے.

ڈیٹا بیس غلطی # 5: نامزد کنکشن کا استعمال نہیں کرتے

جب آپ سب سے پہلے آپ کے ڈیٹا بیس کو ڈیزائن کرنا شروع کر لیتے ہیں تو یہ ایک بڑا سودا نہیں لگ سکتا ہے، لیکن ایک بار آپ معلومات کو دوبارہ حاصل کرنے کے لئے ڈیٹا بیس کے بارے میں سوالات کا جواب دیتے ہیں، نامناسب کنونشن کے طور پر آپ فیلڈ کے نام کو یاد کرتے ہیں.

صرف تصور کریں کہ یہ عمل کتنا مشکل ہے اگر نام سب سے پہلے نام کے طور پر ذخیرہ کیا گیا تھا، آخری نام ایک میز میں اور first_name، کسی دوسرے ٹیبل میں last_name.

دو سب سے زیادہ نامزد نامزد کنونشنز میدان میں ہر لفظ کے پہلے خط کو سرمکت کر رہے ہیں یا الفاظ کو الگ کرکے استعمال کرتے ہیں. آپ کسی بھی ڈویلپرز کو بھی پہلے لفظ کے سوا ہر لفظ کے پہلے خط کا دارالحکومت دیکھتے ہیں: firstName، lastName.

آپ سنگل ٹیبل کے نام یا کثیر ٹیبل کے نام پر استعمال کرنے پر بھی فیصلہ کرنا چاہتے ہیں. کیا یہ آرڈر کی میز یا احکام کی میز ہے؟ کیا یہ کسٹمر میز یا گاہکوں کی میز ہے؟ پھر، آپ آرڈر ٹیبل اور ایک گاہکوں کی میز کے ساتھ پھنسنا نہیں چاہتے ہیں.

نامناسب کنونشن آپ کا انتخاب کرتے ہوئے اصل نام کا انتخاب نامزد کنونشن کے انتخاب اور عمل کے طور پر اہم نہیں ہے.

ڈیٹا بیس غلطی # 6: بہتر نقطہ نظر

انڈیکسنگ حق حاصل کرنے کے لئے سب سے مشکل چیزوں میں سے ایک ہے، خاص طور پر ڈیٹا بیس کے ڈیزائن پر ان کے لئے. تمام بنیادی چابیاں اور غیر ملکی چابیاں انڈیکس کی جانی چاہیئے. یہ وہ لنک میزیں مل کر ہیں، لہذا بغیر کسی انڈیکس کے بغیر، آپ کو آپ کے ڈیٹا بیس سے بہت خراب کارکردگی نظر آئے گی.

لیکن اکثر ضائع ہوتے ہیں دوسرے شعبے ہیں. یہ "WHERE" شعبوں ہیں. اگر آپ اکثر آپ کی تلاش کو تنگ کرنے کے لئے جا رہے ہیں تو اس علاقے میں ایک فیلڈ استعمال کرتے ہوئے، آپ اس فیلڈ پر انڈیکس ڈالنے کے بارے میں سوچنا چاہتے ہیں. تاہم، آپ میزبان زیادہ سے زیادہ انڈیکس نہیں کرنا چاہتے ہیں، جو کارکردگی کو بھی متاثر کر سکتا ہے.

کس طرح فیصلہ کرنا یہ ڈیٹا بیس کے ڈیزائن کی آرٹ کا حصہ ہے. کوئی سخت حدود نہیں ہیں کہ آپ کتنے انڈیکس کو میز پر ڈالیں. بنیادی طور پر، آپ کسی ایسے فیلڈ کو انڈیکس کرنا چاہتے ہیں جو عام طور پر کسی بھی شق میں استعمال کیا جاتا ہے. مناسب طریقے سے آپ کے ڈیٹا بیس کو سنبھالنے کے بارے میں مزید پڑھیں.