سچ پهريون، يا ڇو سسٽم کي ڊيٽابيس ڊيوائس جي بنياد تي ڊزائين ڪرڻ جي ضرورت آهي

اي حبر!

اسان موضوع تي تحقيق جاري رکون ٿا جاوا и بهار جي، بشمول ڊيٽابيس جي سطح تي. اڄ اسان توهان کي پڙهڻ جي دعوت ڏيون ٿا ته ڇو، وڏي ايپليڪيشنن کي ڊزائين ڪرڻ وقت، اهو ڊيٽابيس جي جوڙجڪ آهي، ۽ جاوا ڪوڊ نه، اهو فيصلو ڪندڙ اهميت وارو هجڻ گهرجي، اهو ڪيئن ڪجي، ۽ هن قاعدي ۾ ڪهڙا استثنا آهن.

هن دير سان آرٽيڪل ۾، مان وضاحت ڪندس ته ڇو مان سمجهان ٿو ته تقريبن سڀني صورتن ۾، هڪ ايپليڪيشن ۾ ڊيٽا ماڊل "ڊيٽابيس مان" جي بدران "جاوا جي صلاحيتن مان" (يا جيڪا به ڪلائنٽ ٻولي توهان آهيو. سان ڪم ڪرڻ). ٻيو طريقو کڻڻ سان، توهان پنهنجو پاڻ کي ترتيب ڏئي رهيا آهيو درد ۽ مصيبت جي ڊگهي رستي لاء هڪ دفعو توهان جو منصوبو وڌڻ شروع ٿئي ٿو.

مضمون جي بنياد تي لکيو ويو هڪ سوال، ڏنل اسٽيڪ اوور فلو تي.

سيڪشن ۾ reddit تي دلچسپ بحث /r/java и /r/پروگرامنگ.

ڪوڊ نسل

مون کي ڪيترو تعجب ٿيو ته اتي استعمال ڪندڙن جو ھڪڙو ننڍڙو حصو آھي، جيڪي 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)) {
    // ...
}

ڪوڊ يا ته دستي طور تي اسيمبليءَ کان ٻاهر، يا دستي طور تي هر اسيمبليءَ ۾ ٺاهيو ويندو آهي. مثال طور، اهڙي ٻيهر پيدا ٿيڻ کان پوء فوري طور تي عمل ڪري سگھي ٿو Flyway ڊيٽابيس لڏپلاڻ، جيڪو پڻ دستي طور تي يا خودڪار طريقي سان ڪري سگهجي ٿو.

ماخذ ڪوڊ نسل

اهڙا ڪيترائي فلسفا، فائدا ۽ نقصانات آهن جيڪي انهن طريقن سان جڙيل آهن ڪوڊ جنريشن - دستي ۽ خودڪار - جيڪي آئون هن مضمون ۾ تفصيل سان بحث ڪرڻ وارو نه آهيان. پر، عام طور تي، ٺاهيل ڪوڊ جو سڄو نقطو اهو آهي ته اهو اسان کي جاوا ۾ ٻيهر پيدا ڪرڻ جي اجازت ڏئي ٿو ته "سچ" جيڪو اسان کي ڏني وئي آهي، يا ته اسان جي سسٽم جي اندر يا ان کان ٻاهر. هڪ لحاظ کان، هي اهو آهي جيڪو مرتب ڪندڙ ڪندا آهن جڏهن اهي ٺاهيندا آهن بائيٽ ڪوڊ، مشين ڪوڊ، يا سورس ڪوڊ جو ڪو ٻيو روپ - اسان کي ڪنهن ٻئي ٻوليءَ ۾ اسان جي ”سچ“ جي نمائندگي ملي ٿي، قطع نظر خاص سببن جي.

اهڙا ڪيترائي ڪوڊ جنريٽر آهن. مثال طور، XJC XSD يا WSDL فائلن جي بنياد تي جاوا ڪوڊ ٺاهي سگھي ٿو. اصول هميشه ساڳيو آهي:

• اتي ڪجھ سچ آھي (اندروني يا بيروني) - مثال طور، ھڪڙي وضاحت، ھڪڙو ڊيٽا ماڊل، وغيره.
• اسان کي اسان جي پروگرامنگ ٻولي ۾ هن سچ جي مقامي نمائندگي جي ضرورت آهي.

