እውነት በመጀመሪያ፣ ወይም ለምን በዳታቤዝ መዋቅር ላይ በመመስረት ስርዓቱ መንደፍ እንዳለበት

ሃይ ሀብር!

ርዕሱን መመርመራችንን እንቀጥላለን ጃቫ и ምንጭበመረጃ ቋት ደረጃ ጨምሮ። ዛሬ ትላልቅ አፕሊኬሽኖችን በሚነድፉበት ጊዜ ለምንድነው እንዲያነቡ እንጋብዝዎታለን የውሂብ ጎታ አወቃቀሩ እንጂ የጃቫ ኮድ አይደለም, ወሳኝ ጠቀሜታ ሊኖረው የሚገባው, ይህ እንዴት እንደሚደረግ, እና ለዚህ ህግ ምን ልዩ ሁኔታዎች አሉ.

በዚህ ዘግይቶ መጣጥፍ ፣ በሁሉም ጉዳዮች ማለት ይቻላል ፣ በመተግበሪያ ውስጥ ያለው የመረጃ ሞዴል “ከጃቫ አቅም” (ወይም የትኛውም የደንበኛ ቋንቋ ከሆንክ) ይልቅ “ከመረጃ ቋት” መቅረጽ እንዳለበት ለምን እንዳምን እገልጻለሁ። ጋር መስራት)። ሁለተኛውን አካሄድ በመውሰድ፣ ፕሮጀክትህ ማደግ ከጀመረ በኋላ እራስህን ለረጅም የህመም እና የስቃይ ጎዳና እያዘጋጀህ ነው።

ጽሑፉ የተፃፈው በዚህ መሠረት ነው። አንድ ጥያቄ, በ Stack Overflow ላይ ተሰጥቷል.

በክፍሎች ውስጥ ስለ 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)) {
    // ...
}

ኮዱ የሚመነጨው ከጉባዔው ውጭ ወይም በእጅ በእያንዳንዱ ስብሰባ ነው። ለምሳሌ, እንዲህ ዓይነቱ እድሳት ወዲያውኑ በኋላ ሊከተል ይችላል የፍላይዌይ ዳታቤዝ ፍልሰት፣ እሱም እንዲሁ በእጅ ወይም በራስ-ሰር ሊከናወን ይችላል።.

ምንጭ ኮድ ማመንጨት

በዚህ ጽሑፍ ውስጥ በዝርዝር የማልናገርባቸው የተለያዩ ፍልስፍናዎች፣ ጥቅሞች እና ጉዳቶች ከኮድ ማመንጨት ጋር የተያያዙ - በእጅ እና አውቶማቲክ - አሉ ። ነገር ግን በአጠቃላይ የመነጨው ኮድ አጠቃላይ ነጥብ በስርዓታችን ውስጥም ሆነ ከሱ ውጭ የምንወስደውን "እውነት" በጃቫ ለመድገም ያስችለናል. በአንጻሩ፣ ኮምፕሌተሮች ባይትኮድ፣ ማሽን ኮድ ወይም ሌላ ዓይነት ምንጭ ኮድ ሲያመነጩ የሚያደርጉት ይህ ነው - ልዩ ምክንያቶች ምንም ቢሆኑም የኛን “እውነት” በሌላ ቋንቋ ውክልና እናገኛለን።

ብዙ እንደዚህ ያሉ የኮድ ማመንጫዎች አሉ. ለምሳሌ, XJC በXSD ወይም WSDL ፋይሎች ላይ በመመስረት የጃቫ ኮድ መፍጠር ይችላል።. መርሆው ሁሌም አንድ ነው፡-

• አንዳንድ እውነት (ውስጣዊም ሆነ ውጫዊ) አለ - ለምሳሌ ዝርዝር መግለጫ፣ የውሂብ ሞዴል፣ ወዘተ.
• በፕሮግራም አወጣጥ ቋንቋችን የዚህን እውነት የአካባቢ ውክልና እንፈልጋለን።

