Spojiti redove u tabeli, sumiranje kolone kolicina...zatim update

Zdravo svima,

kako mogu spojiti redove po artikal_id i user_id, sumirati kolicinu, zatim UPDATE iste te tabele `korpa` tim rezultatom, da eliminišem duple artikle.

Može li se ovo riješiti jednim upitom. Jasno mi je grupisanje i zbir,ali kako taj rezultat snimiti u tabelu, a izbrisati duple `artikl_id`?

Izgleda da je cijeli forum na odmoru :)

Ne valja ti prilozena create skripta.... primarni kljuc (id ili artikal_id?)
Ako vec uradis neki "select..group", stavi ga u temp tabelu, orginalnu isprazni, pa vrati.

nista bez privremene tabele?

evo neki se vratili sa odmora .. sad dal smo se odmorili to je pitanje



nemoj ovo uzeti licno, ja postajem extremno alergican (a i ova koza koja mi otpada sa ramena ne pomaze) na izraz "kako da spojim redove" .. ja ne znam gde vas to uce i ko vas to uci ali aj probaj na srpskom/hrvatskom/makedonskom/engleskom/bugarskom ili koji ti je vec jezik priljezan napisati to tako da i tvoja devojka to razume :) ... redove mozes da spojis tako sto ce da ih otstampas pa uheftas, mozes i sa lepkom za papir, tutkalom ..

u racionalnoj algebri join moze da bude na gzilion nacina (natural, equi, semi, anti, outer, inner, left, right, full... pa onda kombinacije .. ) tako da "ja bi da spojim" .. (mozda sam preosetljiv narednih par dana dok ne otpadne ova izgoretina pa prestane to da me nervira :D )



obzirom na sta sve moze da se ugura u unije i subselecte svasta se danas moze nazvati "jednim upitom", da li je to optimalno resenje sa jednim upitom to je vec pitanje.


brisanje duplikata je uvek problem. i to ogroman. to je proces koji realno ne moze da se uradi "kako valja" (koji duplikat da obrises? prvi, drugi? po kom uslovu ces da odlucis koji ces da obrises?) i to je obicno zato sto to u startu znaci da je baza lose dizajnirana. ako imas duplikate to je zato sto si zaboravio da postavis neki unique key




ne valja ti ovo, kaze: ERROR 1072 (42000): Key column 'id' doesn't exist in table
dakle u startu si dao create koji ne radi, nisi proverio datu sa kojom mi treba da ti pomognemo, to je generalno nepostovanja ljudi od kojih ocekujes pomoc (ok, desava se to i najboljima, takve greske mislim, ne to oko postovanje nije frka, ali u tvom slucaju ovakav create samo dodatno zamucuje stvarni problem)

ako ti je artikal_id PK onda nemas duplikate :D dakle nije posto ne bi postavljao pitanje .. sta je ID ?
ako izignorisemo pricu sa PK, kada imas duplikat, opet, po kom principu odlucujes koji ces da obrises?

kapiram da ti zelis da obrises SVE za neki artikl_id i napravis novi koji ce imati sume za sve stare artikl_id ... ako je to nesto sto treba da radis "vise puta" onda batali posao, nije za tebe, dakle "sinko tako se ne pravi avion", mora se redizajnira ceo taj sistem, ako to treba da uradis "jednom", dakle redizajniran je sistem koji je nekad neki komsijin sin "dizajnirao" i greske su pronadjene i opravljene ali je data u .!. i sada mora nekako na misice da se dovede u konzistentno stanje, onda lepo rename te tabele u "tabela_smece", create nove tabele sa kljucevima kako treba i onda jedan insert select i kada proveris da je sve ok drop "tabela_smece" i resen problem... obizirom da problem resavas jednom da li ces da ga resis iz jednog upita, iz 3 upita, iz skripte ili stored procedure who freaking cares .. posebno sto ovako presipanje iz jedne u drugu tabelu ne diras original datu dok nisi siguran da si dobi oizlaz koji zelis

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ti Bogdane imaš pravo i da biješ (prut pa po rukama - kao nekad učiteljica), nema zamjerke... :)

kasno sam primijetio da imam grešku na primarnom kljucu i nisam mogao izmijeniti.

Nije to greska u dizajnu nego sam ja htio malo da "pojednostavim" stvar.

U tabeli se još nalazi i polje session_id koje zavisi od IP-a,da li je user logovan, koji browser koristi, itd...

Nisam htio da prisiljavam korisnike da se registruju da koriste korpu, a da oni koji to hoće imaju tu opciju.

Ako je korisnik koji nije prijavljen počeo sa kupovinom i nekom momentu se prijavi u sistem, moguće je da je imao u korpi nešto od prije, a ja neću registrovanim korisnicima brisati sadržaj korpe, onada se može desiti da u korpi ima iste artikle sa različitim kolicinama.

Uradio sam ja to uz pomoć PHP-a, ali hajd reko možda može i jedan upit to riješiti.

ima smisla za create, nema smisla za ovo presipanje, neces valjda da presipas to non stop?



hm, ne svidja mi se nikako to resenje.

ti moras da imas "korisnika" kada je korpa u pitanju, da li je on "registrovan" ili "anonimus" svejedno mora da bude unique korisnik inace sajt nece raditi kako treba zar ne.

scenariji koji te zanimaju su

