ROOT problem in zaključevanje projekta

[20timresnik]

Dober dan, s sošolci smo pri koncu s projektom, težavo nam delata samo še dve stvari:

1. Na začetni strani imamo v ozadju sliko(ki se nahaja v mapi /static, pod imenom domaca.jpg), ki se nam izriše na localhost, v Binderju pa se sploh ne prikaže. Ali je problem v ROOT-u, bi ga morali dodati v kakšno pot?(smo že probavali, pa nam ni uspelo)
2. Pri raznih redirect-ih, npr. pri prijavi in registraciji, nam ponovno v localhost program deluje pravilno, medtem ko se v Binderju ne vrne na pravo stran, oziroma izpiše not found. Verjetno je tukaj spet napaka v dodanem ROOT pri redirect-ih, ali mogoče kje drugje?(tukaj smo tudi probali nekaj možnosti in ni delovalo...)

Ko se te malenkosti popravi, bi radi projekt dokončali in ga v kratkem zagovarjali pri profesorju vključno s teorijo. Ali je še kakšna malenkost ki jo moramo popraviti?

Lep pozdrav, Tim

[jaanos]

Kar se slike tiče je problem tukaj: 

https://github.com/1marcelspehonja/Sport/blob/827436c6ce2dede91e5a5fca8681b2dc21d2757c/static/stili.css#L33

Ker je CSS statična datoteka, ne bo mogoče uporabiti ROOT, pač pa enostavno uporabite relativno pot - ker je slika v isti mapi, lahko naredite

    background-image: url(domaca.jpg);

Mimogrede, preverite, če vam še kje manjka ROOT - opazil sem pri klicanju JavaScripta.

Kar se tiče preusmeritev, bo treba odstraniti / tako pred kot za ROOT, npr.

    redirect('{0}{1}/ekipe'.format(ROOT,str(sezona[0])))

[jaanos]

Kar se same baze tiče, imam sledeče pripombe:

• Trenutno v svoji bazi nimate nobenih referenc (tujih ključev) - glejte spodaj, kje vse bi jih morali imeti.

• Kot sem že napisal v #2, bi bilo smiselno ločiti igralce in trenerje od statistike ter ekipe od sponzorjev. Tako bi tabeli za igralce in trenerje imeli samo ID (kot glavni ključ) in ime (morda imate lahko celo eno samo tabelo za vse osebe), tabeli s statistiko pa ID (kot referenco na ustrezno tabelo) in sezono skupaj kot glavni ključ, ekipo kot referenco na ustrezno tabelo, in še vse ostale stolpce s statistiko. Pri ekipah bi lahko kot glavni ključ imeli kar kratico, poleg tega pa še ime; pri sponzorjih bi podobno kot pri statistiki imeli glavni ključ iz reference na ekipo in sezone, poleg tega pa še sponzorja.

• V tabeli uporabnik nimate glavnega ključa - najbolje bo, če dodaste ID tipa SERIAL, da se bo sam generiral. UNIQUE za uporabniška imena je seveda smiseln, smiselno bi bilo dodati še NOT NULL za ostala stolpca.

• Tabela priljubljeni naj sestoji iz reference na ID-ja uporabnika in igralca. Oba stolpca naj bosta skupaj glavni ključ, da ne bodo mogoče ponovitve.

[20timresnik]

Lep pozdrav, slika sedaj deluje, kakor tudi ROOT pri redirect-ih; hvala za pomoč.

Iz vaše druge pripombe sklepam da pomeni da moramo v bistvu čisto na novo napisati kodo, saj bi bila s trenutnimi tabelami zdajšnja neuporabna? Ne vem sicer kako bi lahko ločili sedaj podatke med sabo, na primer pri igralcih imamo sedaj združene podatke za vsa tri leta, potem pa če bi delali novo tabelo samo z ID igralca in imenom igralca, ne vem kako bi se klicali v drugi tabeli statistika na tega igralca ker samo statistiko igralca ne vem kako bi povezali z ID-jem tega igralca. V tabelo uporabnik bomo dodali ID tipa SERIAL in tudi UNIQUE da se ne bodo ponavljali uporabniki Pri priljubljenih smo v programu spisali poizvedbo, ki preveri da ne obstaja že priljubljen igralec za določenega uporabnika, tako da niso možne ponovitve. Lep pozdrav, Tim

