bluebird Posted September 1, 2010 Report Share Posted September 1, 2010 Sveiki! Šajā tematā esmu zaļš cik zāļš vien var būt, bet ar kaut ko ir jāsāk. Strādāju vienā poligrāfijas uzņēmumā. Ir tāda lieta kā spiedes ar kurām spiež no loksnēm ārā formu kastei. Ar gadiem tās spiedes sakrājās daudz. Lai spētu atrast tās spiedes līdz šim vairākus gadus dati par spiedēm un produktiem tika Word dokumentā. tagad ir tā, kad daļa datu ir word dokumentā un daļa vienk sarakstīta uz lapām tabulās. Reāli, kas jāsagatavo aparāts darbam, tad reizēm liels čakars kamēr atrod kurā plauktā stāv spiede. Jāiet cauri visiem izdrukātajiem dokumentiem... jāvelk ar pirkstu un jāmeklē kur tad šis atrodas. Tad nu es pēc savas iniciatīvas izveidoju Tabulu iekš MySQL un ar PHP formu ģeneratoru uzģenerēju interfeisu. Sakarā ar šo es iegādājos vienu grāmatu par datubāžu izveidi un sāku lasīt un interesēties par šo tematu vairāk. Rezultātā sapratu, ka visu datu glabāšana viena tabulā pie laba gala nenovedīs agri vai vēlu. Lūdzu palīdzību laba datubāzes modeļa izstrādē, jo gribu, lai arī pēc gadiem 2 vai 3 datubāze pildītu savas funkcijas labi un ar laiku viņai varētu piesaistīt jaunas funkcijas. Es pielikumā pievienošu tabulu lauku attēlu, lai būtu nojausma kādas tabulas ir un kādi laikumi tabulās. Ir trīs galvenās tabulas: •Klients •Produkts •Spiede Process: Tiek ievadīts jauns klients datubāzē --> Tiek pievienots jauns produkts --> Tiek pasūtīta jauna spiede priekš produkta Iespējamās kombinācijas starp klientu, produktu un spiedi: 1. Vienam klientam var būt divi produkti kriem ir viena un tā pati spiede (pilnīgi vienādas kastes pēc izmēriem un formas, tikai dizains cits) 2. Var būt tā kad ir divi klienti, divi dažādi produkti pēc dizaina, bet viena spiede abiem produktiem, jo pēc izmēriem un formas produkti ir vienādi. Tātad spiedi izmanto vienu un to pašu 3.Var būt viens klients, kuram ir divi produkti un katram no viņiem ir pilnīgi dažādas spiedes Vienam klientam var būt piesaistīts neviens produkts vai ntie Viens produkts var būs piesaistīts tikai vienam klientam Vienam produktam var būt piesaistīta tikai viena spiede Vienai spiedei var būt piesaistīts 1 vai ntie produkti Nākotnē varbūt radīsies nepieciešamība šajā DB iepīt funkciju kā pasūtījumu izveidošana vai ko tādu, bet pagaidām aktuāli ir tas ko es esmu uzrakstījis!! Būtu ļoti jauki, ka spožie prāti pakonsultētu ka vislabāk izveidot, jo domāju ka saknē šī DB ir ļoti elementāra. Gribās vienkārši, lai ir labs pamats jau sākumā. Kas trūkst. Kādi lauki. Kā pareizi sasaistīt tabulas utt! Ar sarkasmu pārpilniem lūdzu netērēt viņu dārgo laiku rakstot šeit stulbus komentārus. Ir vienk nepieciešamība pēc supporta un konsultācijas! :) "Spicās" domas var paturēt pie sevis! Paldies!! :) kombinacijas_starp_kl_pr_spied.pdf Quote Link to comment Share on other sites More sharing options...
Grey_Wolf Posted September 1, 2010 Report Share Posted September 1, 2010 Viens no peedeja laikaa saturiigakajiem jautajumiem :) Idejiski nepareiza pieeja :( Ir trīs galvenās tabulas: •Klients •Produkts •Spiede JO: paraizek buutu sakt ar UNIKALO vertiibu kas buutu spiede taatad.. 1. Spiede 2. Klients 3.Pasuutijums --- Kaapec taa shet neiztirzashu ... bet ja jautajumi raksti tepat PM P.S. un nu jaa , zem klienta vel var papildus tabulas ... Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 1, 2010 Author Report Share Posted September 1, 2010 OK! :) Paldies, par norādēm! ;) Rītdien labprāt pakonsultēšos par šo jautājumu un padiskutēšu, lai izveidotu labu pamatu datubāzei. Kādu dienu pēc gada vai vairāk, ja kāds izdomās veidot nopietnu DB, lai vismaz dati ir saknē jau kvalitatīvi un šobrīd mēs varētu operatīvi atrast spiedes plaiktos un kuram produktam utt. Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted September 1, 2010 Report Share Posted September 1, 2010 (edited) Es reiz sāku rakstīt par datu modelēšanu, tiesa gan pārāk tālu netiku. Bet gan rakstā, gan komentāros ir papildus saites, tai skaitā uz saitu, kurā ir kāds bariņš ar modeļiem. neteikšu, ka man tie visi patīk, bet kaut kādas idejas iespējams var paņemt. >Kas trūkst. Kādi lauki. Nu laukus aka atribūtus jau nu gan neviens Tavā vietā neizdomās. Nu piemēram klientam varētu interesēt banka, bankas konta nr, uzņēmuma reģistra numurs, juridiskā adrese, lai varētu izdrukāt automātisku rēķinu vai vismaz tā veidlapu. Visas tādas lietas ir ļoti atkarīgas no tā, ko Jūs darat un ko Jums vajag. >Kā pareizi sasaistīt tabulas utt! Šim mērķim izmanto ārējās atslēgas (foreign key) kolonas, kurās liek saistītās tabulas primāro vai unikālo atslēgu, ko Tu jau esi savās tabulās iezīmējis, kā id kolonas. Tātad, ja vienam klientam var būt 0 līdz N produkti, bet katram produktam ir tieši viens klients, kas to ir pasūtījis, tad acīmredzot produktu tabulā ir kolona klienta id, kas norāda, kurš klients šo produktu ir pasūtījis. Skatoties uz Tavu apgalvojumu, ka vienam produktam var būt tikai viena spiede, man gan tas liekas mazliet šaubīgs - a kas notiek tad, ja spiede saiet dēlī un jāiegādājas jauna? Vai tā nemaz nevar būt? Iespējams, ka mans jautājums ir muļķīgs bet domājot par attiecībām starp objektiem šīs lietas vienmēr jāņem vērā. Pie tam vai nav tā, ka cits klients var pasūtīt precīzi tādu pašu produktu, kā iepriekšējais un jūs varat izmantot veco spiedi? Kas notiek tad, ja kāds klients pēc laika grib atkal to pašu, ko jau reiz pasūtīja, vai tas ir jauns produkts? Vai jūs interesē produkta pasūtījumi un to izpilde? Tiesa gan, protams, pārāk tālu detaļās arī nevajag ieslīgt, ir jau sākumā jānosprauž robežas, kas būs, kas nebūs, lai varētu saprātīgā laikā nonākt pie kaut kā derīga. Bet nu jā - jautājums par kvalitatīviem datiem - esmu tiešām patīkami pārsteigts :) Gints Plivna http://datubazes.wordpress.com Edited September 1, 2010 by Gints Plivna Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 2, 2010 Author Report Share Posted September 2, 2010 Es reiz sāku rakstīt par datu modelēšanu, tiesa gan pārāk tālu netiku. Bet gan rakstā, gan komentāros ir papildus saites, tai skaitā uz saitu, kurā ir kāds bariņš ar modeļiem. neteikšu, ka man tie visi patīk, bet kaut kādas idejas iespējams var paņemt Labi!! Šo es papētīšu!! :) Nu laukus aka atribūtus jau nu gan neviens Tavā vietā neizdomās. Nu piemēram klientam varētu interesēt banka, bankas konta nr, uzņēmuma reģistra numurs, juridiskā adrese, lai varētu izdrukāt automātisku rēķinu vai vismaz tā veidlapu. Visas tādas lietas ir ļoti atkarīgas no tā, ko Jūs darat un ko Jums vajag. Pagaidām mēs tiešām gribam tikai vākt pamat datus. Jo kādēļ to DB veidoju..., lai būtu vieglāk atrast pašas spiedes, bet tad ienāca prātā doma, ka kaut kādu pamatinformāciju par klientu varētu vākt un arī pamatinformāciju par produktu, lai menedžerim izveidojot pasūtījumu (ko viņš dara aizpildot word dokumentā formu) būtu iespējams pārbaudīt vai spiede ir kārtībā vai nevajag pasūtīt jaunu, paskatīties kāds dizains ir produktam utt. Nu tāda pamatinformācija par šīm trim lietām... Klients, produkts, spiede! Un tieši tādēļ es izvēršu šo diskusiju šeit, lai uz priekšdienām, kad kāds izdomās izveidot mega bāzi, tad šīs tabulas un dati būtu noderīgi. Lai šim DB modelim varētu pievienot jaunas tabulas un veiksmīgi ar viņām darboties! :) >Kā pareizi sasaistīt tabulas utt! Šim mērķim izmanto ārējās atslēgas (foreign key) kolonas, kurās liek saistītās tabulas primāro vai unikālo atslēgu, ko Tu jau esi savās tabulās iezīmējis, kā id kolonas. Tātad, ja vienam klientam var būt 0 līdz N produkti, bet katram produktam ir tieši viens klients, kas to ir pasūtījis, tad acīmredzot produktu tabulā ir kolona klienta id, kas norāda, kurš klients šo produktu ir pasūtījis. OK. Es mēģināšu pārveidot ar tām foreign key nedaudz pielabot situāciju, bet man nav īsti skaidrs kā noteikt kas ir pirmā tabula ar kuru sākt un kurai piesaistīts pārējās tabulas, lai nākotnē arī jaunas opcijas varētu veiksmīgi piekabināt. Kā jau minēju, tad šobrīd ir tā ka process norit šādi: Klients-->Produkts-->Spiede Bet kā man norādīja Grey_Wolf: paraizek buutu sakt ar UNIKALO vertiibu kas buutu spiedetaatad.. 1. Spiede 2. Klients 3.Pasuutijums Varbūt tomēr varētu šeit nedaudz apstāstīt kādēļ tā, jo citiem jaunajiem arī būtu noderīga informācija :) Skatoties uz Tavu apgalvojumu, ka vienam produktam var būt tikai viena spiede, man gan tas liekas mazliet šaubīgs - a kas notiek tad, ja spiede saiet dēlī un jāiegādājas jauna? Vai tā nemaz nevar būt? Iespējams, ka mans jautājums ir muļķīgs bet domājot par attiecībām starp objektiem šīs lietas vienmēr jāņem vērTiesa gan, protams, pārāk tālu detaļās arī nevajag ieslīgt, ir jau sākumā jānosprauž robežas, kas būs, kas nebūs, lai varētu saprātīgā laikā nonākt pie kaut kā derīga. --> "vienam produktam var būt tikai viena spiede" Jā! Vienam produktam var būt viena un tikai viena spiede! :) Ja spiede saiet dēlī, tad: ->Ja iespējams, salabojam paši nomainot bojāto nazi ->Ja nav iespējams salabot, tad sūtam jaunu un veco matam ārā. Jaunajai spiedei ir pilnīgi tāds pats numurs kā vecajai. Man vienā reizē bija tā, ka es vienu dienu nočakarējos uzstādot vienu spiedi un izrādijās, ka blakus stāvēja pilnīgi jauna un to uzstādīt aizņēma 1h. Takā, ka ir divas spiedes, tad jau lažu ir nolaidis "Die cutters" kurš nav izmetis veco. Pie tam vai nav tā, ka cits klients var pasūtīt precīzi tādu pašu produktu, kā iepriekšējais un jūs varat izmantot veco spiedi? Precīzi tādu pašu nepasūtīs, jo mēs ražojam iepakojumus un dizainiski nebūs tāds pats produkts, BET var būt tāda paša izmēra un tipa produkts. Tad protams mēs izmantojam vienu spiedi vairākiem produktiem, bet ne veco, jo vecā ir nelietojusies ... naži neasi vai sabojāti utt. Viņa vairs negriež papīru. Kas notiek tad, ja kāds klients pēc laika grib atkal to pašu, ko jau reiz pasūtīja, vai tas ir jauns produkts? Tad tas nav jauns produkts. Tas jau ir esošs produkts. Menedžeris nočeko datubāzē vai ar spiedi viss ir ok. Datubāzē var paskatīties dizaina failus un skices un ja ir kaut kādi jautājumi klientam, tad datubāzē glabājās pamatinformācija par klientu, lai operatīvi viņu sazvanītu. ā. Vai jūs interesē produkta pasūtījumi un to izpilde? Protams, bet ne tagad! Un tieši tādēļ es gribu, lai pati datubāze ir ok izveidota, lai pēc kāda laika X, tad būs iespējas veidot kaut ko nopietnāku, tad var izmantot jau esošās pamatus utt.Paredzot, ka nākotnē varēs glabāt klienta bankas info, pasūtījumus utt. Lai viss ir vienkopus. Arī informāciju par to cik daudz papīra ir noliktavā. Lai veidojot pasūtījumu norāda cik daudz papīra aizies un jau saprast vai vajag pasūtīt vēl utt. Bet tas nākotnei! :) Pagaidām vienk., lai operatīvi varētu atrast kur atrodas spiede. Jo piemēram ja reizēm lai atrastu vienu spiedi tas aizņem 10 min tad ja dienā ir piem jāsagriež vismaz 6 produkti, tad 1h vienk dienā pakāsta meklējot starp 15 A4 lapām kurās ir kādas 6 tabulas. Izej cauri 1x un neatrodi un tad lēnāk atkal meklē utt :) vienk laika zaudēšana. Tādēļ es vēlos ar jūsu palīdzību izveidot labu pamatiņu un ar kādu PHP ģeneratoru formas izveidot un sākt jau vadīt datus :) Ceru uz suportu :) Daudz vēl jālasa man, lai kaut nedaudz būtu skaidrība par to visu :D Neliels ieskats par kādām spiedēm runāju :) Šajā aparātā viņas liek. Un pielikumā ir fails kur redzama ir pati spiede. Ar sarkano kvadrātu esmu apvilcis to vietu kur var redzēt spiedes numuru, kas ir unikāls. Quote Link to comment Share on other sites More sharing options...
Grey_Wolf Posted September 2, 2010 Report Share Posted September 2, 2010 Kaa jau mineju ja spiede ir UNIKALA tad Es njemtu to ka pamat atskaites punktu Spiede: id | numurs | te vinjas apraksts produkts: id| kada spiede izmantota spiedes_id | Kuram klientam pieder klienta_id | produkta apraksts ... Klients: id| klienta_nosaukums |(jo parasti vienam klientam vr buut tikai viens nosaukums ) ... tad varesi dabuut jebkadus datus, arii tad ja vienu spiedi izmanto vairaki klienti, vai arii vienam klientam ir vairaki produkti Quote Link to comment Share on other sites More sharing options...
codez Posted September 2, 2010 Report Share Posted September 2, 2010 clients ------- id citi_dati products -------- id client_id press_id citi_dati presses -------- id citi_dati kaut kā šādi. Ja vajag dabūt klienta produktus, tad SELECT * FROM products WHERE client_id=123; Ja vajag dabūt kāda produkta presi, tad SELECT * FROM products p,presses p2 WHERE p.press_id=p2.id and p.id=345; Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 2, 2010 Author Report Share Posted September 2, 2010 clients ------- id citi_dati products -------- id client_id press_id citi_dati presses -------- id citi_dati kaut kā šādi. Ja vajag dabūt klienta produktus, tad SELECT * FROM products WHERE client_id=123; Ja vajag dabūt kāda produkta presi, tad SELECT * FROM products p,presses p2 WHERE p.press_id=p2.id and p.id=345; No tavas secības es sapratu, ka tu atbalsti to ka tabulas sasaistītas: Klients-->Produkts-->Spiede Vai tu vienkārši tā uzrakstīji jo es biju tādu secību izvēlējies?? :) Es vienkārši gribu saprasti kādu secību man vajag!! Grey_Wolf Vari lūdzu nedaudz sīkāk aprakstīt kā nākotnē varētu tas ietekmēt, ja es izvēlos kā pirmo spiedi un kā, ja es izvēlos kā pirmo klientu!! :) Quote Link to comment Share on other sites More sharing options...
codez Posted September 2, 2010 Report Share Posted September 2, 2010 (edited) Es vispār nesaprotu par kādu secību jūs tur ar Grey_Wolf runājat, jo sql datubāžu tabulām nav nekādas tabulu secības. Es piedāvāju izveidot 2 neatkarīgas tabulas: clients un presses, un tabulu products, kura norāda gan uz clients, gan uz presses. Tas ir vienalga, vai tu pirmo pievieno tabulā spiedi vai klientu, un tad, kad abi ir pievienoti, tad var pievienot produktu, kurš norāda uz attiecīgo klientu un attiecīgo spiedi. Bet pat šijā gadījumā nav strikta secība, jo tu vari pievienot klientu un tad pievienot produktu, norādot press_id=0, kas nozīmēs, ka prese vēl produktam nav piesaistīta un to būs jāizdara vēlāk. Edited September 2, 2010 by codez Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 2, 2010 Author Report Share Posted September 2, 2010 (edited) Es vispār nesaprotu par kādu secību jūs tur ar Grey_Wolf runājat, jo sql datubāžu tabulām nav nekādas tabulu secības. Es piedāvāju izveidot 2 neatkarīgas tabulas: clients un presses, un tabulu products, kura norāda gan uz clients, gan uz presses. Tas ir vienalga, vai tu pirmo pievieno tabulā spiedi vai klientu, un tad, kad abi ir pievienoti, tad var pievienot produktu, kurš norāda uz attiecīgo klientu un attiecīgo spiedi. Bet pat šijā gadījumā nav strikta secība, jo tu vari pievienot klientu un tad pievienot produktu, norādot press_id=0, kas nozīmēs, ka prese vēl produktam nav piesaistīta un to būs jāizdara vēlāk. OK! Kādēļ divas tabulas nevis 3?? Jo katra no trim klāsēm jau man saturēs objektus. Cik nu es esmu palasījies, tad es saprotu, ka vajag trīs tabulas manā situācijā. Un attiecībā uz sasaiti. Klients var būt datubāzē bez produkta un produkts var būt bez spiedes, bet spiede bez produkta nevar būt. Ja spiede ir viena pati, tad mēs viņu metam ārā. Lai neizveidojas arī situācija, kad piemēram spiede "karājās" db viena pati un atrodi nu kuram produktam viņa ir piesaistīta. Pagaidām bez sazīmētām relācijām pielaboju tās tabulas. Vai šāda tabulas ar šādiem laukiem būtu ok? ... pievienoju attēlu pa jaunam, jo biju aizmirsis vienu laiku!! :) Edited September 2, 2010 by bluebird Quote Link to comment Share on other sites More sharing options...
codez Posted September 2, 2010 Report Share Posted September 2, 2010 (edited) manā varaintā 2 tabulas ir neatkarīgas, trešā saistīta ar abām. Kopā 3. Tavā pēdējā grafika gadījumā, ja tu norādi klientam product_id, tas nozīmē, ka klientam varēs būt tikai viens produkts, tāpēc labāk ir produktam norādīt clienta id, tāda'veidā piesaistot produktu pie klienta. Savukārt, ja spiedei norādi product_id, tad katrai spiedei varēs būt viens produkts, bet tu raksti, ka vajag: Vienai spiedei var būt piesaistīts 1 vai ntie produkti Tāpēc vajag produktam norādīt press_id, tādā veidā viens produkts ir piesaistīts konkrētais spiedei un spiedei var būt piesaistīti daudzi produkti. Edited September 2, 2010 by codez Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted September 2, 2010 Report Share Posted September 2, 2010 iekš produkts client_id vai client product_id - viens no tiem ir lieks. Derētu arī tev pašam vismaz sazīmēt, kuri lauki būs obligāti, kuri nē Tad iespējams par to vietu der padomāt, vai tas nav kā klasifikators (ierobežota vērtību kopa), lai viens neraksta augšējais plaukts, otrs trešais plaukts no apakšas un trešais pirmais no augšas. Tad vēl sīkums, protams, bet nestilīgi, ka tiek jauktas valodas. Vai nu visu latviski, vai angliski Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 2, 2010 Author Report Share Posted September 2, 2010 manā varaintā 2 tabulas ir neatkarīgas, trešā saistīta ar abām. Kopā 3. Tavā pēdējā grafika gadījumā, ja tu norādi klientam product_id, tas nozīmē, ka klientam varēs būt tikai viens produkts, tāpēc labāk ir produktam norādīt clienta id, tāda'veidā piesaistot produktu pie klienta. Savukārt, ja spiedei norādi product_id, tad katrai spiedei varēs būt viens produkts, bet tu raksti, ka vajag: Tāpēc vajag produktam norādīt press_id, tādā veidā viens produkts ir piesaistīts konkrētais spiedei un spiedei var būt piesaistīti daudzi produkti. Cool :) Ineresanti, kad palasa kaut ko un reāli ķeras pie prakses .. :) tad viss izskatās pavisam savādāk :) Sapratu reālo problēmu ar manu pirmo variantu. Vai tu atbalsti šādu modeli, kādu pievienoju tagad pielikumā? + ieboldēju tos laukumus kuri ir nepieciešami. Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 2, 2010 Author Report Share Posted September 2, 2010 + kaut kas minēja, ka klienta nosaukumu izmantot kā ID. Neesmu eksperts, bet vai tas nevarētu radīt problēmas, ja pie klienta ievadīšanas tiks norādīts nepareizs nosaukums, tad pēc tam būs grūti atrast viņu? Un tas pats par pašu spiedi. No vienas puses viņas numurs, kas tiek iededzināts uz viņas ir unikāls!! Bet viņu tomēr ievada ar roku!! Ja nu piemēram pārskatās un 6 vietā ievada 8. Tad pēc reālā cipara viņu neatradīs! Tādēļ man šķiet ka ID šajā DB labāk ir ģenerēt automātiski. Quote Link to comment Share on other sites More sharing options...
bluebird Posted September 2, 2010 Author Report Share Posted September 2, 2010 Tad iespējams par to vietu der padomāt, vai tas nav kā klasifikators (ierobežota vērtību kopa), lai viens neraksta augšējais plaukts, otrs trešais plaukts no apakšas un trešais pirmais no augšas. Jā! Par to novietošanu plauktos ir tā. Sadalīti ir A, B, C, D ... Un tad spiedei tiek piešķirta vieta: A1, C12, E23... un Burts norāda plauktu, bet skaitlis kura spiede pēc kārtas. Un uz sāniem arī viņai parasti ir uzrakstīts piem A5. Tad pieejot pie plaukta uzreiz redzu kura ir A5. Tad vēl sīkums, protams, bet nestilīgi, ka tiek jauktas valodas. Vai nu visu latviski, vai angliski Tas jā :) Viss būs vienā valodā! Es vienk tagad tā pielabojot, ierakstu tad tā, tad tā :) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.