حقیقت لومړی، یا ولې سیسټم اړتیا لري د ډیټابیس وسیلې پراساس ډیزاین شي

اې حبره!

موږ د موضوع څیړنې ته دوام ورکوو جاوا и د پسرليپه شمول د ډیټابیس په کچه. نن ورځ موږ تاسو ته بلنه درکوو چې د دې په اړه ولولئ چې ولې، کله چې د لوی غوښتنلیکونو ډیزاین کول، دا د ډیټابیس جوړښت دی، او د جاوا کوډ نه، دا باید پریکړه کونکي اهمیت ولري، دا څنګه ترسره کیږي، او پدې قاعده کې کوم استثناوې شتون لري.

پدې ناوخته مقاله کې ، زه به تشریح کړم چې ولې زه باور لرم چې په نږدې ټولو قضیو کې ، په غوښتنلیک کې د ډیټا ماډل باید د "جاوا له وړتیاو" پرځای "د ډیټابیس څخه" ډیزاین شي (یا هر هغه پیرودونکي ژبه چې تاسو یې یاست. سره کار کوي). د دویمې تګلارې په اخیستلو سره، تاسو خپل ځان د درد او کړاو د اوږدې لارې لپاره تنظیم کوئ کله چې ستاسو پروژه وده پیل کړي.

مقاله پر بنسټ لیکل شوې وه یوه پوښتنه، په Stack Overflow کې ورکړل شوی.

په برخو کې د ریډیټ په اړه په زړه پوري بحثونه /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# کې پلي کیږي. په دې حالت کې، کوډ د کمپیلر لخوا تولید شوی، په حقیقت کې د تالیف په مرحله کې. په اصل کې، دا ډول کوډ د سرچینې په بڼه شتون نلري. جاوا ورته لري، که څه هم په زړه پورې نه وي، وسیلې - د تشریح پروسیسرونه، د بیلګې په توګه، ګشنیزو.

په یو معنی، ورته شیان دلته پیښیږي لکه په لومړي حالت کې، د استثنا سره:

• تاسو تولید شوی کوډ نه ګورئ (شاید دا وضعیت د یو چا لپاره لږ ځورونکي ښکاري؟)
• تاسو باید ډاډ ترلاسه کړئ چې ډولونه چمتو کیدی شي، دا دی، "ریښتیا" باید تل شتون ولري. دا د لومبوک په قضیه کې اسانه ده، کوم چې "حقیقت" تشریح کوي. دا د ډیټابیس ماډلونو سره یو څه ډیر پیچلی دی چې په دوامداره توګه موجود ژوندۍ اړیکې پورې اړه لري.

د کوډ تولید سره ستونزه څه ده؟

د دې پیچلي پوښتنې سربیره چې څنګه د کوډ تولید غوره کولو لپاره - په لاسي یا اتوماتیک ډول ، موږ باید یادونه وکړو چې داسې خلک شتون لري چې باور لري د کوډ تولید هیڅ اړتیا نلري. هغه دلیل چې ما ډیری وختونه لیدلی دی دا دی چې د ساختماني پایپ لاین تنظیم کول ستونزمن دي. هو، دا واقعیا ستونزمنه ده. د زیربنا اضافي لګښتونه رامینځته کیږي. که تاسو یوازې د یو ځانګړي محصول سره پیل کوئ (که دا jOOQ وي، یا JAXB، یا Hibernate، او نور)، د تولید چاپیریال رامینځته کول وخت نیسي چې تاسو د API په زده کړه کې مصرف کوئ نو تاسو کولی شئ له هغې څخه ارزښت راوباسئ. .

که چیرې د جنراتور جوړښت په پوهیدو پورې اړوند لګښتونه خورا لوړ وي ، نو په حقیقت کې ، API د کوډ جنریټر کارولو په اړه ضعیف کار کړی (او وروسته معلومه شوه چې پدې کې د کارونکي تخصیص هم پیچلی دی). کارول باید د هر ډول API لپاره ترټولو لوړ لومړیتوب وي. مګر دا د کوډ تولید پروړاندې یوازې یو دلیل دی. که نه نو، دا په بشپړ ډول لارښود دی چې د داخلي یا بهرني حقیقت ځایی نمایش ولیکئ.

