પ્રથમ સત્ય, અથવા શા માટે સિસ્ટમને ડેટાબેઝ ડિઝાઇનના આધારે ડિઝાઇન કરવાની જરૂર છે

હે હબર!

અમે વિષય પર સંશોધન કરવાનું ચાલુ રાખીએ છીએ જાવા и વસંત, ડેટાબેઝ સ્તર સહિત. આજે અમે તમને વાંચવા માટે આમંત્રિત કરીએ છીએ કે શા માટે, મોટી એપ્લિકેશનો ડિઝાઇન કરતી વખતે, તે ડેટાબેઝ માળખું છે, અને જાવા કોડ નહીં, તે નિર્ણાયક મહત્વનું હોવું જોઈએ, આ કેવી રીતે થાય છે, અને આ નિયમમાં કયા અપવાદો છે.

આ મોડેથી લેખમાં, હું સમજાવીશ કે શા માટે હું માનું છું કે લગભગ તમામ કેસોમાં, એપ્લિકેશનમાંના ડેટા મોડલને "જાવાની ક્ષમતાઓમાંથી" (અથવા તમે ગમે તે ક્લાયન્ટ ભાષા) ને બદલે "ડેટાબેઝમાંથી" ડિઝાઇન કરવું જોઈએ. સાથે કામ કરવું). બીજો અભિગમ અપનાવીને, એકવાર તમારો પ્રોજેક્ટ વધવા માંડે ત્યારે તમે તમારી જાતને પીડા અને વેદનાના લાંબા માર્ગ માટે સેટ કરી રહ્યાં છો.

જેના આધારે લેખ લખવામાં આવ્યો હતો એક પ્રશ્ન, સ્ટેક ઓવરફ્લો પર આપવામાં આવે છે.

વિભાગોમાં 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# માં અમલમાં છે. આ કિસ્સામાં, કોડ કમ્પાઇલર દ્વારા જનરેટ કરવામાં આવે છે, વાસ્તવમાં સંકલન તબક્કે. સૈદ્ધાંતિક રીતે, આવા કોડ સ્ત્રોત સ્વરૂપમાં અસ્તિત્વમાં નથી. જાવામાં સમાન છે, તેમ છતાં ભવ્ય નથી, ટૂલ્સ - એનોટેશન પ્રોસેસર્સ, ઉદાહરણ તરીકે, લૉમબૉક.

એક અર્થમાં, આના અપવાદ સાથે, પ્રથમ કેસની જેમ જ અહીં પણ થાય છે:

• તમને જનરેટ કરેલ કોડ દેખાતો નથી (કદાચ આ પરિસ્થિતિ કોઈને ઓછી પ્રતિકૂળ લાગે છે?)
• તમારે ખાતરી કરવી જોઈએ કે પ્રકારો પ્રદાન કરી શકાય છે, એટલે કે, "સાચું" હંમેશા ઉપલબ્ધ હોવું જોઈએ. લોમ્બોકના કિસ્સામાં આ સરળ છે, જે "સત્ય" ની ટીકા કરે છે. તે ડેટાબેઝ મોડલ્સ સાથે થોડું વધુ જટિલ છે જે ઑપરેટ કરવા માટે સતત ઉપલબ્ધ લાઇવ કનેક્શન પર આધાર રાખે છે.

કોડ જનરેશનમાં શું સમસ્યા છે?

