Trimis: Sâm Feb 06, 2010 6:40 pm Titlul subiectului: as dori un sfat de la un expert mysql
Buna la toata lumea
Sunt nou pe aici si am nevoie de un sfat valoros.
In acest moment lucrez la un soft de retail, care foloseste mysql. Acesta suporta mai multe gestiuni (magazii).
Promblema mea: Sa fac cate un tabel pentru fiecare magazie? sau sa fac o singura magazie iar produsele sunt grupate dupa un camp suplimentar care este magazia?
Trebuie sa lucreze cu peste 8000 de produse in stoc
Data înscrierii: 20/Apr/2005 Mesaje: 5059 Locație: Toronto
Trimis: Sâm Feb 06, 2010 8:31 pm Titlul subiectului:
8000 de inregistrari e o nimica toata. Altii discuta de milioane de inregistrari.
Dupa mine, daca toate magaziile au exact aceeasi structuta a bazei de date atunci e o singura tabela cu un cimp ce face diferenta intre ele. De exemplu locatie sau vreun cod al magaziei.
Adica:
Locatie Produs Stoc
-------------------------------
1 Produs 1 10
1 Produs 2 0
2 Produs 1 5
...
Adica ai magaziile din Locatiile 1 si 2 aici, fiecare cu produsele lor. De fapt ar trebui sa ai doar ID-ul produsului ale carui detalii le tii intr-o tabela de Produse (nume, unitate de masura, categorie, etc.) _________________ Bloguri: News @ Programare.org, ITist, Toronto @ Weblog.ro
Trimis: Sâm Feb 06, 2010 11:20 pm Titlul subiectului:
Ms de raspuns. Pentru 8000 de inregistrari il fac in prezent, insa pe mine ma intereseaza cam cat o sa duca sistemul. Si daca e mai rapida o varianta ca alta in cautari si in updatari
Sa presupunem urmatoarea situatie: 4 gestiuni, fiecare cu cate 30.000 inregistrari, asta inseamna ca voi avea in tabel 120.000 inregistrari.
Deasemenea fiecare magazie are cate 5 POS-uri, asta inseamna ca in total 20 pc-uri cauta produse in respectiva tabela (dupa codul de bare, sau dupa nume) si scade stocurile. + back-office-urile
Testele cu 6000 inregistrari sunt foarte multumitoare
Un server quad core, 2 g ram ar duce lejer si rapid asemenea situatie?
Cand se face o vanzare se mai adauga si in log alte inregistrari, care presupune inca un tabel cu inregistrari care va fi mult mai mare dupa un an de activitate.
In aceasta situatie, care este cea mai rapida solutie?
eu m-am gandit ceva in genu: insa nu stiu daca este mai rapida varianta cu tabele separate (cautari, updatari, adaugari, etc)
Data înscrierii: 28/Dec/2005 Mesaje: 1758 Locație: c:\
Trimis: Sâm Feb 06, 2010 11:53 pm Titlul subiectului:
un sql server ar trebui sa fluiere cu 100,000 inregistrari si daca tabelele sunt scrise (proiectate) cu picioarele.
Eu am lucrat in urma cu ~2 ani la un mic proiect care facea managementul unor produse aflate in diverse magazii, si tabelele cu stocul magaziilor era... unul. Fiecare rand din tabel avea un camp care preciza in ce magazie (Id-ul magaziei - magazie definita in alt tabel) se afla. S-ar putea sa fie mai rapid sa faci 10 tabele pentru 10 magazii, insa e mai mult de munca la codat, si cand o sa trebuiasca sa adaogi/elimini o magazie nu as vrea sa fiu in locul tau.
Trimis: Dum Feb 07, 2010 12:15 am Titlul subiectului:
Cu tot respectul nu cred ca e nevoie de SQL Server sau Oracle pentru asa ceva.
MySQL (community edition ar trebui sa fie suficient) In caz de nevoie se poate trece si la Postgresql. Am lucrat personal in 2004 cu un server Postgresql cu peste 2.000.000 de inregistrari pe tabela si mergea fara probleme (cu indecsii pusi pe coloanele search-uite mai des evident ) .
Cat despre design este suficienta o tabela cu un camp separator (din punctul meu de vedere) daca nu sunt si alte diferente majore intre magazii.
Ai grija doar ca in practica e mai rapid sa lucrezi doar cu niste ID-uri, nu identificarea magaziei prin numele ei intreg. Doar ocupa spatiu aiurea, iar un index cu valoare intreaga (numerica) poate face minuni.
Adica ai tabelele Magazii (id, nume), Produse (id, nume, pret, ...), Stocuri (id magazie, id produs, cantitate, ...).
Pt. cazul tau de mai sus e aiurea sa ai "adidasi" cu un pret in 'magazie1' si altul in 'magazie2' (pretul se repata degeaba pt. fiecare magazie, ar trebui o singura data pt. un produs).
Incearca sa cauti mai multe materiale de citit despre baze de date, optimizarea lor si aducerea la diverse forme normale (cauta asta co google), lucruri fara de care aplicatia ta va parea una scrisa cu picioarele, ca si de catre amatori. Nu e greu, trebuie doar sa citesti citeva materiale pe tema asta. (vezi de exemplu si asta, chiar daca nu e MySQL pt. ca notiunile de baza sint aceleasi) _________________ Bloguri: News @ Programare.org, ITist, Toronto @ Weblog.ro
Trimis: Dum Feb 07, 2010 2:40 am Titlul subiectului:
asta e problema mea... daca "fluiera" cu un anumit volum de inregistrari...
deocamdata o sa fac un singur tabel... mai am timp sa ma orientez daca e grupat dupa index sau dupa nume...
Am acces la codul unui asemenea soft si gruparea este dupa nume, nu dupa id-uri...
de exemplu... ar putea duce un magazin gen selgross, metro?
Data înscrierii: 20/Apr/2005 Mesaje: 5059 Locație: Toronto
Trimis: Dum Feb 07, 2010 5:38 am Titlul subiectului:
ShadowElf, vad ca nu vrei sa inveti si continui sa crezi in lucruri gresite.
Problema cu selgross sau metro ar fi ca m-as mira sa se bazeze pe software-uri scrise pe genunchi, de persoane ce nu stiu ce-i ala un LEFT OUTER JOIN sau INNER JOIN, de exemplu. Eu ti-am dat niste link-uri de invatat daca vrei, daca nu si-asa e bine.
Programatorii profesionisti care folosesc o baza de date stiu cei ala un index, un join intre 2 sau mai multe tabele dupa niste chei si lucrurile absolut de baza de arhitectura bazei de date. Pur si simplu cum vrei tu nu se face, desi desigur nu-i interzis prin lege.
Raspunsul simplu e ca o baza de date poate duce multe, inclusiv cod scris foarte-foarte prost. Si asta chiar daca are sute de mii sau milioane de inregistrari. Sigur tu il scrii cum poti si cum stii, problema e a altora care ar da banii daca nu sint in stare sa faca diferenta intre un soft scris bine sau nu, intre o arhitectura elementara sau lipsa ei.
Trimis: Dum Feb 07, 2010 1:39 pm Titlul subiectului:
Citat:
asta e problema mea... daca "fluiera" cu un anumit volum de inregistrari...
Bai, da` cit de greu e fata sa-ti populezi baza aia de date si sa vezi exact cit duce la tine? De cind povestesti aici nimic, faceai aia de o mie de ori. Populeaza-ti baza aia cu niste multe date si fa diverse query-uri alambicate sa vezi cum se misca. Just do it.
Trimis: Dum Feb 07, 2010 6:26 pm Titlul subiectului:
ITist, nu sunt chiar un novice in domeniu, si prin link-urile alea nu am aflat nimic nou. La inceput ma concentram si eu pe optimizarea bazei de date "la sange", fara date duble, doar id-uri, etc. Insa in practica s-a dovedit mult mai usor sa mai faci rabat de la asta in favoarea unei codari usoare. Astfel, in anumite situatii se pot face selectii de date mult mai usor daca tii anumite date duble. + te ajuta in anumite situatii sa refaci o baza de date daca ai vre-o buba cauzate de socuri de curent, alte erori care pot aparea in afara de codarea gresita.
Adevar este insa ca nu am avut de a face cu milioane de inregistrari, si din aceasta privinta am cerut un sfat de la un "expert" sau cineva care a mai facut asa ceva, nu de la cineva care stie teorie, asta stiu si eu, dar practica bate teoria in multe situatii.
Joinul nu mi este strain, si incerc sa nu fac o aplicatie scrisa pe genunchi.
Insa cand faci o selectie "Cele mai bine vandute produse, in perioada cutare - cutare, din grupa cutare, care are numele like xxx cu preturile intre si intre care expira in maxim xxx zile si cu discount de mazim 10%", daca mai dublezi olek datele o sa fii surprins cat de usor faci chesia asta.
Daca nu am dreptate astept sa fiu corectat. Poate m-am dereglat eu pentru ca nu am lucrat cu un volum imens de date.
Pana in prezent sfatul lui jos8cal este cel mai valoros. Voi face niste teste chiar eu. Nu pot insa simula 20 de calculatoare care lucreaza simultan cu cereri, inserari si updatari in acelasi timp.
Data înscrierii: 20/Apr/2005 Mesaje: 5059 Locație: Toronto
Trimis: Dum Feb 07, 2010 6:53 pm Titlul subiectului:
ShadowElf, fie cum zici tu. Sint de acord ca de multe ori e mai bine sa duplici niste date, insa nu si pt. cazul tau. Gindeste-te simplu: sa zicem ca ai 100.000 de produse in 10 magazii. Numele acelor magazii vine scris pt. fiecare produs in parte, adica fix de 100.000x10 = 1 milion mare si rotund. In plus numele produselor vine repetat de 10 ori fiecare, si la fel pretul (pt. fiecare magazie in parte). Iar toate astea cind alternativa logica e sa tii fiecare separat, 10 inregistrari pt. magazii cu ID-ul lor, produse o singura data toate cele 100.000, nu 1 milion de inregistrari pt. ele chiar daca in realitate sint doar 100.000.
Tu crezi ca duplicarile alea de date o sa ajute la ceva?
In plus, daca vrei backup la toate astea faci backup, si de acolo le refaci dupa ce eventual ti-ar crapa, nicidecum din niste tabele corupte in care nu mai stii cum sint datele (toate reperate de N ori). _________________ Bloguri: News @ Programare.org, ITist, Toronto @ Weblog.ro
Trimis: Dum Feb 07, 2010 8:17 pm Titlul subiectului:
in concluzie:
Daca fac un tabel:
id1 | magazie1
id2 | magazie2
in3 | magazie3
si la produse, bag id-ul in loc de numele magaziei economoisesc mult spatiu si in cautari o sa fie mult mai rapid? sau o sa fie o idee mai rapid si este facuta ca la carte?
Data înscrierii: 20/Apr/2005 Mesaje: 5059 Locație: Toronto
Trimis: Dum Feb 07, 2010 9:23 pm Titlul subiectului:
Tabelul magaziilor il faci asa:
1 | magazie1
2 | magazie2
3 | magazie3
Adica ai ID numeric nu stringuri. Apoi in tabelul produselor (cu ID-ul magaziei si ID-ul produsului) ai indecsi pt. id-ul magaziei si id-ul produselor.
Economisesti evident mult mai mult spatiu iar ca viteza esti tot cam pe acolo ca nu cred ca diferenta sa fie sesizabila cu ochiul liber. In plus fiecare informatie e pastrata intr-un singur loc. Daca schimbi de exemplu numele magazieie sau al prodului nu mai trebuie sa faci update in alte mii de inregistrari (ca e intr-un singur loc, legat prin acel ID ce nu se schimba).
Ora este GMT + 2 ore Du-te la pagina 1, 2Următoare
Pagina 1 din 2
Nu puteți crea un subiect nou în acest forum Nu puteți răspunde în subiectele acestui forum Nu puteți modifica mesajele proprii din acest forum Nu puteți șterge mesajele proprii din acest forum Nu puteți vota în chestionarele din acest forum
) .
