گندا گندا اسپریڈشیٹ اور ڈیٹا بیس میں سوئچ کریں

ہم نے دیکھا اعداد و شمار کی فہرستوں کو ذخیرہ کرنے کے لئے ایک اسپریڈشیٹ ایپلیکیشن جیسے ایکسل جیسے استعمال کے نقصانات پر۔ یہ نقطہ نظر سب سے پہلے بہترین حل کی طرح معلوم ہوسکتا ہے ، لیکن آپ اس اعداد و شمار کو متعدد صارفین کے ساتھ شیئر کرنے ، مشمولات کی توثیق کرنے یا اپنے اعداد و شمار کو نیویگیشن کرنے میں دشواری کا سامنا کرسکتے ہیں۔ کیوں؟ کیونکہ آپ ایک ایسا ٹول استعمال کر رہے ہیں جو کام کرنے کے لئے ڈیزائن نہیں کیا گیا تھا۔

اب ہم اسپریڈشیٹ پر مبنی فہرست کا استعمال کرتے ہوئے کسی کاروبار کے خیالی (لیکن عام) معاملہ پر غور کریں گے ، اور دیکھیں گے کہ اس طرح کے مسائل پر قابو پانے کے لئے کس طرح ڈیٹا بیس کی ایپلی کیشن میں تبدیل کیا جاسکتا ہے۔

کس طرح کتابیں ہاتھ سے نکل جاتی ہیں

ہماری فہرست گاہکوں کے لئے کئے گئے منصوبوں کے ایک سادہ ریکارڈ کے طور پر شروع ہوئی۔ جیسا کہ کمپنی میں اضافہ ہوا ، اسی طرح مؤکلوں کی تعداد ، نام اور رابطے کی تفصیلات کے ساتھ ورک بک میں شامل ہوگئی۔ نیز ، ان منصوبوں پر عملے کے مختلف ممبران کیا کر رہے تھے اس کی ریکارڈنگ کے لئے کسی طرح کی ضرورت تھی ، لہذا اس ورک بک میں اس سے بھی زیادہ اعداد و شمار شامل کیے گئے۔

اس مقام پر اسپریڈشیٹ نقطہ نظر ناقابل عمل بن گئی: بہت سارے لوگ موجود تھے جو اسے جدید رکھنے کی کوشش کر رہے تھے ، اکثر ایک ہی وقت میں۔ کمپنی نے ایک روٹا قائم کرنے کی کوشش کی ، تاکہ لوگوں نے ورک بک کو اپ ڈیٹ کرنے کے ل turns اسے تبدیل کیا ، لیکن اس کا مطلب یہ تھا کہ کچھ کاموں کو ریکارڈ کرنے سے پہلے ہی اسے فراموش کردیا گیا تھا۔

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

یہ ایک ساختہ مثال ہوسکتی ہے ، لیکن میں نے حقیقت میں ان تمام طریقوں کو حقیقی زندگی میں دیکھا ہے۔ آئیے کام کرنے کے اس طریقہ کار کے ذریعہ پیش آنے والے کچھ امور پر گہری نظر ڈالتے ہیں۔

بہت سارے مسائل

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

شروع کردہ کالم میں بھی ایسی ہی دشواری ہے۔ کچھ خلیوں میں ایک تاریخ ہوتی ہے ، لیکن دوسرے میں صرف ایک مہینہ ریکارڈ ہوتا ہے - اور ایک یا دو ریکارڈ صرف ہاں کہتے ہیں۔ ایکسل اعداد و شمار کی توثیق کی حمایت کرتا ہے ، لہذا یہ یقینی بنانا ممکن ہے کہ مخصوص خلیات میں ہمیشہ کسی خاص قسم کا ڈیٹا موجود ہوتا ہے - لیکن جب کسی اسپریڈشیٹ کو ایڈہاک فیشن میں تیار کیا جاتا ہے تو ، اس کا استعمال شاذ و نادر ہی ہوتا ہے۔

