প্রথমে সত্য, বা কেন সিস্টেমটি ডাটাবেস কাঠামোর উপর ভিত্তি করে ডিজাইন করা দরকার

হে হাবর!

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

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

নিবন্ধটি উপর ভিত্তি করে লেখা হয়েছে একটি প্রশ্ন, স্ট্যাক ওভারফ্লোতে দেওয়া।

বিভাগে reddit উপর আকর্ষণীয় আলোচনা /r/java и /আর/প্রোগ্রামিং.

কোড প্রজন্ম

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

	for (Record2<String, String> record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на 
//   основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT 
 
       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ сгенерированные имена
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

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

সোর্স কোড জেনারেশন

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

এরকম অনেক কোড জেনারেটর আছে। উদাহরণ স্বরূপ, XJC XSD বা WSDL ফাইলের উপর ভিত্তি করে জাভা কোড তৈরি করতে পারে. নীতি সবসময় একই:

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

তদুপরি, অপ্রয়োজনীয়তা এড়াতে - এই জাতীয় উপস্থাপনা তৈরি করা প্রায় সবসময়ই যুক্তিযুক্ত।

টাইপ প্রদানকারী এবং টীকা প্রক্রিয়াকরণ

দ্রষ্টব্য: jOOQ-এর জন্য কোড তৈরির আরেকটি, আরও আধুনিক এবং নির্দিষ্ট পদ্ধতির মধ্যে টাইপ প্রদানকারীর ব্যবহার জড়িত, যেমন তারা F# এ প্রয়োগ করা হয়. এই ক্ষেত্রে, কোডটি কম্পাইলার দ্বারা তৈরি করা হয়, আসলে সংকলন পর্যায়ে। নীতিগতভাবে, এই ধরনের কোড সোর্স কোডের আকারে বিদ্যমান নেই। জাভাতে, একই রকম আছে, যদিও মার্জিত নয়, টুলস - এগুলি টীকা প্রসেসর, উদাহরণস্বরূপ, Lombok.

একটি নির্দিষ্ট অর্থে, প্রথম ক্ষেত্রের মতো এখানেও একই জিনিস ঘটে, ব্যতীত:

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

কোড জেনারেশনের সমস্যা কি?

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

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

অনেকেই বলবেন যে তাদের এই সব করার সময় নেই। তারা তাদের সুপার পণ্যের জন্য সময়সীমার উপর আছে. কোন একদিন পরে আমরা সমাবেশ কনভেয়ারদের চিরুনি দেব, আমাদের সময় হবে। আমি তাদের উত্তর দেব:

মূল, অ্যালান ও'রোর্ক, শ্রোতা স্ট্যাক

কিন্তু হাইবারনেট/জেপিএতে "জাভাতে" কোড লেখা এত সহজ।

সত্যিই. হাইবারনেট এবং এর ব্যবহারকারীদের জন্য, এটি একটি বর এবং অভিশাপ উভয়ই। হাইবারনেটে, আপনি কেবল কয়েকটি সত্তা লিখতে পারেন, যেমন:

	@Entity
class Book {
  @Id
  int id;
  String title;
}

এবং প্রায় সবকিছু প্রস্তুত। এখন হাইবারনেটের অনেকগুলি হল আপনার SQL এর "উপভাষা" এর DDL-এ ঠিক কীভাবে এই সত্তাকে সংজ্ঞায়িত করা হবে তার জটিল "বিশদ বিবরণ" তৈরি করা:

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

... এবং অ্যাপ্লিকেশন চালানো শুরু করুন. দ্রুত উঠতে এবং চালানোর জন্য এবং বিভিন্ন জিনিস চেষ্টা করার জন্য একটি সত্যিই দুর্দান্ত বৈশিষ্ট্য।

যাইহোক, আমাকে যাক. আমি মিথ্যা ছিল.

• হাইবারনেট কি আসলে এই নামের প্রাথমিক কীটির সংজ্ঞা কার্যকর করবে?
• হাইবারনেট কি TITLE এ একটি সূচক তৈরি করবে? আমি নিশ্চিতভাবে জানি আমাদের এটা দরকার।
• হাইবারনেট কি এই কীটিকে আইডেন্টিটি স্পেসিফিকেশনে একটি আইডেন্টিটি কী বানাবে?

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

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

কুল। পুনর্জন্ম। আবার, এই ক্ষেত্রে, এটি শুরুতে খুব সহজ হবে।

কিন্তু এর জন্য আপনাকে পরে টাকা দিতে হবে।

শীঘ্রই বা পরে আপনাকে উত্পাদনে যেতে হবে। তখনই মডেলটি কাজ করা বন্ধ করে দেয়। কারণ:

প্রোডাকশনে, পুরানো ডাটাবেস বাতিল করা এবং স্ক্র্যাচ থেকে সবকিছু শুরু করা প্রয়োজন হলে আর সম্ভব হবে না। আপনার ডাটাবেস একটি উত্তরাধিকার এক পরিণত হবে.

এখন থেকে এবং চিরকাল আপনাকে লিখতে হবে DDL মাইগ্রেশন স্ক্রিপ্ট, যেমন Flyway ব্যবহার করে. আর এক্ষেত্রে আপনার সত্ত্বার কী হবে? আপনি হয় সেগুলিকে ম্যানুয়ালি তৈরি করতে পারেন (এবং আপনার কাজের চাপ দ্বিগুণ করতে পারেন) অথবা হাইবারনেট আপনার জন্য সেগুলিকে পুনরায় জেনারেট করতে পারেন (আপনার প্রত্যাশা পূরণ করার জন্য এইভাবে তৈরি করা কতটা সম্ভব?) আপনি যে কোনও উপায়ে হেরে যাবেন৷

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

পরিবর্তে, প্রথম থেকেই, সবকিছু সম্পূর্ণ ভিন্নভাবে করা যেতে পারে। উদাহরণস্বরূপ, একটি সাইকেলে গোল চাকা রাখুন।

প্রথমে ডাটাবেস

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

এবং, যে সব না. উদাহরণস্বরূপ, ওরাকল ব্যবহার করে, আপনি সম্ভবত নির্দিষ্ট করতে চান:

• আপনার টেবিল কি টেবিলস্পেসে আছে
• তার PCTFREE মান কি?
• আপনার অনুক্রমে ক্যাশের আকার কত (আইডির পিছনে)

ছোট সিস্টেমে এই সমস্ত কিছু গুরুত্বপূর্ণ নাও হতে পারে, তবে "বিগ ডেটা" এর রাজ্যে রূপান্তর হওয়া পর্যন্ত অপেক্ষা করার প্রয়োজন নেই - আপনি বিক্রেতা-প্রদত্ত স্টোরেজ অপ্টিমাইজেশানগুলি থেকে উপকৃত হতে শুরু করতে পারেন, যেমন উপরে উল্লিখিতগুলি, অনেক আগে৷ আমি যে ORM দেখেছি (jOOQ সহ) তার কোনোটিই DDL বিকল্পের সম্পূর্ণ সেটে অ্যাক্সেস দেয় না যা আপনি আপনার ডাটাবেসে ব্যবহার করতে চাইতে পারেন। ORMগুলি আপনাকে DDL লিখতে সাহায্য করার জন্য কিছু সরঞ্জাম অফার করে।

কিন্তু দিনের শেষে, একটি সু-পরিকল্পিত স্কিমা DDL-এ হাতে লেখা হয়। যেকোন উত্পন্ন ডিডিএল এটির একটি আনুমানিক মাত্র।

ক্লায়েন্ট মডেল সম্পর্কে কি?

উপরে উল্লিখিত হিসাবে, ক্লায়েন্টে আপনার ডাটাবেস স্কিমা, ক্লায়েন্ট ভিউ এর একটি অনুলিপি প্রয়োজন। বলা বাহুল্য, এই ক্লায়েন্ট ভিউ অবশ্যই বাস্তব মডেলের সাথে সিঙ্ক হতে হবে। এই অর্জন করার জন্য সবচেয়ে ভাল উপায় কি? একটি কোড জেনারেটর সহ।

সমস্ত ডাটাবেস SQL এর মাধ্যমে তাদের মেটা-তথ্য প্রদান করে। আপনার ডাটাবেস থেকে বিভিন্ন SQL উপভাষায় সমস্ত টেবিল কিভাবে পেতে হয় তা এখানে:

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
 
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
 
-- Oracle
SELECT owner, table_name
FROM all_tables
 
-- SQLite
SELECT name
FROM sqlite_master
 
-- Teradata
SELECT databasename, tablename
FROM dbc.tables

এই ক্যোয়ারীগুলি (বা অনুরূপগুলি, আপনাকে ভিউ, ম্যাটেরিয়ালাইজড ভিউ, টেবিল-ভ্যালুড ফাংশনগুলিও বিবেচনা করতে হবে কিনা তার উপর নির্ভর করে) কল করে চালানো হয় DatabaseMetaData.getTables() JDBC থেকে, অথবা jOOQ মেটা-মডিউল ব্যবহার করে।

এই ধরনের প্রশ্নের ফলাফল থেকে, আপনার ডাটাবেস মডেলের ক্লায়েন্ট-সাইড উপস্থাপনা তৈরি করা তুলনামূলকভাবে সহজ, আপনি ক্লায়েন্টে যে প্রযুক্তি ব্যবহার করুন না কেন।

• আপনি যদি JDBC বা স্প্রিং ব্যবহার করেন তবে আপনি স্ট্রিং ধ্রুবকের একটি সেট তৈরি করতে পারেন
• আপনি যদি JPA ব্যবহার করেন, তাহলে আপনি নিজেরাই সত্তা তৈরি করতে পারেন
• আপনি যদি jOOQ ব্যবহার করেন তবে আপনি jOOQ মেটা মডেল তৈরি করতে পারেন

আপনার ক্লায়েন্ট API কতটা শক্তি অফার করে তার উপর নির্ভর করে (যেমন jOOQ বা JPA), জেনারেট করা মেটা মডেল সত্যিই সমৃদ্ধ এবং সম্পূর্ণ হতে পারে। উদাহরণস্বরূপ, অন্তর্নিহিত যোগদানের সম্ভাবনা নিন, jOOQ 3.11-এ চালু করা হয়েছে, যা আপনার টেবিলের মধ্যে বিদেশী কী সম্পর্ক সম্পর্কে জেনারেট করা মেটা-তথ্যের উপর নির্ভর করে।

এখন যেকোনো ডাটাবেস ইনক্রিমেন্ট স্বয়ংক্রিয়ভাবে ক্লায়েন্ট কোড আপডেট করবে। উদাহরণস্বরূপ কল্পনা করুন:

ALTER TABLE book RENAME COLUMN title TO book_title;

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

@Entity
@Table(name = "book", indexes = {
 
  // Вы об этом задумывались?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

অথবা আপডেট করা jOOQ ক্লাস। বেশিরভাগ DDL পরিবর্তন শব্দার্থবিদ্যাকেও প্রভাবিত করে, শুধু সিনট্যাক্স নয়। অতএব, আপনার ডাটাবেস বৃদ্ধির দ্বারা কোন কোডটি প্রভাবিত হবে (বা হতে পারে) সংকলিত কোডে এটি দেখতে সুবিধাজনক হতে পারে।

একমাত্র সত্য

আপনি যে প্রযুক্তি ব্যবহার করেন তা নির্বিশেষে, সর্বদা একটি মডেল থাকে যা কিছু সাবসিস্টেমের জন্য সত্যের একমাত্র উত্স - বা অন্তত আমাদের এটির জন্য প্রচেষ্টা করা উচিত এবং এন্টারপ্রাইজের বিভ্রান্তি এড়ানো উচিত যেখানে "সত্য" সর্বত্র এবং একযোগে কোথাও নেই। সবকিছু অনেক সহজ হতে পারে। আপনি যদি অন্য কোনও সিস্টেমের সাথে এক্সএমএল ফাইলগুলি বিনিময় করছেন তবে কেবল XSD ব্যবহার করুন। XML আকারে jOOQ-এর INFORMATION_SCHEMA মেটা-মডেল দেখুন:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD ভাল বোঝা যায়
• XSD XML বিষয়বস্তুকে খুব ভালভাবে চিহ্নিত করে এবং সমস্ত ক্লায়েন্ট ভাষায় যাচাইকরণের অনুমতি দেয়
• XSD ভাল সংস্করণ এবং অত্যন্ত পশ্চাদপদ সামঞ্জস্যপূর্ণ
• XSD XJC ব্যবহার করে জাভা কোডে অনুবাদ করা যেতে পারে

শেষ বিন্দু গুরুত্বপূর্ণ. XML বার্তা ব্যবহার করে একটি বহিরাগত সিস্টেমের সাথে যোগাযোগ করার সময়, আমরা নিশ্চিত হতে চাই যে আমাদের বার্তাগুলি বৈধ। এটি JAXB, XJC এবং XSD এর সাথে অর্জন করা খুব সহজ। এটা ভাবা নিছক উন্মাদনা হবে যে, একটি জাভা-প্রথম ডিজাইন পদ্ধতিতে যেখানে আমরা আমাদের বার্তাগুলিকে জাভা অবজেক্ট হিসাবে তৈরি করি, সেগুলিকে কোনওভাবে XML-এ বোধগম্যভাবে রেন্ডার করা যেতে পারে এবং অন্য সিস্টেমে ব্যবহারের জন্য পাঠানো যেতে পারে। এইভাবে উৎপন্ন XML হবে খুবই নিম্নমানের, অনথিভুক্ত, এবং বিকাশ করা কঠিন। যদি এই ধরনের একটি ইন্টারফেসে পরিষেবার মানের (SLA) স্তরের একটি চুক্তি থাকে, আমরা অবিলম্বে এটিকে স্ক্রু করব।

সত্যি কথা বলতে, JSON API এর সাথে সব সময় এটিই ঘটে, তবে এটি অন্য গল্প, আমি পরের বার তর্ক করব ...

ডাটাবেস: তারা একই

ডাটাবেসগুলির সাথে কাজ করে, আপনি বুঝতে পারেন যে তারা সবই মূলত একই। ডাটাবেস তার ডেটার মালিক এবং স্কিমা পরিচালনা করতে হবে। স্কিমাতে করা যেকোনো পরিবর্তন অবশ্যই সরাসরি DDL-এ প্রয়োগ করতে হবে যাতে সত্যের একক উৎস আপডেট করা হয়।

সোর্স আপডেট হয়ে গেলে, সমস্ত ক্লায়েন্টকে অবশ্যই তাদের মডেলের কপি আপডেট করতে হবে। কিছু ক্লায়েন্ট জাভাতে jOOQ এবং হাইবারনেট বা JDBC (বা উভয়ই) ব্যবহার করে লেখা হতে পারে। অন্যান্য ক্লায়েন্টদের পার্লে লেখা হতে পারে (আসুন তাদের ভাগ্য কামনা করি), অন্যরা C# এ। এটা কোন ব্যাপার না. মূল মডেলটি ডাটাবেসে রয়েছে। ORM-উত্পাদিত মডেলগুলি সাধারণত নিম্নমানের, খারাপভাবে নথিভুক্ত এবং বিকাশ করা কঠিন।

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

আমাকে এখনো ধন্যবাদ দিও না, পরে।

শোধন

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

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

ব্যতিক্রম

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

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

ব্যতিক্রম প্রকৃতির দ্বারা ব্যতিক্রমী. RDBMS-এর ব্যবহার জড়িত বেশিরভাগ ক্ষেত্রে, স্কিমাটি আগে থেকেই জানা যায়, এটি RDBMS-এর অভ্যন্তরে এবং এটিই "সত্য" এর একমাত্র উৎস এবং সমস্ত ক্লায়েন্টকে এটি থেকে প্রাপ্ত কপিগুলি অর্জন করতে হয়। আদর্শভাবে, এটি একটি কোড জেনারেটর জড়িত করা উচিত.

উত্স: www.habr.com