[jaanos]

Ne bi bilo potrebno znova napisati vse kode, pač pa samo popraviti poizvedbe na spremenjenih tabelah (in morda nekoliko spremeniti nekatere poti).

Kar se tiče igralcev (in trenerjev), bo najlažje, da imate ID tipa SERIAL. Ko uvažate statistiko, preverite, ali igralca že imate v bazi - če je, potem uporabite njegov ID, sicer pa ga dodaste in uporabite ID dodane vrstice (lahko uporabite INSERT z RETURNING, podobno kot pri #3). Seveda to predpostavlja, da ni dveh igralcev z istim imenom - če bi se pa v prihodnosti pojavil kak tak primer, bi lahko ta igralca ločili, saj bi imela različna ID-ja.

Če bi potem v isti poizvedbi potrebovali tako statistiko kot ime, naredite ustrezen JOIN. Seveda se potem povsod sklicujete na igralce z ID-jem (ta naj se pojavi tudi v poti za stran o igralcu).

Vsaka tabela naj bi imela glavni ključ. Preverjanje duplikatov v sami aplikaciji včasih ne zadostuje - lahko bi se namreč zgodilo, da se med preverjanjem in dodajanjem baza spremeni in se tako vanjo izmuzne duplikat. Bolje bo, da v tem (sicer malo verjetnem) primeru pride do napake (ki jo lahko aplikacija ustrezno obravnava), baza pa ostane konsistentna. Konsistenca je tako zagotovljena tudi, če se baza spreminja mimo aplikacije (npr. z neposrednim uvozom podatkov).

[20timresnik]

V redu, razumem kako ste si zamislili da bi izgledale te tabele. Mi smo sedaj pridobivali podatke/obstajajo dostopni podatki za posamezno sezono od vseh igralcev skupaj; nimam ideje kako bi iz osnovne velike tabele(kar imamo na voljo od podatkov) lahko izluščili ven najprej posebej igralce za tabelo igralci potem pa še statistiko posebej za vsakega igralca v tabelo statistika. Ali bi lahko mogoče dali kakšen namig kako se lahko lotimo tega opravila?

Zanima me, ali lahko projekt/teorijo vseeno zagovarjamo tudi brez teh popravkov, ali brez tega ne moremo na zagovor? Smo malo v časovni stiski in ne vem kako nam bodo uspele predlagane spremembe, ker smo malo računali, da smo zaključili projekt, trenutno je pa veliko dela tudi z raznimi izpiti.

[jaanos]

Za uvoz bo najlažje napisati skripto, ki gre čez vrstice v igralci.csv ter, kot sem opisal v prejšnjem komentarju, sproti vstavi igralca (če ga še ni v bazi) in njegovo statistiko za dano leto. Mimogrede, v tabeli igralcev naj bodo seveda poleg imena tudi ostali podatki, ki se ne spreminjajo, torej država, višina, teža (ter morda leto rojstva namesto starosti).

Mimogrede, svetujem, da odstranite povezavo za dodajanje k priljubljenim, če uporabnik ni prijavljen - pri meni pri kliku pride do napake, saj se pot začne z //, kar Linux očitno razume kot pot na lokalnem omrežju. Če pa se vam zdi ta povezava smiselna, poskrbite, da se pot ne začne z //.

Glede na to, da sicer aplikacija deluje, se lahko z @alenFMF domenite za zagovor. Bi pa vseeno svetoval, da ustrezno uredite bazo, saj gre tukaj za osnovne principe organizacije podatkovne baze.