કોડ જનરેશન - મેન્યુઅલી અથવા ઓટોમેટિકલી કેવી રીતે શ્રેષ્ઠ રીતે ચલાવવું તેના મુશ્કેલ પ્રશ્ન ઉપરાંત, અમારે એ પણ ઉલ્લેખ કરવો પડશે કે એવા લોકો છે જેઓ માને છે કે કોડ જનરેશનની બિલકુલ જરૂર નથી. આ દૃષ્ટિકોણનું વાજબીપણું, જે હું મોટાભાગે અનુભવું છું, તે એ છે કે પછી બિલ્ડ પાઇપલાઇન સેટ કરવી મુશ્કેલ છે. હા, તે ખરેખર મુશ્કેલ છે. વધારાના ઈન્ફ્રાસ્ટ્રક્ચર ખર્ચ ઉદભવે છે. જો તમે હમણાં જ કોઈ ચોક્કસ ઉત્પાદન (પછી તે jOOQ, અથવા JAXB, અથવા હાઇબરનેટ, વગેરે) સાથે પ્રારંભ કરી રહ્યાં છો, તો ઉત્પાદન વાતાવરણને સેટ કરવામાં સમય લાગે છે કે તમે API ને શીખવામાં જ ખર્ચ કરશો જેથી તમે તેમાંથી મૂલ્ય મેળવી શકો. .

જો જનરેટરની રચનાને સમજવા સાથે સંકળાયેલ ખર્ચ ખૂબ વધારે છે, તો પછી, ખરેખર, API એ કોડ જનરેટરની ઉપયોગિતા પર નબળું કામ કર્યું છે (અને પછીથી તે બહાર આવ્યું છે કે તેમાં વપરાશકર્તા કસ્ટમાઇઝેશન પણ જટિલ છે). આવા કોઈપણ API માટે ઉપયોગિતા સર્વોચ્ચ પ્રાથમિકતા હોવી જોઈએ. પરંતુ કોડ જનરેશન સામે આ માત્ર એક દલીલ છે. નહિંતર, આંતરિક અથવા બાહ્ય સત્યની સ્થાનિક રજૂઆત લખવા માટે તે સંપૂર્ણપણે મેન્યુઅલ છે.

ઘણા કહેશે કે તેમની પાસે આ બધું કરવા માટે સમય નથી. તેઓ તેમના સુપર પ્રોડક્ટ માટે સમયમર્યાદા પૂરી કરી રહ્યા છે. કોઈ દિવસ અમે એસેમ્બલી કન્વેયર્સને વ્યવસ્થિત કરીશું, અમારી પાસે સમય હશે. હું તેમને જવાબ આપીશ:

મૂળ, એલન O'Rourke, પ્રેક્ષકો સ્ટેક

પરંતુ હાઇબરનેટ/જેપીએમાં જાવા કોડ લખવો ખૂબ સરળ છે.

ખરેખર. હાઇબરનેટ અને તેના વપરાશકર્તાઓ માટે, આ આશીર્વાદ અને શાપ બંને છે. હાઇબરનેટમાં તમે ફક્ત આના જેવી કેટલીક સંસ્થાઓ લખી શકો છો:

	@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 બોલીઓમાં કેવી રીતે મેળવવી તે અહીં છે:

	-- 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 નો ઉપયોગ કરો. XML સ્વરૂપમાં jOOQ માંથી INFORMATION_SCHEMA મેટા-મોડલ જુઓ:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD સારી રીતે સમજી શકાય છે
• XSD XML સામગ્રીને ખૂબ સારી રીતે ટોકનાઇઝ કરે છે અને તમામ ક્લાયન્ટ ભાષાઓમાં માન્યતાને મંજૂરી આપે છે
• XSD સારી રીતે વર્ઝન કરેલ છે અને તેમાં અદ્યતન પછાત સુસંગતતા છે
• XSD XJC નો ઉપયોગ કરીને Java કોડમાં ભાષાંતર કરી શકાય છે

