banjalukaforum.com

Da cujem misljenja ili prijedloge.

Firmw XY ima maloprodaju,i u tu svrhu koristi softver koji u pozadini ima bazu na SQL serveru,koja izmedju ostalog prati i stock level svakog artikla.
Dalje,firma zeli da ima i e-commerce site,koji moze da koristi iskljucivo mysql bazu. Ukoliko bi baza od e-commerce sajta imala i field interne sifre,identicno kao i u bazi od maloprodaje, da li bi moglo da funkcionise da ove dve baze putem nekih trigera i stored procedura obavjestavaju jedna drugu kad se stock level (broj),datog artikla te i te sifre promjeni,sto kroz maloprodaju,sto kroz e-commerce? Pada li na pamet nekome neko drugo rjesenje?

_________________
Viva Elena, Viva Nicolae!

Sto ne bi moglo, napravis linked server u sql management studiu i radis sta hoces kroz funkciju openquery('linked server', 'query').

Evo ti ovdje detaljnije opisano
https://www.packtpub.com/books/content/ ... erver-2008

Nemam pristupa SQL serveru, zato i pitam,a nemam ni iskustva sa istim,nisam bas database guy:)

_________________
Viva Elena, Viva Nicolae!

Onda se sprijatelji sa njihovim DBA-om

Joomla 3 moze preko php drivera da komunicira sa SQL serverom i na nju mozes staviti ecommerce modul, problem je sto je bagovito sve pa moras svaki modul i polje u bazi modifikovati da bi to radilo. Imas isto nopCommerce koji native ima podrsku za SQL, ali je ASP. Nedavno sam radio nesto slicno kao sto si opisao, naisao na toliko problema izmedju tih tehnologija, da sam na kraju odustao zbog moguceg ulozenog vremena, a malo para

Firma je isto imala neki svoj menagment softwer, koji vrsi unos proizvoda, medjutim sve je bilo zbrljano pa si mogao uzeti kupiti procesor od 17 incha, tako da su bile velike prerade kako u PHPu, tako i u njihovim bazama.

Baza za maloprodaju je ok,bazu za e-commerce ja radim,tako da mislim da bi sinhronizacijom ova dva unique fielda interne sifre proizvoda,koji vec postoje u prvoj bazi,to trebalo da radi.

_________________
Viva Elena, Viva Nicolae!

Mozes li napraviti da ecommerce koristi ista polja u bazi kao i taj program od firme? Onda bi se uneseni proizvodi reflektovali na stranicu automatski. Kod ovih sto sam vidio stara njihova solucija je bila da php vadi direktno iz baze preko PDO drivera proizvode, kesira ih u .htm i te htm cache fajlove vuce na server i prikazuje ih u joomli.

Samo cu dodati field interne sifre proizvoda,trebalo bi da bude dovoljno

_________________
Viva Elena, Viva Nicolae!

Kako ces sinhronizovati baze?

Pa samo ce dodati u istu bazu polja i na nju nakaciti ecommerce i vec postojeci software od prodavnice?

Vid sad giometra sto me zajebaje.Ja pitam jel se moze onako izvesti sinhronizacija,kroz neke trigere,kad god se u jednoj od bazi field stock level dekrementuje,da se to odmah sinhonizuje sa drugom bazom,on kaze da to moze,i sad me pita kako cu to uraditi?:))

_________________
Viva Elena, Viva Nicolae!

Reko ako nemas pristup SQL Serveru, da povezes te dvije baze, kako ces trigerom gadjati onu drugu bazu?

To ce uraditi firma koja ima pristup,mene je zanimalo moze li to tako ili ne.Ja cu manje vise isto to uraditi sa strane e-commerce baze.

_________________
Viva Elena, Viva Nicolae!

Možda je malo kasno za odgovor, ali evo ti neke ideje:
Trigeri nisu najsrećnije rješenje za ovakav tip sinhronizacije baza... Prije ili kasnije imaćeš probleme zbog recimo pucanja veze između 2 database servera, pa triger neće odraditi upis u bazu u firmi. Ili ćeš imati situaciju da istovremeno neko preko web shopa i direktno iz firme mijenju stanje zaliha nekog artikla, pitanje je ko tada ima "prvenstvo"?

Postoje 2 načina da se ovo odradi kako bi izbjegao glavobolje i probleme u sinhronizaciji baza:
1. Replikacija ili neka slična tehnika sihronizacije baza
2. Svi podaci ti budu u jednoj bazi, znači da se i iz firme i sa web shopa kačiš na 1 bazu

Druga varijanta je svakako puno jeftinija, ali zahtijeva da riješiš konekciju sa web shopa prema SQL server bazi (recimo, koristi ODBC).

Druga varijanta je malo sporna,malo vise sporna,zbog razlicitog dizajna bazi,tj samih polja.Ici cemo preko web servisa,obe baze se nalaze pod istim domenom sto se tice ip opsega.

_________________
Viva Elena, Viva Nicolae!

Druga varijanta ne mora uopšte biti sporna: Držiš sve u istoj bazi, ako ti je problem dizajn i struktura tabela onda napravi "duple" tabele... Web sajt upisuje u svoje tabele, aplikacija iz firme upisuje svoje tabele... Interna SQL server replikacija (unutar iste baze!) ili neki ETL job ti mogu syncati te tabele međusobno, po potrebi i transformisati podatke...

Lokacija DB servera u mreži uopšte nije bitna za ovu priču, tj. to da li su u istom domenu, u istom IP opsegu... Sve se to da podesiti, bitniji ti je način na koji se syncaju podaci između baza ako već koristiš 2 baze...

Za drugu varijantu bih se morao baciti na php rewrite,za koji nemam vremenskih resursa.Za sad idemo sa sync izmedju 2 baze, samo 2 fielda,interna sifra,i stock level,moguce da cemo morati i ubaciti dodatni layer u vidu nekog servisa,mada bih ja vise volio da ide samo baza ka bazi.Btw,radi se o 2000+ proizvoda.

_________________
Viva Elena, Viva Nicolae!

Koristim MySql bazu i pokusavam primjeniti FIFO metodu na tabele. U tabelama imam datetime kolonu u kojoj se upisuje vremenski zig uz svaki podatak.
Ideja je da napravim before insert ili after insert triger, koji bi provjeravao broj redova i ako je red visi od limita, on bi brisao red sa najstarijim vremenskim zigom.

Tabela i triger na kom testiram ideju:





Problem je sto mi izbacuje sledecu gresku:


Izgleda kao da insert zakljuca tabelu i ne dozvoljava brisanje reda. Postoji li nacin da se ovo nekako prejebe?

_________________
Eins, zwei, eins, zwei build an empire, very Prussian!
Exhaust gasses go into the turbocharger and spin it, witchcraft happens, and you go faster.

evo jedno objasnjenje sa stack-a za slican problem



probaj before insert

Isto i za before.
Prebacicu taj posao na servis koji popunjava bazu...

_________________
Eins, zwei, eins, zwei build an empire, very Prussian!
Exhaust gasses go into the turbocharger and spin it, witchcraft happens, and you go faster.