Kako spremiti ul-li listu (atributa) u bazu?

Pozdrav svima.

Evo pitanje za koje odgovor ne mogu izguglati, a nisam siguran kako napraviti.

Imam tablicu:

gDoba
1 proljece 21.3. bla bla…
2 ljeto 21.6. bla bla…
3 jesen 23.9. bla bla…
4 zima 21.12. bla bla…

I svako doba ima neke svoje (bla bla) atribute…

Ali svako godisnje doba ima i svoje prednosti i mane. Ali je više prednosti i više mana. Recimo za proljeće:

proljeće prednosti

  • super je
  • bas je cool
  • predivno je

proljece mane

  • nije bas nesto
  • ruzno je
  • ne svidja mi se
  • bezveze je

Ali svaka prednost i svaka mana je manje-vise unikatna. Znaci, nema ponavljanja, tj. ne postoji mogućnost da recimo ljeto i jesen mogu imati iste prednosti i/ili iste mane. (Primjer je potpuno izmisljen.)

I kako sad sloziti bazu?

  1. sve ul-li prednosti strpati kao jedan value od pojedinog godisnjeg doba? Pa tako i za mane? Ali onda moram hardkodirati ul-li tagove kao value, kako bih to mogao prikazati ovu listu kao listu na html stranici?

ili

  1. Kreirati zasebne tablice prednosti i mane uz relationship one to many s tablicom gDoba? Kako onda to sloziti?

prednosti
1 super je 1
2 bas je cool 1
3 predivno je 1
4 superiska 2
5 blabla 2
6 blabla 3…

…gdje su ovi brojevi u trecem stupcu foreign ID od primary ID iz gDoba tablice. Jel to štima?

Edit: tab ne radi u ovom editoru…

Ili neki treci nacin?

Ovo mi je prva baza koju slažem, pa ima još dosta nejasnoća…

Hvala.

  1. Tablica – god. doba
  2. Tablica – popis prednosti i mana
  3. Tablica – vezna tablica 1. i 2. tablice

Uff, znači neki treći način. Moram priznati da mi nije jasan.

Prvo mi nije jasna ova vezana tablica. Na teoretskim objašnjenjima svi crtaju vezane tablice, međutim na praktičnim primjerima nikada tu vezanu tablicu nisam vidio u “fizičkom” obliku. U smislu, nikada nisam vidio tu tablicu unešenu u bazu. Jesam li dobro shvatio da se te vezane tablice dobiju isključivo “virtualno” s postavljanjem querija prema bazi? A fizički su samo dvije tablice u bazi?

Drugo mi nije jasno zašto prednosti i mane u istu tablicu? Kako da razdvojim listu prednosti s listom mana?

  1. Tablica
    Id_doba
    Id_prednosti_mane

Nije ti jasno zato jer prvo moras nauciti relacijske baze. Vezna tablica je tablica koja ima dva i vise strana kljuca. Fiizicki su tri tablice.
Kad prodjes teoriju onda ces i znati sto su normalne forme, pa ce ti biti jasnije.

Nema prednosti i mana, nego postoje pravila za projektiranje baza -> normalne forme.

U odnosu na ovo, je l’ spisak (fokus samo na prednosti od ljeta npr.) prednosti za ljeto konačan/ponudjen ili se kreira novi unos svaki put, nevezano za dotadašnje unose?
Drugim riječima, prednosti za ljeto će u konačnici imati 50 poruka ili hipotetički neograničeno?

Imaš tablicu godišnja doba & mane i prednosti, relacija više prema više, potrebna ti je vezna tabela. Prolistaj ili po netu malo pogledaj NF što ti neko reče da ne bi dolazilo do problema i zagušivanja baze ponavaljanjem nekih gluposti i zatrpavanjem, tako što se više pojednostavi i sve funkcionište najbolje što može :slight_smile:

Prošao sam 15-ak sati tutorijala o dizajniranju baza. I nigdje nisam vidio joined table u fizičkom obliku. Koliko sam shvatio, ta joinded table bi se na webu prikazivala tako da se kreira “on the fly” nakon što upišeš nešto u stilu:

SELECT godisnje_doba, prednosti
FROM gDoba
INNER JOIN prednosti
ON gDoba.doba_id = prednosti.doba_id

I kad bi to isprintao unutar HTML, stvorila bi se ta povezana stranica.

E sad, kao što rekoh, tek sam prošao teoriju i neke stvari mi još nisu jasne, pa me ispravi ako ovo gore ne stoji.

Što se tiče normalizacije, pa mislio sam baš zbog normalizacije izdvojiti prednosti i mane u zasebne tablice, jer jedini način da ih po nečemu razlikujem (unutar jedne tablice) bi bio novi stupac koji bi diferencirao što je od toga prednost, a što je od toga mana, a što bi dovelo do repeating data, zbog čega bi opet trebalo taj repeating data izdvojiti u zasebne tablice. Ili sam i tu nešto pomiješao?