ډیری به ووایی چې دوی د دې ټولو کولو لپاره وخت نلري. دوی د خپل سوپر محصول لپاره د نیټې نیټې څخه تیریږي. یوه ورځ به موږ د مجلس ویاندان پاک کړو، موږ به وخت ولرو. زه به ورته ځواب ورکړم:

اصلي, ایلن اورورک، د اوریدونکو سټیک

مګر په هایبرنیټ / JPA کې د جاوا کوډ لیکل خورا اسانه دي.

رښتیا. د هایبرنیټ او د هغې کاروونکو لپاره ، دا دواړه یو نعمت او لعنت دی. په هایبرنیټ کې تاسو کولی شئ په ساده ډول یو څو ادارې ولیکئ، لکه دا:

	@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 ارزښت څه دی؟
• ستاسو په ترتیب کې د کیچ اندازه څومره ده (د ID شاته)

دا ممکن په کوچنیو سیسټمونو کې مهم نه وي، مګر تاسو اړتیا نلرئ تر هغه پورې انتظار وکړئ چې تاسو د لوی ډیټا ساحې ته لاړ شئ - تاسو کولی شئ د پلورونکي لخوا چمتو شوي ذخیره کولو اصلاحونو څخه ګټه پورته کړئ لکه پورته ذکر شوي ډیر ژر. هیڅ کوم ORM ما نه دی لیدلی (د jOOQ په شمول) د DDL اختیارونو بشپړ سیټ ته لاسرسی نه ورکوي چې تاسو یې غواړئ په خپل ډیټابیس کې وکاروئ. ORMs ځینې وسیلې وړاندې کوي چې تاسو سره د DDL لیکلو کې مرسته کوي.

مګر د ورځې په پای کې ، یو ښه ډیزاین شوی سرکټ په 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 ډیری بدلونونه هم په سیمانټیک اغیزه کوي، نه یوازې نحو. نو ځکه، دا ګټور کیدی شي چې په تالیف شوي کوډ کې وګورئ ترڅو وګورئ چې کوم کوډ به ستاسو د ډیټابیس زیاتوالي لخوا اغیزمن شي (یا کیدای شي).

یوازینی حقیقت

پرته لدې چې تاسو کومه ټیکنالوژي کاروئ ، تل یو ماډل شتون لري چې د ځینې فرعي سیسټم لپاره د حقیقت یوازینۍ سرچینه وي - یا لږترلږه ، موږ باید د دې لپاره هڅه وکړو او د داسې تصدۍ ګډوډي څخه مخنیوی وکړو ، چیرې چې "حقیقت" هرچیرې وي او په یوځل کې هیڅ ځای نه وي. . هر څه کیدای شي ډیر ساده وي. که تاسو یوازې د کوم بل سیسټم سره د XML فایلونه تبادله کوئ، یوازې XSD وکاروئ. د INFORMATION_SCHEMA میټا ماډل د jOOQ څخه په XML بڼه کې وګورئ:
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 APIs سره پیښیږي ، مګر دا بله کیسه ده ، زه به بل ځل جګړه وکړم ...

ډیټابیسونه: دوی ورته شی دي

کله چې د ډیټابیسونو سره کار کول، تاسو پوهیږئ چې دوی ټول اساسا ورته دي. بیس خپل معلومات لري او باید سکیم اداره کړي. په سکیما کې کوم تعدیلات باید په مستقیم ډول په DDL کې پلي شي ترڅو د حقیقت واحد سرچینه تازه شي.

کله چې د سرچینې تازه معلومات رامنځ ته شي، ټول پیرودونکي باید د ماډل کاپي هم تازه کړي. ځینې ​​پیرودونکي په جاوا کې د jOOQ او هایبرنیټ یا JDBC (یا دواړه) په کارولو سره لیکل کیدی شي. نور پیرودونکي په پرل کې لیکل کیدی شي (موږ یوازې دوی ته نیکمرغه غواړو) ، پداسې حال کې چې نور په C# کې لیکل کیدی شي. پروا نه لري. اصلي ماډل په ډیټابیس کې دی. د ORMs په کارولو سره تولید شوي ماډلونه معمولا د خراب کیفیت لرونکي وي، په کمزوري توګه مستند شوي، او پراختیا یې ستونزمن وي.