اس مقام پر اسپریڈشیٹ نقطہ نظر ناقابل عمل ہوجاتی ہے: بہت زیادہ لوگ تھے جو اسے تازہ رکھنے کی کوشش کر رہے ہیں

آپ کو کسی ڈیٹا بیس کی ایپلی کیشن میں یہ پریشانی نہیں ہوگی ، کیونکہ فیلڈ کے ڈیٹا ٹائپ کی شروعات سے ہی طے کردی جائے گی۔ اگر آپ کو کام کا آغاز ہونے کی صحیح تاریخ کا پتہ نہیں ہے تو ، آپ مہینے کی پہلی تاریخ کو استعمال کرسکتے ہیں ، یا اگر آپ صرف سال جانتے ہوں تو 1 جنوری۔ اگر پروجیکٹ ابھی شروع نہیں ہوا ہے تو ، آپ شاید اس فیلڈ کو خالی چھوڑ دیں - ڈیٹا بیس کی شرائط میں ایک NULL۔ اگر آپ جانتے تھے کہ پروجیکٹ شروع ہوچکا ہے لیکن پتہ نہیں کب ہوگا تو ، آپ ایسی تاریخ استعمال کرسکتے ہیں جو عام طور پر آپ کے ڈیٹا کے لئے ناممکن ہوجائے گی ، جیسے 1/1/1900۔ فوری طور پر پروجیکٹ کو چھانٹانا اور سرگرمی کا تاریخی جائزہ حاصل کرنا آسان ہوجاتا ہے۔

ایک اور ٹھیک ٹھیک چیلنج کلائنٹ کے لیبل والے کالم کے ذریعہ پیش کیا گیا ہے۔ اس کالم میں درج اندراجات ورک بک میں کسی اور چیز سے منسلک نہیں ہیں ، لیکن شیٹ 1 پر موجود صارفین کی ایک فہرست ہے ، جو غالبا probably اسی سے مراد ہے۔ ایک ہی چیزوں کی متعدد فہرستوں کا ذخیرہ کرنا ، جسے مختلف ناموں سے موسوم کیا جاتا ہے ، مبہم ہے۔ آپ کو اس نام کے بارے میں واضح کرنے کی ضرورت ہے اور اس ہستی کے لئے غیر واضح نام پر تصفیہ کرنا ہے: کیا وہ کلائنٹ ہیں یا صارف؟

اسٹیٹس کالم ایک اور ہے جہاں کوئی توثیق نہیں ہوئی ہے ، لہذا لوگوں نے دوبارہ جو چاہیں لکھنے کا انتخاب کیا۔ بہتر ہوگا کہ تمام جائز اقدار کی ایک مختصر فہرست قائم کی جائے۔

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

جب بات پتوں کی ہو تو ، سب سے بہتر نقطہ نظر یہ ہے کہ پوسٹ کوڈ ، کاؤنٹی ، شہر اور گلی کے لئے الگ الگ فیلڈز کا استعمال کیا جائے (حالانکہ کاؤنٹی کی معلومات برطانیہ کے پتوں کے لئے اختیاری ہے۔ براہ کرم ، ہم برطانوی نہیں ہیں)۔ گلی میں ہر وہ چیز ہونی چاہئے جو پتے کے دوسرے حصوں میں نہیں ہے۔

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

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

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

اپنا ڈیٹا بیس بنانا

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

