ডাটাবেসে ডোমেন মডেলগুলি কি টেকসই সমাধান হতে পারে?


13

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

আমাকে সবচেয়ে বেশি কীভাবে বাগগিজ দিচ্ছে তা হল কীভাবে আমাদের মূল ডাটাবেস বিকাশকারী (যেহেতু "জন" নামে পরিচিত) ডাটাবেজে মডেল স্কিমা রাখে! আমরা 3 টি "যাদু" সারণী রেখে এটি করি; ডাটাবেস-স্কিমার জন্য একটি, টেবিলের জন্য একটি এবং কলামের জন্য একটি

" টেবিলগুলি " -টি টেবিলের মধ্যে একটি রেকর্ড সন্নিবেশ করা (একটি ডাটাবেস ট্রিগার মাধ্যমে), প্রকৃত, সম্পর্কিত টেবিল। " সারিগুলিতে " একটি সারি সন্নিবেশ করা- টেবিলটি সেই সারিটির সাথে রেফারেন্সযুক্ত সারণি আপডেট করে। এগুলি ঘুরেফিরে সি # মডেল তৈরির জন্য তার ঘরের তৈরি সি #-প্রোগ্রামাম দ্বারা পঠিত রয়েছে, যা সীমানা-বিকাশকারীরা নিয়ন্ত্রণকারী এবং বাহিরের জন্য ব্যবহার করেন।

এ ছাড়া বেশিরভাগ উন্নয়ন এএসপি.এনইটি এমভিসি কাঠামো অনুযায়ী হয় ।

আমি এই পদ্ধতির সাথে বেশ কয়েকটি ত্রুটি দেখতে পাচ্ছি:

  • ওআরএম বজায় রাখার জন্য আমাদের তার দরকার, এবং এটি করার খুব কম সময়ই তাঁর হাতে রয়েছে (কাজের সুরক্ষা ভাল!)
  • "সারণী" এবং "সারি" সারণির জন্য ট্রিগারগুলি ত্রুটিযুক্ত। তারা টেবিল আপডেটগুলি বা চেক-সীমাবদ্ধতা বা আরও "উন্নত" বৈশিষ্ট্যগুলিকে সমর্থন করে না। যদিও আমরা অবশ্যই তাদের উন্নতি করতে পেরেছি, এখনও নিশ্চিত নই যে এটি যাওয়ার উপায় কিনা।
  • ডাটাবেসে প্রোগ্রাম্যাটিক যুক্তি রাখা অদ্ভুত এবং সীমাবদ্ধ মনে হয় (যদিও এটি সি # এর মাধ্যমে তার মডেলগুলি প্রসারিত করা সম্ভব))
  • তার সি # মডেল-জেনারেটরটি 3 জনের একজনের মধ্যে ম্যানুয়ালি চালিত করতে হবে (যার মধ্যে আমি একজন) এবং এখনও স্বয়ংক্রিয় বিল্ড প্রক্রিয়াতে অন্তর্ভুক্ত হওয়ার মতো যথেষ্ট পরিপক্ক হয়ে উঠেনি।

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

এই পোস্টটি এমন কিছু দিকে নিয়ে যাচ্ছে যা একটি মতামতপূর্ণ আলোচনার মতো দেখতে পারে তবে এটি আমার উদ্দেশ্য নয়। আমি কেবল আমাদের স্থাপত্য পদ্ধতির বিষয়ে কিছু স্পষ্টতা চাই।

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


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

"ডাটাবেসে প্রোগ্রাম্যাটিক যুক্তি রেখে" আপনি কী বোঝাতে চেয়েছেন তা সম্পর্কে আমি কিছুটা অস্পষ্ট। আপনি কি তা পরিষ্কার করতে পারেন?
রবার্ট হার্ভে

কোডে ব্যবসায়ের যুক্তি ঠিক সঠিক উপায়ে। ডিবি বোবা ডেটাস্টোর হওয়া উচিত, অন্য কিছু নয়।
অ্যান্ডি

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

@ ভ্লাদিস্লাভস্ট্রাস্নি যে কারণেই হোক না কেন, ব্যবসায় যুক্তি যুক্তিকে ডিবিতে রাখা একটি অত্যন্ত দুর্বল নকশা।
অ্যান্ডি

উত্তর:


16

আপনি একটি অভ্যন্তরীণ প্ল্যাটফর্ম বর্ণনা করছেন

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

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

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

আরও পঠন
"দৃষ্টি" প্রকল্প, অভ্যন্তরীণ প্ল্যাটফর্মের প্রভাব সম্পর্কে একটি সতর্কতামূলক কাহিনী
(আপনি উপস্থাপনাটি এড়িয়ে যেতে পারেন এবং "উপস্থাপনের দৃষ্টি উপস্থাপনা" এ পড়া শুরু করতে পারেন)


2
আকর্ষণীয় পড়া, আমি অবশ্যই anolog আঁকতে পারে। আমি এখনও নতুন এবং আমি আপাতত দর্শকের কাছে থেকে যাব, তবে আমি অবশ্যই এটিকে লেন্সের নীচে রাখব। একটি ভাল প্রতিক্রিয়া জন্য ধন্যবাদ!
Krystah
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.