نو تېروتنه مه کوئ. له پیل څخه تېروتنې مه کوئ. د ډیټابیس څخه کار وکړئ. د پلي کولو پایپ لاین جوړ کړئ چې اتومات کیدی شي. د کوډ جنریټرونه فعال کړئ ترڅو ستاسو د ډیټابیس ماډل کاپي کول اسانه کړي او په پیرودونکو یې ډمپ کړي. او د کوډ جنراتورونو په اړه اندیښنه ودروئ. دوی ښه دي. د دوی سره به تاسو ډیر ګټور شئ. تاسو یوازې د پیل څخه د دوی په ترتیب کولو کې لږ وخت مصرف کولو ته اړتیا لرئ - او بیا د ډیرو تولیداتو کلونه ستاسو په تمه دي ، کوم چې به ستاسو د پروژې تاریخ رامینځته کړي.

بیا هم مننه مه کوئ، وروسته.

تشریح

د روښانه کیدو لپاره: دا مقاله په هیڅ ډول د دې ملاتړ نه کوي چې تاسو اړتیا لرئ د خپل ډیټابیس ماډل فټ کولو لپاره ټول سیسټم (د بیلګې په توګه ، ډومین ، سوداګرۍ منطق ، او نور) وخورئ. هغه څه چې زه پدې مقاله کې وایم هغه دا دی چې د پیرودونکي کوډ چې د ډیټابیس سره اړیکه لري باید د ډیټابیس ماډل پراساس عمل وکړي ، نو دا پخپله د ډیټابیس ماډل په "لومړي درجې" حالت کې تولید نه کوي. دا منطق معمولا ستاسو په پیرودونکي کې د معلوماتو لاسرسي پرت کې موقعیت لري.

په دوه سطحه معمارۍ کې، کوم چې لاهم په ځینو ځایونو کې ساتل کیږي، د داسې سیسټم ماډل ممکن یوازینۍ ممکن وي. په هرصورت، په ډیری سیسټمونو کې د معلوماتو لاسرسي پرت ماته یو "فرعي سیسټم" ښکاري چې د ډیټابیس ماډل پوښي.

استثناوې

د هرې قاعدې لپاره استثناوې شتون لري، او ما دمخه ویلي دي چې د ډیټابیس لومړی او د سرچینې کوډ تولید طریقه کله ناکله نامناسب وي. دلته یو څو داسې استثناوې دي (شاید نور شتون ولري):

• کله چې سکیما نامعلومه وي او باید کشف شي. د مثال په توګه، تاسو د یوې وسیلې چمتو کوونکی یاست چې کاروونکو سره مرسته کوي کوم ډیاګرام نیویګیټ کړي. اوغ دلته د کوډ تولید نشته. مګر بیا هم، ډیټابیس لومړی راځي.
• کله چې یو سرکټ باید په الوتنه کې رامینځته شي ترڅو ځینې ستونزې حل کړي. دا بیلګه د نمونې یو څه په زړه پوري نسخه ښکاري د وجود خاصیت ارزښت، د بیلګې په توګه ، تاسو واقعیا روښانه تعریف شوي سکیم نلرئ. پدې حالت کې، تاسو ډیری وختونه حتی ډاډه نه یاست چې RDBMS به ستاسو سره مناسب وي.

استثناوې د طبیعت له مخې استثنایی دي. په ډیری قضیو کې چې د RDBMS کارول شامل دي، سکیما دمخه پیژندل کیږي، دا په RDBMS کې موقعیت لري او د "حقیقت" یوازینۍ سرچینه ده، او ټول پیرودونکي باید د هغې څخه اخیستل شوي کاپي ترلاسه کړي. په مثالي توګه ، تاسو اړتیا لرئ د کوډ جنریټر وکاروئ.

سرچینه: www.habr.com