سب سے پہلے آپ کو اپنی ایکسل ورک بک میں موجود ڈیٹا کو صاف کرنا ہے۔ تلاش اور بدلیں کا استعمال مددگار ثابت ہوسکتا ہے ، اور آپ کو کوئی بھی کالم یا قطار حذف کرنی چاہئے جس میں ڈیٹا موجود نہیں ہے (کالم کی سرخی کے علاوہ ، جس کو رکھنا ضروری ہے)۔ کالم A میں ہر شیٹ میں ایک ID کالم شامل کریں ، اور پہلے سیل میں 1 ٹائپ کرکے اعداد و شمار کے نیچے (شفٹ + اینڈ ، ڈاون) منتخب کرکے پھر فل ڈاؤن کمانڈ (Ctrl + D) کا انتخاب کرکے ان کو بڑھاو with نمبروں کے ساتھ آباد کریں۔ ). پروجیکٹ کے ناموں کی ایک ماسٹر فہرست بنائیں ، اور جہاں بھی کسی پروجیکٹ کا نام درج ہو ، اپنے ماسٹر ID نمبر کی تصدیق کے لئے VLookup () فنکشن کا استعمال کریں؛ اگر کوئی تعداد نہیں ہے تو ، آپ کے ڈیٹا میں مطابقت نہیں ہے۔

ایک بار جب آپ کا ڈیٹا صاف ہوجائے تو ، اس کو رکھنے کے ل it ایک نیا ڈیٹا بیس ڈیزائن کرنے کا وقت آگیا ہے۔ ہم رسائی 2013 کا استعمال کریں گے ، کیونکہ ہماری نظریاتی مثال میں یہ ہمارے آفس 365 کے سبسکرپشن کے ذریعے ہمارے تمام صارفین کے لئے دستیاب ہے۔ جب آپ ایک نیا رسائی کا ڈیٹا بیس بناتے ہیں تو ، آپ اسے ایک رسائی ویب اپلی کیشن یا ایک رسائی ڈیسک ٹاپ ڈیٹا بیس کے بطور تخلیق کرنے کا انتخاب حاصل کرتے ہیں۔ ویب ایپس کا ایک آسان انٹرفیس ہے اور صرف اس صورت میں استعمال کیا جاسکتا ہے جب آپ کے پاس آفس 365 شیئرپوائنٹ آن لائن ہے یا شیئرپوائنٹ سرور 2013 کے ساتھ ایکسیس سروسز اور ایس کیو ایل سرور 2012 ہے۔ ہم روایتی ڈیسک ٹاپ ڈیٹا بیس کا استعمال کریں گے ، کیونکہ اس میں مزید اختیارات اور زیادہ سے زیادہ کنٹرول کی پیش کش کی جاتی ہے۔ صارف کا تجربہ.

نیا ڈیسک ٹاپ ڈیٹا بیس بنانے اور اس کا نام لینے کیلئے منتخب کریں: رسائی ایک نیا جدول بناتا ہے جسے ٹیبل 1 کہتے ہیں ، اور آپ کو ایک کالم کے ساتھ ڈیزائن ویو میں رکھتا ہے ، جس کو ID کہتے ہیں۔ یہاں آپ اپنے ڈیٹا بیس میں مطلوب میزیں ڈیزائن کرسکتے ہیں۔ ہر جدول میں ایک ID فیلڈ ہونا چاہئے (ایک خود بخود بڑھنے والا عدد) ، لیکن الجھن سے بچنے کے ل it اس کو مزید وضاحتی نام دینا بہتر ہوگا۔ پروجیکٹس ٹیبل میں یہ پروجیکٹ آئی ڈی ، کسٹمر آئی ڈی میں کسٹمر ایڈ ، وغیرہ ہوگا۔

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

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

فارمیٹنگ کالمز پر پرسنٹج کامپلیٹ جیسے فیصد اور شارٹ ڈیٹ ہونے کی تاریخوں پر ترتیب دیں ، اور متن والے فیلڈز کی زیادہ سے زیادہ لمبائی کو بھی قابل قدر قدر پر مقرر کریں ، یا وہ سبھی 255 حرف کے لمبے ہوں گے۔ یاد رکھیں کہ کچھ الفاظ (جیسے تاریخ) محفوظ ہیں ، لہذا آپ انہیں کالم کے نام کے طور پر استعمال نہیں کرسکتے ہیں: اس کے بجائے ٹاسک ڈیٹ یا کوئی اور وضاحتی چیز استعمال کریں۔