ከዚህም በላይ ተደጋጋሚነትን ለማስወገድ ሁልጊዜ ማለት ይቻላል እንዲህ ዓይነቱን ውክልና ማመንጨት ተገቢ ነው.

አይነት አቅራቢዎች እና ማብራሪያ ሂደት

ማስታወሻ፡ ለ jOOQ የሚሆን ሌላ፣ ይበልጥ ዘመናዊ እና የተለየ አቀራረብ አይነት አቅራቢዎችን እየተጠቀመ ነው፣ በF# ውስጥ እንደሚተገበሩ. በዚህ ሁኔታ, ኮዱ የሚመነጨው በማጠናከሪያው ነው, በእውነቱ በማጠናቀር ደረጃ ላይ ነው. በመርህ ደረጃ, እንዲህ ዓይነቱ ኮድ በምንጭ መልክ የለም. ጃቫ ተመሳሳይ ነው ፣ ምንም እንኳን እንደ ውበት ባይሆንም ፣ መሣሪያዎች - የማብራሪያ ማቀነባበሪያዎች ፣ ለምሳሌ ፣ Lombok.

ከሚከተሉት በስተቀር፣ እንደ መጀመሪያው ሁኔታ ተመሳሳይ ነገሮች እዚህ ይከሰታሉ፡-

• የመነጨውን ኮድ አያዩትም (ምናልባት ይህ ሁኔታ ለአንድ ሰው ብዙም አጸያፊ ይመስላል?)
• ዓይነቶች ሊቀርቡ እንደሚችሉ ማረጋገጥ አለብዎት, ማለትም, "እውነት" ሁልጊዜ መገኘት አለበት. ይህ በሎምቦክ ጉዳይ ላይ ቀላል ነው, እሱም "እውነትን" ያብራራል. በቋሚነት በሚገኝ የቀጥታ ግንኙነት ላይ በሚመሰረቱ የውሂብ ጎታ ሞዴሎች ትንሽ የተወሳሰበ ነው።

ኮድ የማመንጨት ችግር ምንድነው?

ኮድ ማመንጨት እንዴት ይሻላል ከሚለው ተንኮለኛ ጥያቄ በተጨማሪ - በእጅ ወይም በራስ-ሰር ፣ ኮድ ማመንጨት በጭራሽ አያስፈልግም ብለው የሚያምኑ ሰዎች እንዳሉ መጥቀስ አለብን። ብዙ ጊዜ ያጋጠመኝ የዚህ አመለካከት ማረጋገጫ, ከዚያም የግንባታ ቧንቧን ማዘጋጀት አስቸጋሪ ነው. አዎ በጣም ከባድ ነው። ተጨማሪ የመሠረተ ልማት ወጪዎች ይነሳሉ. በአንድ የተወሰነ ምርት (JOOQ፣ ወይም JAXB፣ ወይም Hibernate፣ ወዘተ) እየጀመርክ ​​ከሆነ፣ የምርት አካባቢን ማዘጋጀት ጊዜ የሚወስድብህ ከሆነ ኤፒአይን በራሱ በመማር የምታጠፋው ጊዜ ስለሚወስድ ነው፣ ስለዚህም ከእሱ ዋጋ ማውጣት እንድትችል .

የጄነሬተሩን መዋቅር ከመረዳት ጋር የተያያዙ ወጪዎች በጣም ብዙ ከሆኑ, በእርግጥ, ኤፒአይ በኮድ ጄኔሬተር አጠቃቀም ላይ ደካማ ስራ ሰርቷል (እና በኋላ ላይ የተጠቃሚውን ማበጀት ውስብስብ ነው). ለእንደዚህ አይነቱ ኤፒአይ አጠቃቀም ከፍተኛው ቅድሚያ የሚሰጠው መሆን አለበት። ግን ይህ በኮድ ማመንጨት ላይ አንድ ክርክር ብቻ ነው። ያለበለዚያ፣ የውስጣዊም ሆነ ውጫዊ እውነትን አካባቢያዊ ውክልና መጻፍ ሙሉ በሙሉ በእጅ ነው።