Ne. Prednosti je fizicka tablica. Onda nisi dobro pratio tutorial. Svaka tablica u query-u je ujedno i fizicka tablica. Postoje view-i na bazi, pa materialized view i sl., i to je druga tema.

Kazes 15 sati, to je na faxu predmet od 2 semestra, svaki semestar, barem 4 sata(2+2),

To je: 60 sati predavanja + 60 sati vjezbe ukupno.

Fiksno. To ne ubacuju neki useri, nego je to moja interna baza s kojom gradim website. I da bih imao bolju kontrolu nad svim podacima, odlučio sam sve strpati u bazu. Nekad se doduše može dogoditi da ja skužim da proljeće ima još jednu prednost, pa da sad ne tražim php file u kojem sam to napisao, lijepo sve pronađem u bazi. Ali, radi se o 5-6 prednosti i isto toliko mana.

Inače, ja te podatke sve držim na svakoj stranici unutar polja. Imam polje za prednosti, polje za mane, polje za ovo, polje za ono… I onda izvlačim te podatke unutar HTML-a. A budući da se ne radi o nekakvom blogu, nego je cijeli web popis nekih, nazovmo kao proizvoda i svaka stranica predstavlja svoj proizvod, shvatio sam nakon 4 stranice da će to biti kaos i da trebam bazu, radi lakše kontrole atributa svih proizvoda.

Tko te tako ucio?
Svi podaci se drze u bazi.

Drže se u bazi ako poznaješ rad s bazama. Ja ga ne poznajem, pa radim kako znam. Sad sam počeo učiti o bazama, jer web koji radim je prekomplicirano za podatke držati u varijablama i poljima.

Imaš link na neki tutorijal gdje je prikazano kako se iz dvije tablice fizički gradi treća tablica?

Nisi, u redu je tako.

@elembe
Edit 2: ispravljena greška.

Zasto nisi nekog pitao da ti preporuci literaturu, tutoriale i sl.?
Znas kako se kaze, neznanje nije opravdanje.

Nisam ni ja znao, niti se bilo tko rodio sa znanjem.

Mene su isto popljuvali na jednom forumu, negdje 2002. ili 2003. , kad sam pitao osnovna pitanja i kad sam ucio baze. Kad sam vidio da nista od toga, nabavio literaturu i ucio i pitao ekipu koja zna i sva sreca pa su bili voljni pomoci i odgovoriti strpljivo na svako pitanje.

Danas je jednostavnije jer je internet jeftin, 2003. spajanje sa sugavim modemom od 56 k, preko karneta, 1 sat 3.6kn po danu i od 19.00 do 7 po cijeni od 1.8 kn.

Dva sata dnevno po 1.8, ukupno 3.6 kn x 30 dana = 108 kn, sto je onda bilo puno.

Prvo cekas spajanje, pa moras paziti koliko si bio spojen, pa ti netko vice, skine se s interneta jer moram telefonirati, itd…

Danas je 10 x lakse, ima hrpa tutoriala, video tutoriala itd…

1 Like

Literatura:
Udemy
Php knjiga – pogledaj sto se nudi na amazonu, obicno u knjizi bude jedno pogljavlhe o bazama, kratko, ali dovoljno za pocetak.

ucio sam iz slijedece literature:
1.skripta sa fera ( sql)
2.skripta sa pmf-a (fizicki odsjek, baze podataka)
3.skripta sa fera - projektiranje informacijskih sustava
4.mysql i postgresql manual
5.oracle dokumentacija
6.wikipedia
7.razni tutoriali

Pogledaj na tutorials point i vidi ovdje:
http://tutoriali.org – ovdje ima sa fera, pmf-a, fon-a

1 Like

E dobro, baš gledam, pa mi nije bilo jasno. :slight_smile:
Ono prvo što si nacrtao bi bilo relation many to many? Kada bi više godišnjih doba moglo imati neke zajedničke prednosti i mane?

2003.? Ajoooooj… Eto, kad starac ide učiti SQL. A na netu je od '94. :slight_smile:

Ono prvo nije bilo ništa. Bila je greška i u drugom a sada: treća sreća. :smiley:
Ne treba ti many-to-many (ako je request takav da neće biti isti atributi) već dvije 1:m tabele.
Ne u istu tabelu zbog toga kako si i sam naveo da ne mora da znači da ćeš imati uvijek isti broj pro/con za odredjenu sezonu.

Hvala.

Hvala i svim ostalima.

Da, ok, hvala na trudu!

1 Like