টেবিলের অবিচ্ছিন্নভাবে সৃষ্টি এবং মুছে ফেলা কি কোনও স্থাপত্য ত্রুটির চিহ্ন?


11

সম্প্রতি আমি এমন একটি বিকাশকারী সাথে আলোচনা করেছি যিনি উল্লেখ করেছিলেন যে প্রোগ্রাম বিকাশের সময় তারা নিয়মিতভাবে নতুন বৈশিষ্ট্যগুলি এবং ন্যায়সঙ্গত জিনিসগুলির উপর কাজ করার সময় নিয়মিতভাবে টেবিল এবং কলামগুলি মুছে ফেলা এবং মুছে ফেলা বলে যে চতুর বিকাশ প্রক্রিয়া ব্যবহার করার সময় এটি স্বাভাবিক।

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


ডাটাবেসটিতে একটি মন্তব্য, শেষ বার যখন এটি পরীক্ষা করা হয়েছিল সেখানে 700 টিরও বেশি টেবিল রয়েছে এবং আমি অন্যদের দ্বারা শুনেছি যে "এটি রিফ্যাক্টর করার পর্যাপ্ত সময় নেই" "
rjzii

24
700 টেবিল এবং রিফ্যাক্টর পর্যাপ্ত সময় না? আমি এখানে পুরো পথে ব্যর্থ গন্ধ করতে পারি।
অ্যাডাম ক্রসল্যান্ড

7
700 ইউএসইডি টেবিল বা 700 টেবিল যার মধ্যে অনেকগুলি অনাথ?
বেন ব্রোকা

1
@ অ্যাডামক্রসল্যান্ড সিরিয়াসলি ... লিনিার্ড স্কাইনার্ডের ওহ যে গন্ধ মাথায় আসে। তবে একটি গুরুতর নোটের ভিত্তিতে, ডেনারমালাইজড টেবিলগুলি কখনও কখনও পঠন-ভারী বা ডেটাবেজে ভারী প্রতিবেদনের ভারী ভারী নকশার পছন্দ।
maple_shaft

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

উত্তর:


21

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

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

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

শেষ পর্যন্ত, চটজলদি কেবল একটি শব্দ। আপনি প্রতিদিন কী করছেন তা নির্ধারণ করে যে আপনি সফল হবেন কি না।


2
কার্যকর চটপট প্রক্রিয়াটি হ'ল প্রকৃত অর্থে আরও সামনে কাজ করা উচিত কারণ প্রতিটি স্প্রিন্টের পরে কেবলমাত্র কার্যকরী সফ্টওয়্যার সরবরাহ করার ক্ষেত্রে বারবার ফোকাস। যদি সঠিকভাবে করা হয় তবে এটি সাফল্যের আরও ভাল সম্ভাবনার দিকে পরিচালিত করে। জলপ্রপাতটি আসলে আরও কার্যকর যদি আপনি ধরে নেন যে প্রয়োজনীয়তাগুলি স্থির এবং প্রকল্পের উত্সগুলি ভুল না করে। যদিও বেশিরভাগ পরিস্থিতিতে এটি ফ্যান্টাসি।
maple_shaft

1
@ ম্যাপেল_শ্যাফ্ট, ঠিক তেমন চটপটে হয়ে ওঠা পণ্য তৈরি থেকে কঠোর পরিশ্রম সরিয়ে দেয় না।
অ্যাডাম ক্রসল্যান্ড

2
আমার একটা অনুভূতি আছে যদি এই দলটি জলপ্রপাতের পদ্ধতির ব্যবহার করে থাকে তবে এটি ঠিক বিশৃঙ্খলাযুক্ত হবে এবং যে কোনও পরিবর্তনের অনুরোধটি একটি বিপর্যয় হবে।
জেফো

ঠিক বলেছেন, জেফ ও।
অ্যাডাম ক্রসল্যান্ড

11

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

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

একটি ডিবিএ সাহায্য করবে, কেবল নিশ্চিত করে নিন যে আপনি এমন একটি ডিবিএ পেয়েছেন যা বিকাশের পাশাপাশি সাফল্যের বিকাশকে বোঝে। আপনার উন্নয়ন দলের কারাগারে নিক্ষেপ করা উচিত নয়, জড়িত থাকা দরকার।


5

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

ভাল-লিখিত সফ্টওয়্যার খুব কমই সেই নতুন ডাটাবেস অবজেক্টগুলিকে লক্ষ্য করে, তাই কিছু টেবিলের নতুন কলামের কারণে কিছুই ভঙ্গ হয় না।

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


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