ان کان علاوه، اهو تقريبا هميشه صلاح ڏني وئي آهي ته اهڙي نمائندگي پيدا ڪرڻ لاء بيڪارگي کان بچڻ لاء.

قسم فراهم ڪندڙ ۽ تشريح پروسيسنگ

نوٽ: jOOQ لاءِ ڪوڊ پيدا ڪرڻ لاءِ ٻيو، وڌيڪ جديد ۽ مخصوص طريقو قسم فراهم ڪندڙ استعمال ڪري رهيو آهي، جيئن اهي F# ۾ لاڳو ڪيا ويا آهن. انهي صورت ۾، ڪوڊ ٺاهيل آهي مرتب ڪندڙ طرفان، اصل ۾ تاليف واري مرحلي ۾. اصول ۾، اهڙي ڪوڊ ماخذ فارم ۾ موجود نه آهي. جاوا ۾ ساڳيو آهي، جيتوڻيڪ خوبصورت نه، اوزار - تشريح پروسيسر، مثال طور، Lombok.

هڪ لحاظ کان، هتي ساڳيون شيون ٿين ٿيون جيئن پهرين صورت ۾، سواءِ هن جي:

• توهان ٺاهيل ڪوڊ نه ٿا ڏسو (شايد اها صورتحال ڪنهن کي گهٽ ناپسنديده لڳي؟)
• توھان کي پڪ ڪرڻ گھرجي ته قسمون مهيا ڪري سگھجن ٿيون، اھو آھي، "سچو" ھميشه موجود ھجڻ گھرجي. اهو لومبوڪ جي صورت ۾ آسان آهي، جيڪو "سچ" کي بيان ڪري ٿو. اهو ڊيٽابيس ماڊلز سان ٿورڙو وڌيڪ پيچيده آهي جيڪو مستقل طور تي موجود لائيو ڪنيڪشن تي منحصر هوندو آهي.

ڪوڊ پيدا ڪرڻ سان مسئلو ڇا آهي؟

ان کان علاوه مشڪل سوال کان علاوه ڪيئن بهترين طريقي سان ڪوڊ نسل کي هلائڻ لاء - دستي طور تي يا خودڪار طور تي، اسان کي اهو به ذڪر ڪرڻو پوندو ته اهڙا ماڻهو آهن جيڪي يقين ڪن ٿا ته ڪوڊ نسل جي ضرورت ناهي. هن نقطي نظر جو جواز، جيڪو مون کي اڪثر نظر آيو، اهو آهي ته پوء هڪ تعميراتي پائپ لائن قائم ڪرڻ ڏکيو آهي. ها، اهو واقعي ڏکيو آهي. اضافي انفراسٽرڪچر جي قيمت پيدا ٿئي ٿي. جيڪڏهن توهان صرف هڪ خاص پراڊڪٽ سان شروعات ڪري رهيا آهيو (ڇا اهو آهي jOOQ، يا JAXB، يا Hibernate، وغيره)، هڪ پيداواري ماحول قائم ڪرڻ ۾ وقت لڳندو آهي ته توهان بجاءِ خود API کي سکڻ ۾ خرچ ڪندا ته جيئن توهان ان مان قيمت ڪڍي سگهو. .

جيڪڏهن جنريٽر جي ڍانچي کي سمجهڻ سان لاڳاپيل لاڳاپا تمام وڏا آهن، ته پوءِ، حقيقت ۾، API ڪوڊ جنريٽر جي استعمال تي خراب ڪم ڪيو آهي (۽ بعد ۾ اهو ظاهر ٿئي ٿو ته ان ۾ صارف جي ڪسٽمائيزيشن پڻ ڏکيو آهي). ڪنهن به اهڙي API لاءِ استعمال کي اعليٰ ترجيح هجڻ گهرجي. پر هي ڪوڊ نسل جي خلاف صرف هڪ دليل آهي. ٻي صورت ۾، اندروني يا بيروني سچائي جي مقامي نمائندگي لکڻ بلڪل مڪمل طور تي دستياب آهي.

ڪيترائي چون ٿا ته انهن وٽ اهو سڀ ڪجهه ڪرڻ جو وقت ناهي. اهي پنهنجي سپر پراڊڪٽ لاءِ آخري حدن کان ٻاهر آهن. ڪنهن ڏينهن اسان اسيمبليءَ جي ڪنوينر کي صاف ڪنداسين، اسان وٽ وقت هوندو. مان انهن کي جواب ڏيندس:

اصل, الان O'Rourke، سامعين اسٽيڪ

پر Hibernate/JPA ۾ جاوا ڪوڊ لکڻ تمام آسان آهي.

واقعي. Hibernate ۽ ان جي استعمال ڪندڙن لاء، هي هڪ نعمت ۽ لعنت آهي. Hibernate ۾ توهان صرف ڪجهه ادارا لکي سگهو ٿا، جهڙوڪ:

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

۽ لڳ ڀڳ هر شيء تيار آهي. ھاڻي اھو Hibernate تي آھي پيچيده ”تفصيل“ پيدا ڪرڻ لاءِ ته توھان جي SQL ”ڊليڪٽ“ جي ڊي ڊي ايل ۾ ھي ادارو ڪيئن بيان ڪيو ويندو:

	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);

... ۽ ايپليڪيشن کي هلائڻ شروع ڪريو. جلدي شروع ڪرڻ ۽ مختلف شين جي ڪوشش ڪرڻ جو هڪ بهترين موقعو.

بهرحال، مهرباني ڪري مون کي اجازت ڏيو. مان ڪوڙ ڳالهائي رهيو هوس.

• ڇا Hibernate اصل ۾ هن نالي جي پرائمري ڪي جي تعريف کي لاڳو ڪندو؟
• ڇا Hibernate TITLE ۾ هڪ انڊيڪس ٺاهيندو؟ - مان پڪ ڄاڻان ٿو ته اسان کي ان جي ضرورت پوندي.
• ڇا Hibernate صحيح طور تي سڃاڻپ جي وضاحت ۾ هن اهم جي سڃاڻپ ڪندو؟

شايد نه. جيڪڏھن توھان پنھنجي پروجيڪٽ کي شروع کان ترقي ڪري رھيا آھيو، اھو ھميشه آسان آھي صرف پراڻي ڊيٽابيس کي رد ڪرڻ ۽ ھڪڙو نئون ٺاھيو جيئن توھان ضروري تشريح شامل ڪريو. اهڙيء طرح، ڪتاب جو ادارو آخرڪار فارم وٺندو:

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

عمده. ٻيهر پيدا ڪرڻ. ٻيهر، انهي صورت ۾ اهو شروع ۾ تمام آسان ٿيندو.

پر توهان کي بعد ۾ ان لاء ادا ڪرڻو پوندو

جلدي يا بعد ۾ توهان کي پيداوار ۾ وڃڻو پوندو. اهو آهي جڏهن هي ماڊل ڪم ڪرڻ بند ڪري ڇڏيندو. ڇاڪاڻ ته:

پيداوار ۾، اهو هاڻي ممڪن نه ٿيندو، جيڪڏهن ضروري هجي ته، پراڻي ڊيٽابيس کي رد ڪرڻ ۽ شروع کان شروع ڪرڻ. توهان جو ڊيٽابيس ورثي بڻجي ويندو.

ھاڻي ھاڻي ۽ ھميشه توھان کي لکڻو پوندو DDL لڏپلاڻ اسڪرپٽ، مثال طور، Flyway استعمال ڪندي. ان صورت ۾ توهان جي ادارن جو ڇا ٿيندو؟ توهان يا ته انهن کي دستي طور تي ترتيب ڏئي سگهو ٿا (۽ اهڙي طرح توهان جي ڪم جي لوڊ کي ٻيڻو) ڪري سگهو ٿا، يا توهان Hibernate کي چئي سگهو ٿا انهن کي توهان جي لاءِ ٻيهر پيدا ڪرڻ لاءِ (ڪيترا ممڪن آهن جيڪي توهان جي اميدن کي پورو ڪرڻ لاءِ هن طريقي سان پيدا ڪيا ويا آهن؟) يا ته ، توهان وڃائي سگهو ٿا.

تنهنڪري هڪ دفعو توهان پيداوار ۾ حاصل ڪيو توهان کي گرم پيچ جي ضرورت پوندي. ۽ انهن کي تمام جلدي پيداوار ۾ رکڻ جي ضرورت آهي. جيئن ته توهان تيار نه ڪيو آهي ۽ پيداوار لاءِ توهان جي لڏپلاڻ جي هڪ هموار پائيپ لائين کي منظم نه ڪيو آهي، توهان جهنگلي طور تي هر شي کي پيچ ڪيو. ۽ پوء توهان وٽ هاڻي وقت نه آهي هر شي کي صحيح ڪرڻ لاء. ۽ توهان Hibernate تي تنقيد ڪريو ٿا، ڇو ته اهو هميشه ڪنهن ٻئي جي غلطي آهي، صرف توهان نه ...

