Talk:Ajamasin: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Line 23: Line 23:
*Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
*Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.
*Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.
*Pakkumiseisik ja Logi tabelis on puudu unikaalne id. See pole absoluutselt vajalik, kuid kunagi kahjuks ka ei tule.

Revision as of 22:14, 13 November 2016

BRONEERING

Ajamasinat retsenseerib meeskond Isearve https://wiki.itcollege.ee/index.php/Isearve

RETSENSIOON ON VEEL KIRJUTAMISEL


Arhitektuur

Loodetavsti saan õigesti aru, et rakendus koosneb praeguse visiooni kohaselt kahest peamisest nö eraldi programmist või vaatest, mille aluskood on ilmselt üpris sarnane, kuid tegu on siiski täiesti eraldiseisvate programmidega, mis on ühendatud vaid andmebaasi kaudu.


Funktsionaalsus

Väga mahukas ettevõtmine! Kas töö mahu arvutamine ja hind on täispäevade kaupa? Hetkel see paistab nii oelvat, kuigi päriselus käib arveldamine tavaliselt töötundides

Andmebaas

Andmebaasi tabelite arv tundub antud töö jaoks olema täiesti piisav ning nende sisu asjakohane. Paar mõtet andmebaasi ülevaadet lugedes siiski tekkis.

  • Esiteks ei saa selle praegusest kirjakujust liiga hästi aru, kuidas üks tabel teisega seotud võib olla. Siin võib abiks olla, kui kasutada üle kogu andmebaasi unikaalseid väljade nimetusi. Näiteks Pakkumise id oleks nimetusega pakkumine_id ja Asukoha id oleks asukoht_id.
  • Kasutades eelnevat loogikat peaks olema näha, et antud hetkel on andmebaasi skeemis osad id-d kirjas ainult ühe korra, mis omakorda tähendab seda, et selliste id-dega tabelid pole skeemi järgi ühegi teise tabeliga seotud. Tabelid Asukoht ja Staatus paistavad olevat sellised tabelid, mille sisu ei saa hetkel kuskil mujal kasutada, kuna nende id-sid muudes tabelites ei leidu. Kuna mõlemad on loogiliselt kõige rohkem seotud pakkumisega, peaks Pakkumiste tabelit täiendama kahe väljaga: asukoht_id ja staatus_id. Väli "staatus" on küll pakkumiste tabelis olemas, kuid hetkel jääb arusaamatuks selle funktsioon, kui on olemas eraldi tabel Staatus.
  • Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
  • Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.
  • Pakkumiseisik ja Logi tabelis on puudu unikaalne id. See pole absoluutselt vajalik, kuid kunagi kahjuks ka ei tule.