છેલ્લો મુદ્દો મહત્વપૂર્ણ છે. XML સંદેશાઓનો ઉપયોગ કરીને બાહ્ય સિસ્ટમ સાથે વાતચીત કરતી વખતે, અમે ખાતરી કરવા માંગીએ છીએ કે અમારા સંદેશા માન્ય છે. JAXB, XJC અને XSD નો ઉપયોગ કરીને આ પ્રાપ્ત કરવું ખૂબ જ સરળ છે. તે વિચારવું એકદમ ગાંડપણ હશે કે, "જાવા ફર્સ્ટ" ડિઝાઇન અભિગમ સાથે જ્યાં અમે અમારા સંદેશાઓને જાવા ઑબ્જેક્ટ તરીકે બનાવીએ છીએ, કે તે કોઈક રીતે XML સાથે સુસંગત રીતે મેપ કરી શકાય છે અને વપરાશ માટે અન્ય સિસ્ટમમાં મોકલી શકાય છે. આ રીતે જનરેટ થયેલ XML ખૂબ જ નબળી ગુણવત્તાવાળું, બિનદસ્તાવેજીકૃત અને વિકસિત કરવું મુશ્કેલ હશે. જો આવા ઇન્ટરફેસ માટે સર્વિસ લેવલ એગ્રીમેન્ટ (SLA) હોત, તો અમે તેને તરત જ સ્ક્રૂ કરી દઈશું.

પ્રામાણિકપણે, JSON API સાથે હંમેશાં આવું થાય છે, પરંતુ તે બીજી વાર્તા છે, હું આગલી વખતે ઝઘડો કરીશ...

ડેટાબેસેસ: તેઓ એક જ વસ્તુ છે

ડેટાબેસેસ સાથે કામ કરતી વખતે, તમે સમજો છો કે તે બધા મૂળભૂત રીતે સમાન છે. આધાર તેના ડેટાની માલિકી ધરાવે છે અને તેણે યોજનાનું સંચાલન કરવું જોઈએ. સ્કીમામાં કરવામાં આવેલ કોઈપણ ફેરફારો સીધા DDL માં લાગુ કરવા જોઈએ જેથી સત્યનો એક જ સ્ત્રોત અપડેટ થઈ શકે.

જ્યારે સ્રોત અપડેટ થાય છે, ત્યારે બધા ક્લાયન્ટે તેમના મોડેલની નકલો પણ અપડેટ કરવી આવશ્યક છે. કેટલાક ક્લાયન્ટ્સ JOOQ અને હાઇબરનેટ અથવા JDBC (અથવા બંને) નો ઉપયોગ કરીને Javaમાં લખી શકાય છે. અન્ય ક્લાયન્ટ્સ પર્લમાં લખી શકાય છે (અમે તેમને શુભેચ્છા પાઠવીએ છીએ), જ્યારે અન્ય C# માં લખી શકાય છે. કોઈ વાંધો નથી. મુખ્ય મોડેલ ડેટાબેઝમાં છે. ORM નો ઉપયોગ કરીને જનરેટ કરવામાં આવતા મોડલ સામાન્ય રીતે નબળી ગુણવત્તાના, નબળા દસ્તાવેજીકૃત અને વિકસાવવા મુશ્કેલ હોય છે.

તેથી ભૂલો ન કરો. શરૂઆતથી જ ભૂલો ન કરો. ડેટાબેઝમાંથી કામ કરો. એક જમાવટ પાઇપલાઇન બનાવો જે સ્વચાલિત થઈ શકે. તમારા ડેટાબેઝ મૉડલને કૉપિ કરવાનું સરળ બનાવવા અને તેને ક્લાયંટ પર ડમ્પ કરવા માટે કોડ જનરેટરને સક્ષમ કરો. અને કોડ જનરેટર વિશે ચિંતા કરવાનું બંધ કરો. તેઓ સારા છે. તેમની સાથે તમે વધુ ઉત્પાદક બનશો. તમારે શરૂઆતથી જ તેમને સેટ કરવા માટે થોડો સમય પસાર કરવાની જરૂર છે - અને પછી વધતી ઉત્પાદકતાના વર્ષો તમારી રાહ જોશે, જે તમારા પ્રોજેક્ટનો ઇતિહાસ બનાવશે.