ان جي بدران، شيون شروع کان بلڪل مختلف ٿي سگھن ٿيون. مثال طور، هڪ سائيڪل تي گول ڦيٿي وجهي.

پهريون ڊيٽابيس

توهان جي ڊيٽابيس جي اسڪيما ۾ حقيقي "سچ" ۽ ان تي "خودمختاري" ڊيٽابيس جي اندر آهي. اسڪيما جي وضاحت صرف ڊيٽابيس ۾ ڪئي وئي آهي ۽ ٻيو ڪٿي به نه، ۽ هر ڪلائنٽ وٽ هن اسڪيما جي هڪ ڪاپي آهي، تنهنڪري اهو صحيح سمجهه ۾ اچي ٿو ته اسڪيما ۽ ان جي سالميت جي تعميل کي لاڳو ڪرڻ، ان کي ڊيٽابيس ۾ درست ڪرڻ لاءِ - جتي معلومات آهي. ذخيرو ٿيل.
اها پراڻي آهي، حتي هيڪني حڪمت. پرائمري ۽ منفرد ڪنجيون سٺيون آهن. پرڏيهي ڪنجيون سٺيون آهن. پابنديون چيڪ ڪرڻ سٺو آهي. دعوائون - چڱو.

ان کان سواء، اهو سڀ ڪجهه ناهي. مثال طور، Oracle استعمال ڪندي، توهان شايد وضاحت ڪرڻ چاهيندا:

• توهان جي ٽيبل ڪهڙي ٽيبل اسپيس ۾ آهي؟
• ان جي PCTFREE قدر ڇا آهي؟
• توهان جي ترتيب ۾ ڪيش سائيز ڇا آهي (ID جي پويان)

اهو شايد ننڍن سسٽم ۾ اهم نه هجي، پر توهان کي انتظار ڪرڻ جي ضرورت ناهي جيستائين توهان وڏي ڊيٽا جي دائري ۾ نه وڃو- توهان وينڊرز طرفان فراهم ڪيل اسٽوريج جي اصلاحن مان فائدو حاصل ڪرڻ شروع ڪري سگهو ٿا جهڙوڪ مٿي ذڪر ڪيل گهڻو جلدي. ڪو به ORM جيڪي مون نه ڏٺو آهي (جنهن ۾ jOOQ شامل آهن) DDL اختيارن جي مڪمل سيٽ تائين رسائي فراهم ڪن ٿا جيڪي توهان پنهنجي ڊيٽابيس ۾ استعمال ڪرڻ چاهيو ٿا. ORMs پيش ڪن ٿا ڪجھ اوزار جيڪي توھان جي مدد ڪن ٿا 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;

ڇا توهان واقعي هن نوڪري کي ٻه ڀيرا ڪرڻ چاهيندا؟ ڪنهن به صورت ۾. بس ڊي ڊي ايل کي انجام ڏيو، ان کي پنهنجي تعميراتي پائپ لائن ذريعي هلائي، ۽ تازه ڪاري ادارو حاصل ڪريو:

@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 ڪلاس. گهڻيون ڊي ڊي ايل تبديليون پڻ سيمينٽڪس تي اثر انداز ڪن ٿيون، نه رڳو نحو. تنهن ڪري، اهو ڪارائتو ٿي سگهي ٿو مرتب ڪيل ڪوڊ ۾ ڏسڻ لاءِ ته ڪهڙو ڪوڊ متاثر ٿيندو (يا ٿي سگهي ٿو) توهان جي ڊيٽابيس جي واڌ سان.

صرف سچ