যথাযথভাবে। প্রচুর সংখ্যক টেবিল নিয়ে চিন্তা করবেন না, তাদের বেশিরভাগই যেভাবেই অব্যবহৃত এবং সম্ভবত সেগুলি শীঘ্রই বাদ দেওয়া হবে। এসসিএনআর
ব্যবহারকারী 281377

ঠিক আছে, সমস্যাটি হ'ল এগুলি সমস্তই ব্যবহৃত হয়, যদিও এটি কেবলমাত্র একটি রেকর্ডের জন্য।
rjzii

4

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

মন্তব্যের আলোকে - সাধারণত এগুলির প্রতিফলনটি হ'ল গুচ্ছ গুচ্ছ নিজেকে গুছিয়ে তোলে - চিৎকার চালান। ফাস্ট। Anddailywtf.com এ আপনি যা যা করতে পারেন তার সব পোস্ট করুন যাতে আমরা সকলেই আপনার ভয়াবহতা উপভোগ করতে পারি।


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

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

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

2
ইসস! সংস্করণ না !!! এতে অবাক হওয়ার কিছু নেই অ্যাপ কোডটি কেমন তা ভাবতে ভাবতে আমি কাঁপছি।
ozz

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

3

স্ট্যাকএক্সচেঞ্জের বেশিরভাগ উত্তরের মতো, উত্তরটি 'এটি নির্ভর করে' হওয়া উচিত। চতুর বিকাশে, প্রয়োগের সময় প্রয়োজনীয়তা এবং বিশদগুলি সন্ধান করা হয়।

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

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


চতুর প্রক্রিয়াটির কোন পর্যায়ে ভবিষ্যতের সমস্ত পরিবর্তনের অনুরোধগুলির জন্য সঠিক মডেলটি যাদুকরীভাবে উপস্থিত হয়?
জেফো

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

@ ডিবিবেক: এবং এরপরে আপনি এক্স, ওয়াই এবং জেড ক্ষেত্রে ইউরোপীয় ইউনিয়ন (২ 27 টি দেশ) কে একক দেশ হিসাবে বিবেচনা করা বা মার্কিন যুক্তরাষ্ট্রের দেশগুলিকে দেশ হিসাবে বিবেচনা করার মতো ব্যবসায়িক সমস্যাগুলি পেয়েছেন। বা ব্যবসায়ের উপলব্ধি যে কিছু ডিবি এন্ট্রিগুলিতে একক ঠিকানার জন্য 2 টি ঠিকানা উপস্থাপনা থাকে।
এমসাল্টাররা

3

আপনার প্রশ্নের উত্তর দেওয়ার জন্য, না, এটি একটি চপল প্রক্রিয়াতে স্বাভাবিক নয়।

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

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

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


2

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

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

এমনকি চতুরতার মধ্যেও, একটি বড় ব্যবস্থার জন্য, এখনও স্কিমার দায়িত্বে থাকা কোনও ব্যক্তির / দলকে রাখা খুব সাধারণ বিষয়।


2

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


2

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

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


1

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


5
ডাটাবেসগুলি কোড নয়, তবে স্কিমাটি হ'ল এবং এরূপ হিসাবে গণ্য করা উচিত। এটি সংস্করণ করা উচিত এবং উত্সটিও নিয়ন্ত্রণ করা উচিত। আমি এটিকে হ্রাস করতে চাই তবে আপনার উত্তরগুলির বাকিগুলির সাথে আমি খুব বেশি সম্মত।
maple_shaft

6
চটপটি কোডিং সম্পর্কে নয় । এটি সফ্টওয়্যার বিকাশ প্রক্রিয়া সম্পর্কে, যা কার্যত সফ্টওয়্যার যদি ডেটাবেসের উপর নির্ভর করে তবে ডেটাবেস অন্তর্ভুক্ত করে। এটি বলে, আমি আপনার এই দৃ with়তার সাথে একমত যে এগিলের অর্থ 'পরে কাজ করার পরিকল্পনা এখন করা উচিত নয়' does
এরিক কিং

@ ম্যাপেল_শ্যাফ্ট কেবল এই কারণে যে কোনও ডিবি স্কিমা কোডের মতো আচরণ করে এটি কোড তৈরি করে না। পোষা প্রাণীকে মানুষ হিসাবে বিবেচনা করা হয়, তবে এটি তাদের মানুষ করে না
রাইথাল

3
কিছু কোড হোক বা না হোক এটির পরিকল্পনা করা দরকার। একটি ডাটাবেস পরিবর্তন করার জন্য বিদ্যমান ডেটার বিবেচনার পাশাপাশি কোড পরিবর্তন করার মতো আচরণ করা উচিত। এটি আসলে আরও চিন্তাভাবনা এবং পরিকল্পনা নেয়।
জেফো

1

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

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

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