Pats Toms Posted May 25, 2016 Report Share Posted May 25, 2016 Jā, izpildes ātrumu tas ietekmē minimāli, bet DRY gan datubāzēs ir svarīgs, it īpaši, ja ir plānoti 10k+ produkti ar tonnu atribūtu. Bet vai šeit nav pretruna? Tu man piekrīti, ka tas ļoti diez vai ietekmēs izpildes ātrumu, bet pēc tam apgalvo, ka tabulās, kur ir desmitiem tūkstošu ierakstu - DRY ir super svarīgs. Manuprāt, desmitiem un arī simtiem tūkstošiem ierakstu, joprojām nav liela datubāze. Tas, protams, ir atkarīgs no datiem, bet šajā konkrētajā piemērā, tas nav daudz un es to parādīju konkrētajā demo. Quote Link to comment Share on other sites More sharing options...
F3llony Posted May 25, 2016 Report Share Posted May 25, 2016 Divas problēmas. Tev nav priekšstata kas ir vairākums, un Tu nedomā. Industriālo softu. Mongo tur spīd. Hahahahaha. Because fuck data integrity. :D Quote Link to comment Share on other sites More sharing options...
Wuu Posted May 25, 2016 Author Report Share Posted May 25, 2016 (edited) Dzēst, F3llony bloķēts. Neveido diskusiju. Pubertāte un atzinības trūkums, acīmredzams. Nav ko troļus barot. Edited May 25, 2016 by Wuu Quote Link to comment Share on other sites More sharing options...
Val Posted May 25, 2016 Report Share Posted May 25, 2016 Šos tekstus jau nu varēji paturēt pie sevis. Quote Link to comment Share on other sites More sharing options...
F3llony Posted May 25, 2016 Report Share Posted May 25, 2016 Dzēst, F3llony bloķēts. Neveido diskusiju. Pubertāte un atzinības trūkums, acīmredzams. Nav ko troļus barot. Es vēl joprojām neesmu dzirdējis no Tevis nevienu argumentu izņemot "es esmu slinks un man nepatīk shema constraints". Redzēsim, cik industriāls būs Tavs risinājums, kad kādam nabaga frēzes operatoram nozāģēs kāju, jo Mongo nejauši papisīs vienu updeitu un silently nofeilos, tāpēc ka Wuu lai palielinātu ātrumu (kas ir galvenais) noteiktu darbinās visus klientus ar WC:NACK vai minority... Lūdzu, cienītie, tā arī rodas tādas LNB Mongo bāzes, knapi kopā turas, jo šitādi kretīni savu DB izvēli pamato ar teikumu like "uhh ohhh yeyy dokument store un grāmatas taču ir dokumenti, right? There MUST be something!". Quote Link to comment Share on other sites More sharing options...
codez Posted May 25, 2016 Report Share Posted May 25, 2016 Varbūt viss ko tev vajag ir glabāt šos parametrus vienā kolonnā DB saserializētu + vienkārši tos barot kādam search engine, kas ir paredzēts meklēšanai, piemēram, Ellasticsearch? Man kā idejas piekritējam, ka uz datubāzi skatāmies kā uz datu glabātuvi, tieši šis variants nāk galvā kā pirmais, kurš ir diezgan universāls un diezgan ātrdarbīgs. Šis variants ļauj viegli skeiloties, jo no datu bāzes principā atlasīsim tikai pēc id un produktu saraksts jau saturēs visus datus - nebūs jātaisa joini. Savukārt, Elasticsearch meklējumos pēc kompleksiem nosacījumiem krietni pārspēj Mysql. Quote Link to comment Share on other sites More sharing options...
Roze Posted May 25, 2016 Report Share Posted May 25, 2016 Elasticsearch meklējumos pēc kompleksiem nosacījumiem krietni pārspēj Mysql. Ticēt rakstītajam .. Personīgi nācās tikt nedaudz pāri nepatikai pret Javu (bērnības traumas), bet Elastics noteikti ir gan labāka object store (vs Mongo) gan search engine (Lucene v0v), gan replikācijas (automagically shardings/clusterings utt), proti, ja ir vēlme var pilnībā iztikt tikai ar ES (pretēji piem. ja izmanto kādu eksternālu meklēšanas pļurzuli kā Sphinx kuram rezultāti ir tikai dokumentu id). Quote Link to comment Share on other sites More sharing options...
F3llony Posted May 25, 2016 Report Share Posted May 25, 2016 Savukārt, Elasticsearch meklējumos pēc kompleksiem nosacījumiem krietni pārspēj Mysql. This. "If the only tool you know is a hammer, you tend to see every problem as a nail". Quote Link to comment Share on other sites More sharing options...
jurchiks Posted May 25, 2016 Report Share Posted May 25, 2016 kā Sphinx kuram rezultāti ir tikai dokumentu id). Nav gan tikai ID, ir visi dati, kas indeksā definēti. Ja nav definēts neviens lauks, tad, protams, tikai ID vien būs. Bet vai šeit nav pretruna? Tu man piekrīti, ka tas ļoti diez vai ietekmēs izpildes ātrumu, bet pēc tam apgalvo, ka tabulās, kur ir desmitiem tūkstošu ierakstu - DRY ir super svarīgs. Manuprāt, desmitiem un arī simtiem tūkstošiem ierakstu, joprojām nav liela datubāze. Tas, protams, ir atkarīgs no datiem, bet šajā konkrētajā piemērā, tas nav daudz un es to parādīju konkrētajā demo. DRY nav svarīgs ātruma dēļ, bet gan lai datubāzē neveidotos tonna duplicate datu. Kur tu tur saredzi pretrunu? Quote Link to comment Share on other sites More sharing options...
Леший Posted May 25, 2016 Report Share Posted May 25, 2016 DRY nav svarīgs ātruma dēļ, bet gan lai datubāzē neveidotos tonna duplicate datu. Kur tu tur saredzi pretrunu? DRY nav sakara ar duplicate. Uzliec unique indeksus, sakārto ORM vai kas tev ir, un nebūs tev dublikātu. DRY ir tiešais sakars ar ātrumu. Ja tev kāds kods ir atkārtojas, un tu to nerejuzo, tad opitimizējot to vienā vietā, tu vari aizmirst optimizēt citā vietā, un tas ietekmēs ātrumam. Ja ir DRY-ots, tad tātas problēmas nebūs. Quote Link to comment Share on other sites More sharing options...
jurchiks Posted May 25, 2016 Report Share Posted May 25, 2016 Izlasi, lūdzu, visu topiku, tad labāk sapratīsi, par ko es konkrēti runāju. Quote Link to comment Share on other sites More sharing options...
Mr.Key Posted May 25, 2016 Report Share Posted May 25, 2016 (edited) DRY ir kodā, datubāzes struktūrā ir normalizācija. Edited May 25, 2016 by Mr.Key Quote Link to comment Share on other sites More sharing options...
jurchiks Posted May 25, 2016 Report Share Posted May 25, 2016 DRY ir princips. Idejiski to var elementāri attiecināt arī uz datubāzēm. Normalizācija ir krietni vien plašāks jēdziens, kas sevī ietver arī DRY. Quote Link to comment Share on other sites More sharing options...
spainis Posted May 25, 2016 Report Share Posted May 25, 2016 https://twitter.com/sadserver/status/727879508984877056 Quote Link to comment Share on other sites More sharing options...
Wuu Posted May 25, 2016 Author Report Share Posted May 25, 2016 https://twitter.com/sadserver/status/727879508984877056 https://twitter.com/sadserver/status/725466785160404992 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.