ብዙዎች ይህንን ሁሉ ለማድረግ ጊዜ እንደሌላቸው ይናገራሉ. ለሱፐር ምርታቸው የጊዜ ገደብ እያለቀባቸው ነው። አንድ ቀን የመሰብሰቢያ ማጓጓዣዎችን እናጸዳለን, ጊዜ ይኖረናል. እመልስላቸዋለሁ፡-

የመጀመሪያው, Alan O'Rourke፣ የታዳሚዎች ቁልል

ነገር ግን በ Hibernate/JPA የጃቫ ኮድ መፃፍ በጣም ቀላል ነው።

በእውነት። ለ Hibernate እና ለተጠቃሚዎቹ፣ ይህ ሁለቱም በረከት እና እርግማን ነው። በ Hibernate ውስጥ እንደዚህ ያሉ ሁለት አካላትን በቀላሉ መጻፍ ይችላሉ-

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

እና ሁሉም ነገር ማለት ይቻላል ዝግጁ ነው። አሁን ይህ ህጋዊ አካል በእርስዎ SQL “ዘዬ” ዲኤልኤል ውስጥ እንዴት እንደሚገለጽ ውስብስብ “ዝርዝሮችን” ለመፍጠር እስከ Hibernate ድረስ ነው።

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

ጥሩ. እንደገና ማመንጨት። በድጋሚ, በዚህ ሁኔታ መጀመሪያ ላይ በጣም ቀላል ይሆናል.

ግን በኋላ መክፈል አለብህ

ፈጥኖም ይሁን ዘግይቶ ወደ ምርት መሄድ አለብዎት. ይህ ሞዴል መስራት የሚያቆመው ያኔ ነው። ምክንያቱም፡-

በምርት ውስጥ, አስፈላጊ ከሆነ, የድሮውን የውሂብ ጎታ መጣል እና ከባዶ መጀመር አይቻልም. የውሂብ ጎታዎ ቅርስ ይሆናል።

ከአሁን ጀምሮ እና ለዘላለም መፃፍ አለብዎት የዲዲኤል ፍልሰት ስክሪፕቶች፣ ለምሳሌ፣ ፍላይዌይን በመጠቀም. በዚህ ጉዳይ ላይ የእርስዎ አካላት ምን ይሆናሉ? ወይ እራስዎ ማስማማት ይችላሉ (እና ስለዚህ የስራ ጫናዎን በእጥፍ ያሳድጉ) ወይም ሃይበርኔትን እንዲያድስልዎ መንገር ይችላሉ (በዚህ መንገድ የተፈጠሩት እርስዎ የሚጠብቁትን ለማሟላት ምን ያህል ሊሆኑ ይችላሉ?) በማንኛውም መንገድ እርስዎ ይሸነፋሉ።

ስለዚህ ወደ ምርት ከገቡ በኋላ ትኩስ ፕላስተር ያስፈልግዎታል. እና በፍጥነት ወደ ምርት መግባት አለባቸው. ለምርት የስደት ጉዞዎችዎን ለስላሳ የቧንቧ መስመር ስላላዘጋጁ እና ስላላደራጁ ሁሉንም ነገር በደንብ ያስተካክላሉ። እና ከዚያ በኋላ ሁሉንም ነገር በትክክል ለመስራት ጊዜ የለዎትም። እና Hibernateን ትተቸዋለህ፣ ምክንያቱም ሁሌም የሌላ ሰው ጥፋት እንጂ አንተ አይደለህም...

ይልቁንስ ነገሮች ገና ከመጀመሪያው ፈጽሞ በተለየ መንገድ ሊደረጉ ይችሉ ነበር። ለምሳሌ, ክብ ጎማዎችን በብስክሌት ላይ ያድርጉ.

የውሂብ ጎታ መጀመሪያ