قطع نظر ته توهان ڪهڙي ٽيڪنالاجي استعمال ڪندا آهيو، اتي هميشه هڪ ماڊل هوندو آهي جيڪو سچ جو واحد ذريعو آهي ڪجهه سب سسٽم لاءِ - يا، گهٽ ۾ گهٽ، اسان کي ان لاءِ ڪوشش ڪرڻ گهرجي ۽ اهڙي ڪاروباري مونجهاري کان پاسو ڪرڻ گهرجي، جتي ”سچ“ هر جاءِ تي آهي ۽ ڪٿي به هڪ ڀيرو. . هر شي تمام گهڻو آسان ٿي سگهي ٿو. جيڪڏهن توهان صرف XML فائلن کي ڪنهن ٻئي سسٽم سان مٽائي رهيا آهيو، صرف XSD استعمال ڪريو. ڏسو INFORMATION_SCHEMA ميٽا ماڊل jOOQ کان XML فارم ۾:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD چڱي طرح سمجھي وئي آھي
• XSD تمام چڱي طرح XML مواد کي ٽوڪنائيز ڪري ٿو ۽ سڀني ڪلائنٽ ٻولين ۾ تصديق جي اجازت ڏئي ٿو
• XSD سٺو نسخو آهي ۽ ترقي يافته پسمانده مطابقت آهي
• XJC استعمال ڪندي XSD جاوا ڪوڊ ۾ ترجمو ڪري سگھجي ٿو

آخري نقطو اهم آهي. جڏهن ايڪس ايم ايل پيغامن کي استعمال ڪندي هڪ خارجي سسٽم سان رابطو ڪري، اسان کي پڪ ڪرڻ چاهيون ٿا ته اسان جا پيغام صحيح آهن. اهو JAXB، XJC ۽ XSD استعمال ڪندي حاصل ڪرڻ بلڪل آسان آهي. اهو سوچڻ سراسر چريو هوندو ته، ”جاوا فرسٽ“ ڊيزائن واري طريقي سان، جتي اسان پنهنجا پيغام جاوا آبجڪس جي طور تي ٺاهيندا آهيون، ته اهي ڪنهن به طريقي سان XML تي ميپ ڪري سگهجن ٿيون ۽ استعمال لاءِ ٻئي سسٽم ڏانهن موڪليا وڃن ٿا. هن طريقي سان ٺاهيل XML تمام خراب معيار، غير دستاويزي، ۽ ترقي ڪرڻ ڏکيو هوندو. جيڪڏهن اهڙي انٽرفيس لاءِ ڪو سروس ليول معاهدو (SLA) هجي ها، ته اسان ان کي فوري طور ختم ڪري ڇڏينداسين.

ايمانداري سان، اهو آهي جيڪو هر وقت JSON APIs سان ٿئي ٿو، پر اها ٻي ڪهاڻي آهي، مان ايندڙ وقت تي تڪرار ڪندس ...

ڊيٽابيس: اهي ساڳيا آهن

جڏهن ڊيٽابيس سان ڪم ڪري رهيا آهيو، توهان محسوس ڪيو ته اهي سڀئي بنيادي طور تي ساڳيا آهن. بنيادي طور تي ان جي ڊيٽا جو مالڪ آهي ۽ اسڪيم کي منظم ڪرڻ گهرجي. اسڪيما ۾ ڪيل ڪي به ترميمون سڌو سنئون DDL ۾ لاڳو ٿيڻ گهرجن ته جيئن سچ جو واحد ذريعو اپڊيٽ ڪيو وڃي.

جڏهن هڪ ذريعو اپڊيٽ ٿي چڪو آهي، سڀني مراجعين کي پڻ انهن جي ماڊل جي نقلن کي اپڊيٽ ڪرڻ گهرجي. ڪجھ ڪلائنٽ جاوا ۾ jOOQ ۽ Hibernate يا JDBC (يا ٻئي) استعمال ڪندي لکي سگھجن ٿا. ٻيا گراهڪ پرل ۾ لکي سگهجن ٿا (اسان صرف انهن کي سٺي قسمت چاهيون ٿا)، جڏهن ته ٻيا سي # ۾ لکي سگهجن ٿا. هن سان فرق نٿو پئي. بنيادي ماڊل ڊيٽابيس ۾ آهي. ORMs استعمال ڪندي ٺاهيل ماڊل عام طور تي ناقص معيار جا، ناقص دستاويزي، ۽ ترقي ڪرڻ مشڪل هوندا آهن.

