2. Fórumok
  3. Szoftverfejlesztés
  4. SQL kérdések
  5. (kiemelt téma)

Új hozzászólás Aktív témák

  • #4628 nyunyu félisten Louro #4626
    Új Válasz #4628
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    nyunyu

    félisten

    válasz Louro #4626 üzenetére

    Állami hivatal, napjainkban futó pármilliárdos IT tender.

    Valamelyik nagyokos kitalálta, hogy Enterprise Architectben jól lemodellezi az egész rendszert, és megrajzolt egy olyan infrastruktúrát és adatmodellt, aminek az egyik fele felesleges, másik fele meg használhatatlan.

    Hivatal IT osztálya persze ellenkezett, hogy ez így megvalósíthatatlan, kivitelezhetetlen, de hát nem ők voltak a döntéshozói szerepkörben, így el lett fogadva.
    Megvalósítani meg úgyis a beszállítóknak kell...

    A hivatalnak van saját sokoldalas fejlesztési standardja, ami előírja a beszédes nevek használatát, minden objektumnak kell legyen egy _id végű egyedi kulcsa, minden mezőnév a táblanévvel kezdődik, stb.
    Ezektől eltérni nem lehet, mert deploy előtti ellenőrzésen fennakad a kód, nem telepítik, ha valamelyik követelménynek nem felel meg.

    Lényeg: EAban szereplő adatmodellből generálják az objektumokat létrehozó szkripteket.

    Probléma azzal még nincs, hogy a beszedes_elso_tablanev_elso_mezoje túl hosszú lenne, hanem azzal, hogy a külső kulcsok neve táblanév1_táblanév2_id alakú, illetve az N:M relációk leírásához szükséges táblák neve is konkatenálódik: táblanév1_táblanév2.
    Így a benne lévő táblanév1_mezőre visszamutató mező neve elso_tabla_neve_masodik_tabla_neve_elso_tabla_neve_mezo_neve lesz.

    Ennek persze az lett az eredménye, hogy az EAból generált szkripteket a meglevő Oracle 12.1 rendszerük nem bírta lefuttatni, mert nem fértek bele a 30 karakteres tábla és oszlopnév limitjébe.

    Főnököm felvetette, hogy akkor leimplementáljuk mi az adatmodellt, értelmesen rövidített táblanevekkel.
    Na azt nem lehet, mert akkor nem felelünk meg az EAban leírt terveknek.

    Jó, akkor módosítsátok az EAban lévő adatmodellt úgy, hogy a konkatenált nevek is beleférjenek a 30 karakterbe.
    Nem lehet, túl sok munka, meg már a projekt többi részéhez is hozzá kéne nyúlni.

    Harmadik opció?
    DB upgrade, de annak jelentős szoftverlicensz vonzata van.

    Azóta a projekt alatt Oracle 19 dübörög, mivel annak a költségét egyszerűbb volt átverekedni az ilyen-olyan bizottságon, mint a szent és sérthetetlen (hetente ötször változó) haditervet módosítsák, mert az utóbbi annak a beismerése lett volna, hogy a terv alapból szar. :))

    Akarom mondani a DB frissítés kisebb projekt kockázattal járt, mint a tervet módosítani.

Új hozzászólás Aktív témák