Hirdetés

  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

  • Szmeby Szmeby tag
    #4629
    #4628 nyunyu
    Új Válasz
    Ú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
    Szmeby
    Szmeby
    tag
    #4628 nyunyu
    #4628 nyunyu

    Á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.

    És gondolom, a projektben résztvevő összes cég azt állítja magáról, hogy csak minőségi szoftvert adnak ki a kezükből, a szakmai kiválóság az elsődleges.

    Szerintem amúgy nem szar a terv, csak a tervező bizonyára elfelejtette, hogy a munkája nem ér véget a Generate gomb megnyomásával. A többi résztvevő meg nem volt elég tökös visszadobni a félkész produktumot. Pénz van, idő nincs, nyilván a gányolás felé húz ezek után minden résztvevő szíve. Nem szar ez, hanem kihívásokkal tűzdelt. Azt meg minden fejlesztő szereti, sokan a cv-be is beírják, a kihívás fontos. :D

    (Sosem értettem, miért nem illik megosztani a nyilvánvaló ostobaságokat elkövető (jogi) személyek / projektek nevét. Mások okulására és tájékoztatására, hogy "ide ne gyertek dolgozni, ha nem akartok inkompetens, egyeztetésre képtelen egyedekkel együtt dolgozni". Mindig csak a cukormáz látszik. Pedig hibázni jó dolog, de azt nem beismerni totális káoszba vezet. És kinek van kedve káoszban létezni? Habár biztos akad olyan is, de én nem tartozom közéjük.)

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