ਪਹਿਲਾਂ ਸੱਚ, ਜਾਂ ਸਿਸਟਮ ਨੂੰ ਡੇਟਾਬੇਸ ਡਿਵਾਈਸ ਦੇ ਅਧਾਰ ਤੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

ਹੇ ਹਬਰ!

ਅਸੀਂ ਵਿਸ਼ੇ ਦੀ ਪੜਚੋਲ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ ਜਾਵਾ и ਬਸੰਤਡਾਟਾਬੇਸ ਪੱਧਰ 'ਤੇ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਅੱਜ ਅਸੀਂ ਇਸ ਬਾਰੇ ਪੜ੍ਹਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ, ਵੱਡੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਡੇਟਾਬੇਸ ਢਾਂਚਾ ਕਿਉਂ ਹੈ, ਨਾ ਕਿ ਜਾਵਾ ਕੋਡ, ਜੋ ਨਿਰਣਾਇਕ ਮਹੱਤਵ ਵਾਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਨਿਯਮ ਦੇ ਅਪਵਾਦ ਕੀ ਹਨ।

ਇਸ ਦੀ ਬਜਾਏ ਦੇਰੀ ਵਾਲੇ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਦੱਸਾਂਗਾ ਕਿ ਮੈਨੂੰ ਕਿਉਂ ਲੱਗਦਾ ਹੈ ਕਿ ਲਗਭਗ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਡੇਟਾ ਮਾਡਲ "ਜਾਵਾ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਤੋਂ" (ਜਾਂ ਜੋ ਵੀ ਕਲਾਇੰਟ ਭਾਸ਼ਾ ਤੁਸੀਂ ਹੋ) ਦੀ ਬਜਾਏ "ਡੇਟਾਬੇਸ ਤੋਂ" ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਾਲ ਕੰਮ ਕਰਨਾ). ਦੂਜੀ ਪਹੁੰਚ ਦੀ ਚੋਣ ਕਰਕੇ, ਜਦੋਂ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਵਧਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਦਰਦ ਅਤੇ ਦੁੱਖ ਦੇ ਲੰਬੇ ਰਸਤੇ ਵਿੱਚ ਦਾਖਲ ਹੋ ਜਾਂਦੇ ਹੋ।

ਦੇ ਆਧਾਰ 'ਤੇ ਲੇਖ ਲਿਖਿਆ ਗਿਆ ਸੀ ਇੱਕ ਸਵਾਲ, ਸਟੈਕ ਓਵਰਫਲੋ 'ਤੇ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਭਾਗਾਂ ਵਿੱਚ 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 ਲਈ ਉਪਯੋਗਤਾ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪਰ ਇਹ ਕੋਡ ਬਣਾਉਣ ਦੇ ਵਿਰੁੱਧ ਸਿਰਫ ਇੱਕ ਦਲੀਲ ਹੈ. ਨਹੀਂ ਤਾਂ, ਅੰਦਰੂਨੀ ਜਾਂ ਬਾਹਰੀ ਸੱਚਾਈ ਦੀ ਸਥਾਨਕ ਪ੍ਰਤੀਨਿਧਤਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਥ ਨਾਲ ਲਿਖੋ।

ਕਈ ਕਹਿਣਗੇ ਕਿ ਉਨ੍ਹਾਂ ਕੋਲ ਇਹ ਸਭ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ ਹੈ। ਉਹ ਆਪਣੇ ਸੁਪਰ ਉਤਪਾਦ ਲਈ ਅੰਤਮ ਤਾਰੀਖ 'ਤੇ ਹਨ। ਕਿਸੇ ਦਿਨ ਬਾਅਦ ਵਿੱਚ ਅਸੈਂਬਲੀ ਕਨਵੀਨਰ ਨੂੰ ਕੰਘੀ ਕਰਾਂਗੇ, ਸਾਡੇ ਕੋਲ ਸਮਾਂ ਹੋਵੇਗਾ। ਮੈਂ ਉਨ੍ਹਾਂ ਨੂੰ ਜਵਾਬ ਦੇਵਾਂਗਾ:

ਅਸਲੀ, ਐਲਨ ਓ'ਰੂਰਕੇ, ਦਰਸ਼ਕ ਸਟੈਕ

ਪਰ ਹਾਈਬਰਨੇਟ / ਜੇਪੀਏ ਵਿੱਚ "ਜਾਵਾ ਵਿੱਚ" ਕੋਡ ਲਿਖਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ।