1. anonimus je zavrsio kupovinu, platio i otisao sa sajta - sta sad, on nema nacin da se vrati da pogleda svoju istoriju (nije registrovani korisnik), tebi njegova istorija ne znaci nista (nemas pojma ko je sta je ne vezujes ga za sledecu kupovinu .. ostavljanje kukija je ruzna praksa koja se koristi ali svejedno ..) tako da je realno njegova data beskorisna, njegov user_id nikad vise neces iskoristiti opet. pitanje ovde je da li ces takvog korisnika (sa svom njegovom datom) obrisati ili ostaviti u bazi ... ja licno ostavljam te usere u bazi ali to je sad pitanje biznis logike, ne same baze .. svakako ta data je funkcionalno beskorisna, moze da ima smisla za neki data mining process flow mining etc etc ... tj za razne neke analize kasnije ali sto se tice "prodavnice" to je visak

2. anonimus u nekom trenutku odlucuje da postane registrovan korisnik (2.1 -> uloguje se u postojeci nalog, 2.2 registruje novi nalog). u varijanti 2.2 gde registruje novi nalog taj user_id koji si mu dodelio kada je poceo da pravi korpu samo promeni tip iz anonimus u registrovan i prica je gotova, data je tu pa je tu etc etc ... dakle nemas nikakav problem, u varijanti 2.1 gde se sad loguje u postojeci nalog ti sada sve sto je radio kao user_id=X treba da prebacis u user_id=Y sto realno nije problem sa single update-om da odradis.. i opet si u konzistentnom stanju ...

ni u prvom ni u drugom scenariju ne postoje nikakvi duplikati ?!

e sad postoji ono treci virtualni scenario, u jednom tabu je ulogovan a u drugom tabu je neulogovan, tj u jednom tabu puni korpu kao anon, onda u drugom tabu uloguje se i nastavi da puni korpu, ti tu treba da pri logovanju detektujes 2.1 scenario i samo sledeci put kad klikne u onom neulogovanom tabu da automatsku udje u ulogovan sa svim itemima vec u korpi .. nije neki problem, doduse nema veze sa mysql-om :D

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

U scenariju 2.1 može da dođe do duplikata i taj scenario mora da obradi,
taj single update ne bi smeo da napravi duplikate.

teoretski bi moglo, i na dosta sopova u takvom slucaju se desi bas to, imas isti item 2-3 puta sa razlicitom kolicinom ali to se spreci pravilnim koristenjem baze... fora je samo da ne uspe da doda item u cart od trnutka kada krene proces logovanja dok se proces ne zavrsi. obzirom da taj proces treba da traje <1ms tesko da moze da stigne da promeni tab i klikne tamo nesto, a cak i u tom slucaju moze da se spreci sa malo lokovanja :D

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ne, nisam mislio na to - ne može tek tako da samo prespoji item-e sa anonymous usera
na registrovanog usera već mora da uradi neku vrstu uparivanja da ne bi dobio više rekorda sa istim prod id-em.

razmisli, ne moze covek da bude na sajtu istovremeno kao neulogovan i
kao ulogovan
sto znaci ne moze da ima istovremeno cart kao neulogovan i kao ulogovan ...
jedino ako na logout ne brises cart pa kad dodje posle 5 dana klika kao
neulogovan pa se uloguje pa mu vratis stari cart + novi cart .. to je po
meni generalno ocajan flow .. ali ako napravis tako, onda da, u
situaciji 2.1 moras da ih pospajas

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Baš na ovo sam mislio:


Možda je tehnički očajan ali je svakako bolji i za korisnika a i za biznis,
inače ga valjda ne bi koristile ozbiljne online prodavnice.
Možda je empty cart na logout opet neki standardan flow ali ga ja stvarno nisam zapazio.

da dosta prodavnica ima to da ti cuva stari cart, mene to licno do jaja
nervira, ja brisem cart kad istekne sesija :D no kao sto rekoh nema to
veze sa bazom, 100 ljudi 100 cudi .. a ja nisam bas poznat po tome da su
moje zelje i cestitke kako nesto treba dizajnirati popularne :D

e sad to je npr nesto gde bi po meni stored procedura bila ok resenje
(kursor po anon rezultatima, insert into reg on duplicate key update, a
key je id,article_id, delete where id=anonid)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

ovako sam ja razmišljao:

- korisnik nije prijavljen, puni korpu, ima svoj session_id, user_id = 0;

- kada se prijavi session_id ostaje isti, a ja dalje prelazim na user_id;

- kupac se odjavljuje, korpa ostaje i kada sljedeci put dođe nije prijavljen, puni korpu, i prijavljuje se;

Tada dolazi do duplikata.

(A tu ima priča kada korisnik koristi više browsera pa je u jednom prijavljen a u drugom nije i na kraju se prijavlju i ovom drugom.)

- preko PHP-a uzmem sve iz korpe za user_id, sumirane kolicine grupisane po artikal_id, napunim array,

- pravim transakciju

1. brisi sve sa user_id = nesto

2. insert sumirane količine grupisane po artikal_id




inače ne reigistrovanim korisnicima ne planiram čuvati korpu, trajat će koliko traje njihova sesija.

odosmo jos dalje od mysql-a ali .. zasto ne kreiras korisnika (temp)
kada krene da puni korpu a nije ulogovan? obicno se tako radi, na taj
nacin ne dupliras kod, lakse je za administraciju etc etc ..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

ali opet se vracamo na isto, ako je punio korpu dok nije prijavljen kada se prijavi, a vec je imao nesto u korpi moguci su duplikati...

možes li mi objasniti zasto nije dobro ovo grupisanje, a zatim brisanje?