تنهنڪري غلطيون نه ڪريو. شروعات کان ئي غلطيون نه ڪريو. ڊيٽابيس مان ڪم ڪريو. ھڪڙي ٺاھڻ واري پائپ لائن ٺاھيو جيڪا خودڪار ٿي سگھي ٿي. ڪوڊ جنريٽر کي فعال ڪريو ان کي آسان بڻائڻ لاءِ توھان جي ڊيٽابيس ماڊل کي نقل ڪرڻ ۽ ان کي ڪلائنٽ تي ڊمپ ڪريو. ۽ ڪوڊ جنريٽر بابت پريشان ٿيڻ بند ڪريو. اهي سٺا آهن. انهن سان گڏ توهان وڌيڪ پيداوار بڻجي ويندا. توهان کي صرف شروعات کان ئي انهن کي ترتيب ڏيڻ ۾ ٿورو وقت گذارڻ جي ضرورت آهي - ۽ پوءِ وڌندڙ پيداوار جا سال توهان جو انتظار ڪندا ، جيڪي توهان جي منصوبي جي تاريخ ٺاهيندا.

اڃان تائين مون کي مهرباني نه ڪريو، بعد ۾.

وضاحت

واضح ٿيڻ لاءِ: هي آرٽيڪل ڪنهن به طريقي سان وڪيل نٿو ڪري ته توهان کي پوري نظام کي موڙڻ جي ضرورت آهي (يعني ڊومين، ڪاروباري منطق، وغيره وغيره) توهان جي ڊيٽابيس جي ماڊل کي پورو ڪرڻ لاءِ. جيڪو مان هن آرٽيڪل ۾ چئي رهيو آهيان اهو آهي ته ڪلائنٽ ڪوڊ جيڪو ڊيٽابيس سان رابطو ڪري ٿو ان کي ڊيٽابيس ماڊل جي بنياد تي عمل ڪرڻ گهرجي، انهي ڪري ته اهو خود ڊيٽابيس ماڊل کي "فرسٽ ڪلاس" جي حيثيت ۾ ٻيهر پيدا نٿو ڪري. هي منطق عام طور تي توهان جي ڪلائنٽ تي ڊيٽا جي رسائي جي پرت تي واقع آهي.

ٻن سطحن جي تعميرات ۾، جيڪي اڃا تائين ڪجهه هنڌن تي محفوظ آهن، اهڙي نظام جو نمونو صرف ممڪن آهي. بهرحال، اڪثر سسٽم ۾ ڊيٽا جي رسائي واري پرت مون کي لڳي ٿو "سب سسٽم" جيڪو ڊيٽابيس ماڊل کي گڏ ڪري ٿو.

استقبال

هر قاعدي ۾ استثنا آهن، ۽ مون اڳ ۾ ئي چيو آهي ته ڊيٽابيس-پهريون ۽ ماخذ-ڪوڊ پيدا ڪرڻ جو طريقو ڪڏهن ڪڏهن نامناسب ٿي سگهي ٿو. هتي اهڙا ٻه استثنا آهن (شايد ٻيا به آهن):

• جڏهن اسڪيما نامعلوم آهي ۽ دريافت ڪرڻ جي ضرورت آهي. مثال طور، توهان هڪ اوزار جو مهيا ڪندڙ آهيو جيڪو مدد ڪري ٿو صارفين کي ڪنهن به ڊراگرام کي نيويگيٽ ڪرڻ ۾. اوڇ. هتي ڪو به ڪوڊ نسل نه آهي. پر اڃا تائين، ڊيٽابيس پهرين اچي ٿو.
• جڏهن ڪجهه مسئلو حل ڪرڻ لاءِ اڏام تي سرڪٽ پيدا ٿيڻ گهرجي. اهو مثال نموني جي ٿورڙي شاندار نسخي وانگر لڳي ٿو entity وصف قدر، يعني، توهان وٽ حقيقت ۾ واضح طور تي بيان ڪيل اسڪيم نه آهي. انهي حالت ۾، توهان اڪثر ڪري پڪ نه ٿا ڪري سگهو ته هڪ RDBMS توهان کي مناسب ڪندو.

استثنا فطرت طرفان غير معمولي آهن. اڪثر ڪيسن ۾ RDBMS جو استعمال شامل آهي، اسڪيما اڳ ۾ ڄاڻايل آهي، اهو RDBMS جي اندر رهي ٿو ۽ "سچ" جو واحد ذريعو آهي، ۽ سڀني گراهڪن کي ان مان نڪتل ڪاپيون حاصل ڪرڻ گهرجن. مثالي طور، توهان کي ڪوڊ جنريٽر استعمال ڪرڻ جي ضرورت آهي.

جو ذريعو: www.habr.com