ਸੱਚਮੁੱਚ. ਹਾਈਬਰਨੇਟ ਅਤੇ ਇਸਦੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਇਹ ਇੱਕ ਵਰਦਾਨ ਅਤੇ ਸਰਾਪ ਹੈ। ਹਾਈਬਰਨੇਟ ਵਿੱਚ, ਤੁਸੀਂ ਬਸ ਕੁਝ ਇਕਾਈਆਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖ ਸਕਦੇ ਹੋ:

	@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 ਵਿੱਚ ਹੱਥ ਨਾਲ ਲਿਖੀ ਜਾਂਦੀ ਹੈ। ਕੋਈ ਵੀ ਤਿਆਰ ਕੀਤਾ 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 ਮੈਟਾ-ਮੋਡਿਊਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।

ਅਜਿਹੇ ਸਵਾਲਾਂ ਦੇ ਨਤੀਜਿਆਂ ਤੋਂ, ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਮਾਡਲ ਦੀ ਕਿਸੇ ਵੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਪ੍ਰਤੀਨਿਧਤਾ ਨੂੰ ਬਣਾਉਣਾ ਮੁਕਾਬਲਤਨ ਆਸਾਨ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਕਲਾਇੰਟ 'ਤੇ ਕਿਹੜੀ ਤਕਨੀਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ।