በመረጃ ቋትህ ውስጥ ያለው እውነተኛው "እውነት" እና በእሱ ላይ ያለው "ሉዓላዊነት" በመረጃ ቋቱ ውስጥ ነው። መርሃግብሩ በራሱ በመረጃ ቋቱ ውስጥ ብቻ እና በየትኛውም ቦታ ይገለጻል, እና እያንዳንዱ ደንበኛ የዚህ ንድፍ ቅጂ አለው, ስለዚህ የመርሃግብሩን እና የአቋም መግለጫውን በትክክል መተግበር, በመረጃ ቋቱ ውስጥ በትክክል ለመስራት ፍጹም ምክንያታዊ ነው - መረጃው የት ነው. ተከማችቷል.
ይህ አሮጌ ነው, እንዲያውም የተጠለፈ ጥበብ. ዋና እና ልዩ ቁልፎች ጥሩ ናቸው. የውጭ ቁልፎች ጥሩ ናቸው. ገደቦችን መፈተሽ ጥሩ ነው. መግለጫዎች - ጥሩ።

ከዚህም በላይ ይህ ብቻ አይደለም. ለምሳሌ፣ Oracleን በመጠቀም፣ ምናልባት የሚከተለውን መግለጽ ይፈልጉ ይሆናል።

• ጠረጴዛዎ በየትኛው የጠረጴዛ ቦታ ላይ ነው?
• የ PCTFREE ዋጋው ስንት ነው?
• በቅደም ተከተልዎ ውስጥ ያለው የመሸጎጫ መጠን ስንት ነው (ከመታወቂያው በስተጀርባ)

በትናንሽ ስርዓቶች ውስጥ ይህ አስፈላጊ ላይሆን ይችላል፣ ነገር ግን ወደ ትልቁ የውሂብ ጎራ እስክትገቡ ድረስ መጠበቅ አይኖርብዎትም—ከላይ እንደተጠቀሱት ቶሎ ቶሎ ከአቅራቢዎች ከሚቀርቡት የማከማቻ ማሻሻያዎች ተጠቃሚ መሆን ይችላሉ። ካየኋቸው ORMዎች ውስጥ አንዳቸውም (jOOQን ጨምሮ) በመረጃ ቋትዎ ውስጥ ሊጠቀሙባቸው የሚችሏቸውን ሙሉ የዲዲኤል አማራጮችን አይሰጡም። 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 ወይም Spring እየተጠቀሙ ከሆነ፣ የሕብረቁምፊ ቋሚዎች ስብስብ መፍጠር ይችላሉ።
• JPA ን ከተጠቀሙ ህጋዊ አካላትን ራሳቸው ማመንጨት ይችላሉ።
• jOOQ ከተጠቀሙ፣ የ jOOQ ሜታ-ሞዴሉን ማመንጨት ይችላሉ።

