[ magrinjo @ 04.12.2017. 01:14 ] @
U tabeli korisnici imam polje za ID, ime i prezime, kao i polje za maticni broj.
U tabeli prodaja imam prodat proizvod, datum i cenu.

Kako bih mogao da spojim korisnika sa prodajom, tako da u pretrazi imam uvid koji je korisnik kupio koji proizvod, bez da spojim ove dve tabele u jednu celinu.

Hvala :)
[ djoka_l @ 04.12.2017. 07:18 ] @
Više mogućih načina:
1. U tabeli gde su podaci o prodaji, dodati polje ID_KUPCA
2. Dodati tabelu za vezu korisnici-prodaja (recimo korisnici_prodaja), koja bi imala polja id_korisnika, id_prodaje
3. Preko neke treće tabele (recimo, u fakturi imaš podatke o tome ko je naručio neku robu, kako bi izvukao adrese i poslao fakturu, zatim imaš vezu sa nekom tabelom knjiženja, pa preko toga vezu sa promenom stanja u magacinu). Okolo, naokolo i napravio si vezi između korisnika i prodaje. Naravno, metoda 1) je najlakša. Pravilo je, praviš tabele tako da lako dolaziš do podataka - dakle prema tome kakavi će se upiti puštati nad njima, a ne tako da izgledaju lepo na papiru.
[ magrinjo @ 04.12.2017. 22:00 ] @
Da, izabrao sam opciju "1".

U prodaji sam dodao ID_KUPCA i stavio sam da je u korelaciji sa tabelom `korisnici`.

U smislu same baze shvatam kako funkcionise, ali kako u vizuelnom smislu da pruzim "admin korisniku" mogucnost da moze vec postojeceg korisnika da spoji sa prodajom odredjene robe, odnosno da ga izabere?
Koji je najzgodniji nacin za to, mozda neko "live search" izlistavanje iz baze?
[ Predrag Supurovic @ 04.12.2017. 22:46 ] @
Magrinjo, iz iskustva, prodaja se sastoji od dva dela: jedan je zaglalvje dokumetna prodaje u kome se definise id prodaje, datum, kupac i ostalo sv sto ej vezano za prodaju i lista proizvoda koja cien prodaju koja se sastoji od id prodaje, id proiyvoda, cene i drugih podataka za svaki proizvod pojedinacno.

Vrlo je retka situacija da se sva prodaja sastoji iskljucivo samo od jednog proizvoda, mnogo je realnije da se prodaje vise proizvoda zajedno.
[ Zlatni_bg @ 05.12.2017. 01:00 ] @
Ja sam skoro radio jedan projekat za pc shop. Ukratko cu ti opisati tabele koje su bitne za porudzbine.

korpa --- sadrzi informacije o proizvodima u korpi pre realizacije porudzbine
-cartid - AI u tabeli, za svaki slucaj
-uid - id korisnika
-prid - id proizvoda
filed - 0 ili 1, u zavisnosti od toga da li je korisnik porucio proizvode ili su i dalje u korpi

porudzbine -- sadrzi informacije o celim porudzbinama
-id_porudzbine - unikatan broj za jednu porudzbinu, AI
-id_kor - id korisnika koji je izvrsio porudzbinu
-datum - datum kada je porudzbina napravljena
-obradjena - 0 ili 1, u zavisnosti da li je administrator realizovao porudzbinu

porudzbine_proizvodi -- sadrzi info o proizvodima iz individualnih porudzbina iz tabele porudzbine
-idai - AI broj u tabeli, ubacen zbog eventualnog kasnijeg koriscenja
-idporudzbine - vezivni broj sa tabelom porudzbine
-idproizvoda - povezan sa tabelom "proizvodi" iz kojih dobija podatke o specifikaciji proizvoda
-cena - cena po kojoj je proizvod porucen jer je promenljiva
-uid - id korisnika koji je porucio taj proizvod

Verovatno sadrzi i previse redova ali volim da ubacim ranije nego kasnije za slucaj da zelim da implementiram jos neku funkciju ili da lakse dodjem do nekih podataka.
[ Zlatni_bg @ 05.12.2017. 01:01 ] @
P.S. evo ga ceo model kako bi neki slican projekat trebalo da izgleda. Po meni, idealno je napravljeno kako bi olaksalo razmisljanje o zadatom problemu.
[ magrinjo @ 06.12.2017. 13:59 ] @
Hvala momci :)
[ nkrgovic @ 06.12.2017. 21:15 ] @
Uh, ja na ovo sto je zlatni poslao imam gomilu zamerki. Ukratko:

- Customer tabela treba da sadrzi samo ID, username i password, jer se to koristi za logovanje i na svim drugim mestima. Detalji idu u odvojenu tabelu, da rasterete bazu od citanja i mozda slanja nepotrebnih podataka u svakom upitu. Ako mislite da mozete da uradite SELECT ID, Username, Password, razmislite ponovo: Osim ako nemate covering index, db engine ce citati ceo red sa diska. Kad dodje do milion korisnika, pocece da boli.

- Osobine product-a treba da idu u odvojenu tableu, uz trecu veznu tableu koja vezuje svaki produkt sa osobinama. Onda mozes da radis i obrnuti search, tipa, daj mi sve products gde je boja "crvena". Dodatno, ako u tabeli ima i food_flavor i isbn_number, onda ne gine gomila null-ova u tabeli.

- Sta je koj' djavo parent_product ? Ako trebaju kategorije, to ide u odvojenu tabelu.

- Mora da postoji i Payment, a ne samo payment method. Dodatno, znam da je kao ilustracija, ali nikad, NIKAD ne ide card_number u bazu. Procesiranje placanja radi procesor, vi ne cuvate podatke o korisnikovoj kartici, samo ID iz payment procesora za refund. Da bi cuvali i procesirali kartice morate da imate PCI compliance, plust jos trista cuda - ne zelite to. Zapravo, payment_method je mozda i suvisna, ne cuvate podakte lakse vam je. Sta ce vam "payment method" ako je on "platio uplatnicom"?

- U product price ide i polje JE_AKTIVNA, plus index koji kaze da je kombinacija product_ID + Je_aktivan =1 unique. Onda izvlacenje cene za ID ide po tom indexu, a ne po WHERE DATUM najveci. Kad bude par miliona redova u tabeli, ubrzanje ce biti za red velicine, minimum.

Kad razrezis ove boljke, lepo se vratis za knjigu, prva, druga, treca nf, boyce-code i to je to.
[ Zlatni_bg @ 06.12.2017. 23:45 ] @
Ja sam poslao prvo verziju koju sam ja za sebe radio. Ova slika pomaze samo za razmisljanje ;)

Ja imam isto posebno tabelu sa specifikacijama proizvoda. Ali u toj tabeli su redovi `catid`, `spec1`, `spec2`... itd. Tu se unose vrednosti odredjene specifikacije, a u tabeli `proizvodi` imam `spec1name` na primer, gde se nalazi naziv prve specifikacije, recimo "frekvencija procesora".

Daleko od toga da je slika savrsena, ali je nesto sto sam ja koristio kao smernicu kako ne bih zaboravio neki deo. Nije za copy/paste nikako.
[ nkrgovic @ 07.12.2017. 09:19 ] @
Ma sve OK, ovo je forum, cisto diskutujemo. :) I ja sam samo nabacao ideje u pola jedanaest nocu :)