• ਜੇ ਤੁਸੀਂ ਜੇਡੀਬੀਸੀ ਜਾਂ ਸਪਰਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਸਤਰ ਸਥਿਰਾਂਕ ਦਾ ਇੱਕ ਸੈੱਟ ਬਣਾ ਸਕਦੇ ਹੋ
• ਜੇ ਤੁਸੀਂ ਜੇਪੀਏ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਖੁਦ ਇਕਾਈਆਂ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ
• ਜੇਕਰ ਤੁਸੀਂ 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 (ਜਾਂ ਦੋਵੇਂ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖੇ ਜਾ ਸਕਦੇ ਹਨ। ਹੋਰ ਕਲਾਇੰਟਸ ਪਰਲ ਵਿੱਚ ਲਿਖੇ ਜਾ ਸਕਦੇ ਹਨ (ਆਓ ਉਹਨਾਂ ਦੀ ਕਿਸਮਤ ਦੀ ਕਾਮਨਾ ਕਰੀਏ), ਹੋਰ C# ਵਿੱਚ। ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ। ਮੁੱਖ ਮਾਡਲ ਡਾਟਾਬੇਸ ਵਿੱਚ ਹੈ. ORM-ਤਿਆਰ ਕੀਤੇ ਮਾਡਲ ਆਮ ਤੌਰ 'ਤੇ ਮਾੜੀ ਕੁਆਲਿਟੀ ਦੇ ਹੁੰਦੇ ਹਨ, ਮਾੜੇ ਦਸਤਾਵੇਜ਼ੀ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਵਿਕਸਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਇਸ ਲਈ ਗਲਤੀਆਂ ਨਾ ਕਰੋ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਗ਼ਲਤੀਆਂ ਨਾ ਕਰੋ। ਇੱਕ ਡੇਟਾਬੇਸ ਤੋਂ ਕੰਮ ਕਰੋ। ਇੱਕ ਤੈਨਾਤੀ ਪਾਈਪਲਾਈਨ ਬਣਾਓ ਜੋ ਸਵੈਚਲਿਤ ਹੋ ਸਕਦੀ ਹੈ। ਕੋਡ ਜਨਰੇਟਰਾਂ ਨੂੰ ਆਪਣੇ ਡੇਟਾਬੇਸ ਮਾਡਲ ਦੀ ਆਸਾਨੀ ਨਾਲ ਨਕਲ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਗਾਹਕਾਂ 'ਤੇ ਡੰਪ ਕਰਨ ਲਈ ਸਮਰੱਥ ਬਣਾਓ। ਅਤੇ ਕੋਡ ਜਨਰੇਟਰਾਂ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨਾ ਬੰਦ ਕਰੋ. ਉਹ ਚੰਗੇ ਹਨ। ਉਹਨਾਂ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਬਣੋਗੇ. ਤੁਹਾਨੂੰ ਬਸ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਉਹਨਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਥੋੜ੍ਹਾ ਸਮਾਂ ਬਿਤਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਕਹਾਣੀ ਬਣਾਉਣ ਲਈ ਕਈ ਸਾਲਾਂ ਦੀ ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ ਹੋਵੇਗੀ।

ਮੈਨੂੰ ਅਜੇ, ਬਾਅਦ ਵਿੱਚ ਧੰਨਵਾਦ ਨਾ ਕਰੋ.

ਵਿਆਖਿਆ

ਸਪੱਸ਼ਟ ਹੋਣ ਲਈ: ਇਹ ਲੇਖ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਇਸ ਗੱਲ ਦੀ ਵਕਾਲਤ ਨਹੀਂ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਮਾਡਲ ਨੂੰ ਫਿੱਟ ਕਰਨ ਲਈ ਪੂਰੇ ਸਿਸਟਮ (ਜਿਵੇਂ, ਡੋਮੇਨ, ਵਪਾਰਕ ਤਰਕ, ਆਦਿ, ਆਦਿ) ਨੂੰ ਲਚਕੀਲੇ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਮੈਂ ਇਸ ਲੇਖ ਵਿੱਚ ਜਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ ਉਹ ਇਹ ਹੈ ਕਿ ਇੱਕ ਡੇਟਾਬੇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਕੋਡ ਨੂੰ ਡੇਟਾਬੇਸ ਮਾਡਲ ਦੇ ਆਧਾਰ 'ਤੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਡੇਟਾਬੇਸ ਮਾਡਲ ਨੂੰ "ਪਹਿਲੀ ਸ਼੍ਰੇਣੀ" ਸਥਿਤੀ ਵਿੱਚ ਦੁਬਾਰਾ ਪੇਸ਼ ਨਾ ਕਰੇ। ਅਜਿਹਾ ਤਰਕ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕਲਾਇੰਟ 'ਤੇ ਡੇਟਾ ਐਕਸੈਸ ਲੇਅਰ 'ਤੇ ਸਥਿਤ ਹੁੰਦਾ ਹੈ।

ਦੋ-ਪੱਧਰੀ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਜੋ ਅਜੇ ਵੀ ਕੁਝ ਸਥਾਨਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਹਨ, ਅਜਿਹਾ ਸਿਸਟਮ ਮਾਡਲ ਸੰਭਵ ਹੋ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, ਡੇਟਾ ਐਕਸੈਸ ਲੇਅਰ ਮੈਨੂੰ ਇੱਕ "ਸਬਸਿਸਟਮ" ਜਾਪਦੀ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਮਾਡਲ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ।

ਅਪਵਾਦ

ਹਰ ਨਿਯਮ ਦੇ ਅਪਵਾਦ ਹਨ, ਅਤੇ ਮੈਂ ਪਹਿਲਾਂ ਕਿਹਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਪਹਿਲਾਂ ਅਤੇ ਸਰੋਤ ਕੋਡ ਬਣਾਉਣ ਦੀ ਪਹੁੰਚ ਕਈ ਵਾਰ ਅਣਉਚਿਤ ਹੋ ਸਕਦੀ ਹੈ. ਇੱਥੇ ਅਜਿਹੇ ਕੁਝ ਅਪਵਾਦ ਹਨ (ਸ਼ਾਇਦ ਹੋਰ ਵੀ ਹਨ):

• ਜਦੋਂ ਸਕੀਮਾ ਅਣਜਾਣ ਹੈ ਅਤੇ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਚਿੱਤਰ ਨੂੰ ਨੈਵੀਗੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਇੱਕ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋ। ਫੂ. ਇੱਥੇ ਕੋਈ ਕੋਡ ਜਨਰੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਪਰ ਫਿਰ ਵੀ - ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ.
• ਜਦੋਂ ਕਿਸੇ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਫਲਾਈ 'ਤੇ ਇੱਕ ਸਰਕਟ ਤਿਆਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਇਹ ਉਦਾਹਰਨ ਪੈਟਰਨ ਦਾ ਇੱਕ ਥੋੜ੍ਹਾ ਫ੍ਰੀਲੀ ਸੰਸਕਰਣ ਜਾਪਦਾ ਹੈ ਇਕਾਈ ਗੁਣ ਮੁੱਲ, ਭਾਵ, ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਸਕੀਮਾ ਨਹੀਂ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਸੀਂ ਅਕਸਰ ਇਹ ਵੀ ਯਕੀਨੀ ਨਹੀਂ ਹੋ ਸਕਦੇ ਕਿ ਇੱਕ RDBMS ਤੁਹਾਡੇ ਲਈ ਅਨੁਕੂਲ ਹੋਵੇਗਾ।

ਅਪਵਾਦ ਕੁਦਰਤ ਦੁਆਰਾ ਬੇਮਿਸਾਲ ਹਨ. RDBMS ਦੀ ਵਰਤੋਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਕੀਮਾ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣੀ ਜਾਂਦੀ ਹੈ, ਇਹ RDBMS ਦੇ ਅੰਦਰ ਹੈ ਅਤੇ "ਸੱਚ" ਦਾ ਇੱਕੋ ਇੱਕ ਸਰੋਤ ਹੈ, ਅਤੇ ਸਾਰੇ ਗਾਹਕਾਂ ਨੂੰ ਇਸ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਕਾਪੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ। ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਇਸ ਵਿੱਚ ਇੱਕ ਕੋਡ ਜਨਰੇਟਰ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com