હજુ સુધી મારો આભાર માનશો નહીં, પછીથી.

સમજૂતી

સ્પષ્ટ થવા માટે: આ લેખ કોઈપણ રીતે હિમાયત કરતો નથી કે તમારે તમારા ડેટાબેઝ મોડલને ફિટ કરવા માટે આખી સિસ્ટમ (એટલે ​​કે ડોમેન, બિઝનેસ લોજિક, વગેરે, વગેરે) ને વાળવાની જરૂર છે. આ લેખમાં હું જે કહી રહ્યો છું તે એ છે કે ક્લાયંટ કોડ કે જે ડેટાબેઝ સાથે ક્રિયાપ્રતિક્રિયા કરે છે તે ડેટાબેઝ મોડેલના આધારે કાર્ય કરે છે, જેથી તે પોતે ડેટાબેઝ મોડેલને "પ્રથમ-વર્ગ" સ્થિતિમાં પુનઃઉત્પાદિત ન કરે. આ તર્ક સામાન્ય રીતે તમારા ક્લાયંટ પર ડેટા એક્સેસ લેયર પર સ્થિત હોય છે.

બે-સ્તરના આર્કિટેક્ચરમાં, જે હજુ પણ કેટલીક જગ્યાએ સચવાયેલ છે, આવા સિસ્ટમ મોડેલ એકમાત્ર શક્ય હોઈ શકે છે. જો કે, મોટાભાગની સિસ્ટમોમાં ડેટા એક્સેસ લેયર મને "સબસિસ્ટમ" લાગે છે જે ડેટાબેઝ મોડલને સમાવે છે.

અપવાદો

દરેક નિયમમાં અપવાદો છે, અને મેં પહેલેથી જ કહ્યું છે કે ડેટાબેઝ-ફર્સ્ટ અને સોર્સ-કોડ જનરેશનનો અભિગમ ક્યારેક અયોગ્ય હોઈ શકે છે. અહીં આવા કેટલાક અપવાદો છે (કદાચ અન્ય છે):

• જ્યારે સ્કીમા અજ્ઞાત હોય અને તેને શોધવાની જરૂર હોય. ઉદાહરણ તરીકે, તમે એવા સાધનના પ્રદાતા છો જે વપરાશકર્તાઓને કોઈપણ ડાયાગ્રામ નેવિગેટ કરવામાં મદદ કરે છે. ઉહ. અહીં કોઈ કોડ જનરેશન નથી. પરંતુ હજુ પણ, ડેટાબેઝ પ્રથમ આવે છે.
• જ્યારે કોઈ સમસ્યા હલ કરવા માટે ફ્લાય પર સર્કિટ જનરેટ કરવી આવશ્યક છે. આ ઉદાહરણ પેટર્નના સહેજ કાલ્પનિક સંસ્કરણ જેવું લાગે છે એન્ટિટી એટ્રિબ્યુટ મૂલ્ય, એટલે કે, તમારી પાસે ખરેખર સ્પષ્ટ રીતે વ્યાખ્યાયિત યોજના નથી. આ કિસ્સામાં, તમે ઘણીવાર ખાતરી પણ કરી શકતા નથી કે RDBMS તમને અનુકૂળ કરશે.

અપવાદો પ્રકૃતિ દ્વારા અપવાદરૂપ છે. RDBMS ના ઉપયોગ સાથે સંકળાયેલા મોટા ભાગના કિસ્સાઓમાં, સ્કીમા અગાઉથી જાણીતી હોય છે, તે RDBMS ની અંદર રહે છે અને "સત્ય" નો એકમાત્ર સ્ત્રોત છે, અને તમામ ગ્રાહકોએ તેમાંથી મેળવેલી નકલો મેળવવાની હોય છે. આદર્શ રીતે, તમારે કોડ જનરેટરનો ઉપયોગ કરવાની જરૂર છે.

સોર્સ: www.habr.com