جب ان کالموں کی بات آتی ہے جہاں آپ کسی اور جدول (جیسے پراجیکٹس ٹیبل میں کسٹمر کالم) کی قیمت تلاش کرنا چاہتے ہیں تو ، تلاش کے کالم کو شامل کرنے سے پہلے رسائی میں موجود ان دیگر جدولوں کی وضاحت کریں۔ جب بات اسٹیٹس کی ہو تو ، آسان ترین آپشن صرف ڈراپ ڈاؤن فہرست میں دکھائ جانے والی اقدار کو ٹائپ کرنا ہوتا ہے - لیکن اس کے بعد ممکنہ اقدار کی فہرست کو شامل کرنا یا اس میں ترمیم کرنا مشکل ہوجاتا ہے۔ جب تک کہ آپ ایک مختصر فہرست سے نمٹنے نہیں کر رہے ہیں جہاں ممکن قدروں میں تبدیلی کا امکان نہیں ہے جیسے کہ کسی فیلڈ میں کسی کی جنس کی ریکارڈنگ ہوتی ہے - یہ بہتر ہے کہ پروجیکٹ اسٹیٹس جیسے اندراجات کے ل another ایک اور ٹیبل بنائیں۔ اس کی مدد سے آپ پروگرامنگ میں تبدیلی کے بغیر مستقبل میں آسانی سے اضافی اختیارات فہرست میں شامل کرسکتے ہیں۔

افزودگی

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

ایک اور اضافہ جو ہم کرسکتے ہیں وہ یہ ہے کہ پراجیکٹ اسٹیٹس جیسی اندراجات کو حرف تہجی کے بجائے کسی خاص ترتیب میں ظاہر کرنے کے لئے مقرر کیا جائے - مثال کے طور پر ، آپ فہرست کے نچلے حصے میں جانا چاہتے ہو۔ ایسا کرنے کے لئے ، ایک ڈسپلے آرڈر کالم شامل کریں اور تلاش کی فہرست کو ترتیب دینے کے ل use اس کا استعمال کریں۔ ID فیلڈ کو استعمال کرنے کا لالچ نہ دو۔ اس کے ساتھ ، کوئی بھی نیا ریکارڈ صرف فہرست کے آخر میں ہی جاسکتا ہے۔

ہمارے اعداد و شمار کو صاف ستھرا رکھنے کے ل we ، ہم ان فیلڈوں کو نشان زد کرسکتے ہیں جن کو صارف کو ضرورت کے مطابق پُر کرنا چاہئے ، اور اس میں توثیق شامل کرنا ہے تاکہ یہ یقینی بنایا جاسکے کہ درج کردہ ڈیٹا صحیح شکل میں ہے۔ آپ سمجھدار ڈیفالٹ اقدار طے کرکے زندگی کو آسان بنا سکتے ہیں: تبصرے کی میز پر کمنٹ ڈیٹ فیلڈ میں اس کی پہلے سے طے شدہ قیمت = تاریخ () مقرر کی جاسکتی ہے ، جب بھی کوئی نیا تبصرہ تخلیق ہوتا ہے تو وہ خود بخود آج کی تاریخ پر سیٹ ہوجاتا ہے۔ صارفین کو مخصوص اقدار کے ساتھ نئے ریکارڈ شامل کرنے سے روکنے کے لئے آپ کسی جدول (بلین) میں دستبرداری کالم کے ساتھ ساتھ توثیق بھی استعمال کرسکتے ہیں۔ اس سے آپ کو ایسی تاریخی اقدار برقرار رکھنے کی اجازت ملتی ہے جو پہلے جائز ہوتی تھیں ، لیکن اب ان کا استعمال نہیں ہوتا ہے۔ یہ خصوصیات ٹیبل ٹولز | پر مل سکتی ہیں ٹیبل ڈیزائن ویو میں فیلڈز ٹیب کو ربن پر یا فیلڈ پراپرٹیز میں۔

آپ کا ڈیٹا درآمد کرنا