በደንበኛዎ ኤፒአይ (ለምሳሌ 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 ክፍል። አብዛኛዎቹ የዲዲኤል ለውጦች አገባብ ብቻ ሳይሆን የትርጓሜ ትምህርት ላይም ተጽዕኖ ያሳድራሉ። ስለዚህ፣ በመረጃ ቋትዎ መጨመር ምን አይነት ኮድ እንደሚጎዳ (ወይም ሊጎዳ እንደሚችል) ለማየት የተጠናቀረውን ኮድ መመልከት ጠቃሚ ሊሆን ይችላል።

ብቸኛው እውነት

ምንም አይነት ቴክኖሎጂ ቢጠቀሙ ለአንዳንድ ንዑስ ስርዓቶች ብቸኛው የእውነት ምንጭ አንድ ሞዴል አለ - ወይም ቢያንስ ለዚህ ጥረት ማድረግ እና ከእንደዚህ አይነት የድርጅት ግራ መጋባት መራቅ አለብን ፣ “እውነት” በሁሉም ቦታ እና በአንድ ጊዜ የለም . ሁሉም ነገር በጣም ቀላል ሊሆን ይችላል. የኤክስኤምኤል ፋይሎችን ከሌላ ሥርዓት ጋር የምትለዋወጡ ከሆነ፣ XSDን ብቻ ተጠቀም። የINFORMATION_SCHEMA ሜታ-ሞዴሉን ከ jOOQ በXML መልክ ይመልከቱ፡-
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD በደንብ ተረድቷል።
• XSD የኤክስኤምኤል ይዘትን በደንብ ያሳያል እና በሁሉም የደንበኛ ቋንቋዎች ማረጋገጥን ይፈቅዳል
• XSD በጥሩ ሁኔታ የተሻሻለ እና የላቀ የኋላ ተኳኋኝነት አለው።
• XJC በመጠቀም ወደ ጃቫ ኮድ ሊተረጎም ይችላል።

የመጨረሻው ነጥብ አስፈላጊ ነው. የኤክስኤምኤል መልዕክቶችን በመጠቀም ከውጫዊ ስርዓት ጋር ስንገናኝ መልእክቶቻችን ትክክለኛ መሆናቸውን ማረጋገጥ እንፈልጋለን። ይህ JAXB፣ XJC እና XSD በመጠቀም ለማግኘት በጣም ቀላል ነው። መልእክቶቻችንን የጃቫ እቃዎች አድርገን በምንሰራበት በ"Java first" የንድፍ አሰራር እንደምንም በአንድነት ወደ ኤክስኤምኤል ተቀርፀው ለፍጆታ ወደ ሌላ ስርአት ሊላክ ይችላል ብሎ ማሰብ በጣም እብደት ነው። በዚህ መንገድ የሚመነጨው XML ጥራት የሌለው፣ ሰነድ አልባ እና ለማዳበር አስቸጋሪ ይሆናል። ለእንደዚህ አይነቱ በይነገጽ የአገልግሎት ደረጃ ስምምነት (ኤስኤልኤ) ካለ ወዲያውኑ እንዘጋዋለን።

እንደ እውነቱ ከሆነ በJSON ኤፒአይዎች ሁልጊዜ የሚሆነው ይህ ነው፣ ግን ያ ሌላ ታሪክ ነው፣ በሚቀጥለው ጊዜ እጨቃጨቃለሁ...

ዳታቤዝ፡ አንድ አይነት ናቸው።

ከመረጃ ቋቶች ጋር ሲሰሩ, ሁሉም በመሠረቱ ተመሳሳይ መሆናቸውን ይገነዘባሉ. መሰረቱ የራሱ ውሂብ አለው እና እቅዱን ማስተዳደር አለበት። በእቅዱ ላይ የተደረጉ ማሻሻያዎች አንድ ነጠላ የእውነት ምንጭ እንዲዘመን በዲዲኤል ውስጥ በቀጥታ መተግበር አለበት።

የምንጭ ዝመና ሲከሰት ሁሉም ደንበኞች የአምሳያው ቅጂዎቻቸውን ማዘመን አለባቸው። አንዳንድ ደንበኞች jOOQ እና Hibernate ወይም JDBC (ወይም ሁለቱንም) በመጠቀም በጃቫ መፃፍ ይችላሉ። ሌሎች ደንበኞች በፐርል (መልካም እድል እንመኛለን) ሊፃፉ ይችላሉ, ሌሎች ደግሞ በ C # ሊጻፉ ይችላሉ. ምንም ችግር የለውም. ዋናው ሞዴል በመረጃ ቋቱ ውስጥ ነው. ORMs በመጠቀም የሚመነጩት ሞዴሎች በአብዛኛው ጥራት የሌላቸው፣ በደንብ ያልተመዘገቡ እና ለማዳበር አስቸጋሪ ናቸው።

ስለዚህ አትሳሳት። ገና ከመጀመሪያው ስህተት አትስሩ. ከመረጃ ቋቱ ይስሩ። አውቶማቲክ ሊሆን የሚችል የማሰማሪያ ቧንቧ ይገንቡ። የውሂብ ጎታዎን ሞዴል ለመቅዳት ቀላል ለማድረግ የኮድ ማመንጫዎችን ያንቁ እና በደንበኞች ላይ ይጥሉት። እና ስለ ኮድ ማመንጫዎች መጨነቅዎን ያቁሙ. ጥሩ ናቸው. በእነሱ አማካኝነት የበለጠ ውጤታማ ይሆናሉ. ገና ከመጀመሪያው እነሱን በማዋቀር ትንሽ ጊዜ ማሳለፍ ያስፈልግዎታል - እና ከዚያ የተጨማሪ ምርታማነት ዓመታት ይጠብቁዎታል ፣ ይህም የፕሮጀክትዎን ታሪክ ይይዛል።

አሁንም አታመሰግኑኝ፣ በኋላ።

ማብራሪያ ፡፡

ግልጽ ለማድረግ፡ ይህ ጽሁፍ የውሂብ ጎታህን ሞዴል ለመግጠም መላውን ስርዓት (ማለትም፣ ጎራ፣ ቢዝነስ ሎጂክ፣ ወዘተ፣ ወዘተ) ማጠፍ እንደሚያስፈልግህ በምንም መንገድ አይደግፍም። በዚህ ጽሁፍ ውስጥ የምለው ከመረጃ ቋቱ ጋር የሚገናኘው የደንበኛ ኮድ በዳታቤዝ ሞዴሉ ላይ ተመርኩዞ መስራት ያለበት ራሱ የመረጃ ቋቱን ሞዴል በ"አንደኛ ደረጃ" ደረጃ እንዳይሰራጭ ነው። ይህ አመክንዮ ብዙውን ጊዜ በደንበኛዎ ላይ ባለው የውሂብ መዳረሻ ንብርብር ላይ ይገኛል።

በአንዳንድ ቦታዎች አሁንም ተጠብቀው በሚገኙ ሁለት-ደረጃ አርክቴክቶች ውስጥ, እንዲህ ዓይነቱ የስርዓት ሞዴል ብቸኛው ሊሆን ይችላል. ነገር ግን፣ በአብዛኛዎቹ ሲስተሞች የውሂብ መዳረሻ ንብርብር የመረጃ ቋቱን ሞዴል የሚሸፍን "ንዑስ ስርዓት" መስሎ ይታየኛል።

ልዩነቶች

ለእያንዳንዱ ህግ ልዩ ሁኔታዎች አሉ፣ እና አስቀድሜ ተናግሬአለሁ የውሂብ ጎታ-የመጀመሪያ እና የምንጭ-ኮድ ማመንጨት አካሄድ አንዳንድ ጊዜ አግባብነት የለውም። ከእነዚህ ልዩ ሁኔታዎች ውስጥ ጥቂቶቹ እዚህ አሉ (ምናልባትም ሌሎች ሊኖሩ ይችላሉ)

• መርሃግብሩ በማይታወቅበት ጊዜ እና መገኘት ሲኖርበት. ለምሳሌ እርስዎ ተጠቃሚዎች ማንኛውንም ስዕላዊ መግለጫ እንዲያስሱ የሚያግዝ መሳሪያ አቅራቢ ነዎት። ኧረ እዚህ ምንም ኮድ ማመንጨት የለም. ግን አሁንም የውሂብ ጎታው መጀመሪያ ይመጣል.
• አንዳንድ ችግር ለመፍታት በበረራ ላይ አንድ ወረዳ መፈጠር አለበት ጊዜ. ይህ ምሳሌ ትንሽ የሚያምር የስርዓተ-ጥለት ስሪት ይመስላል የህጋዊ አካል እሴት፣ ማለትም፣ በትክክል በግልፅ የተቀመጠ እቅድ የለዎትም። በዚህ አጋጣሚ፣ RDBMS ለእርስዎ እንደሚስማማ እርግጠኛ መሆን እንኳን አይችሉም።

ልዩነቱ በተፈጥሮ ልዩ ነው። በአብዛኛዎቹ ጉዳዮች የ RDBMS አጠቃቀምን በሚመለከቱ ጉዳዮች ፣ መርሃግብሩ አስቀድሞ ይታወቃል ፣ በ RDBMS ውስጥ ይኖራል እና “የእውነት” ብቸኛው ምንጭ ነው ፣ እና ሁሉም ደንበኞች ከእሱ የተገኙ ቅጂዎችን ማግኘት አለባቸው። በሐሳብ ደረጃ, አንድ ኮድ ጄኔሬተር መጠቀም አለብዎት.

ምንጭ: hab.com