ایک بار جب آپ کی میزیں مرتب ہوجائیں تو ، آپ بیرونی ڈیٹا کا استعمال کرسکتے ہیں درآمد اور لنک | اپنے ایکسل ورک بک سے ڈیٹا کو اپنے رسائی کے ڈیٹا بیس میں جدولوں میں شامل کرنے کے ل the ربن پر ایکسل بٹن۔ شروع کرنے سے پہلے اپنے خالی ایکسیس ڈیٹا بیس کا بیک اپ بنائیں ، اگر کچھ غلط ہوجاتا ہے تو ، اور اگر ضرورت ہو تو چھوٹی میزیں ہاتھ سے آباد کرکے شروع کریں۔ ایک بار کام کرنے کے بعد دوسرا بیک اپ لیں ، لہذا اگر مندرجہ ذیل مراحل میں کچھ غلط ہو گیا تو آپ اس مقام پر واپس جاسکتے ہیں۔

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

ایک بار جب ڈیٹا امپورٹ ہوجاتا ہے تو ، ڈیٹاشیٹ ویو میں جدولوں پر اتنا ہی کام کرنا چاہئے جیسا کہ ایکسل ورک شیٹ نے کیا تھا - لیکن اعداد و شمار کی توثیق ، ​​تلاش اور ترتیب دینے کے ساتھ۔ اگر آپ چاہیں تو ، اب آپ اس اعداد و شمار کی بنیاد پر نئی شکلیں اور رپورٹس تیار کرنا شروع کرسکتے ہیں: مثال کے طور پر ، پروجیکٹس کے لئے ماسٹر / ڈیٹیل فارم فارم کے اوپری حصے میں کسی پروجیکٹ کا ڈیٹا اور اس کے لئے ٹاسکس کا گرڈ دکھا سکتا ہے۔ نچلے حصے میں پروجیکٹ.

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

کوئی کاؤنٹی نہیں ، براہ کرم ، ہم برطانوی ہیں

اگر آپ اپنے ڈیٹا بیس میں پتے اسٹور کر رہے ہیں تو ، یہ سمجھنا ضروری ہے کہ آپ کو اصل میں کس معلومات کی ضرورت ہے۔ اگرچہ کاؤنٹی کی معلومات مارکیٹنگ کے لئے کارآمد ثابت ہوسکتی ہیں - اور کچھ بیرون ملک مقیم پتوں کی ضرورت ہوسکتی ہے - اب یہ برطانیہ کے پتوں میں باضابطہ استعمال نہیں ہوتا ہے۔

اپنے تمام YouTube تبصروں کو کیسے تلاش کریں

اس کی وجہ یہ ہے کہ یوکے کے پوسٹل ایڈریس پوسٹ ٹاؤن کے تصور پر انحصار کرتے ہیں ، جہاں آپ کے لئے پوسٹ بھیج دی جاتی ہے اور اسے آپ کے دروازے تک پہنچانے سے پہلے ہی ترتیب دیا جاتا ہے۔ تمام شہر یا دیہات ایک ہی کاؤنٹی میں پوسٹ ٹاؤن کے ذریعہ پیش نہیں کیے جاتے ہیں - مثال کے طور پر ، میلبورن (کیمبرج شائر میں) اپنا میل روسٹن (ہارٹ فورڈ شائر میں) کے ذریعہ ملتا ہے - لہذا پتے میں کاؤنٹی کی وضاحت کسی کے لئے ضروری نہیں ہے۔

الجھن سے بچنے کے ل 1996 ، پوسٹ آفس نے 1996 میں پتے میں کاؤنٹیوں کا استعمال بند کردیا ، اس کے بجائے پوسٹ کوڈ کی معلومات پر بھروسہ کیا - اور 2016 تک ، اس کا ارادہ ہے کہ کاؤنٹی کے ناموں کو اضافی پتہ کی معلومات کے عرف ڈیٹا فائل سے خارج کیا جائے۔ لہذا ، اگر آپ کسی کاؤنٹی کو برطانیہ کے پتے میں شامل کرتے ہیں تو اسے آسانی سے نظرانداز کردیا جائے گا۔