Lep pozdrav,
sem bolj začetnik, pa bi vas vprašal za en nasvet.
Izdelujem aplikacijo, in ne vem kako bi prišel do hitrejših seekov po bazi.
Imam dve možnosti.
Imeti cca 40 stolpcev, podatkovnega tipa npr. nchar v njih pa bi bil zapis denimo 4;7;9 (to pomeni, katera polja so true). Select stavki bi tako imeli kar nekaj pogojev WHERE npr. '3' LIKE '3;4;5' OR 5 LIKE '3;4;5' itd
Ali imeti cca 200 stolpcev v eni tabeli tipa boolean in izvajati SELECT stavke v stilu WHERE polje13 =TRUE or polje 15=TRUE itd...
Se komu sanja, kaj bi bilo hitreje in zasedlo manj rama. Kakor vem so iskanja LIKE kar sistemsko zahtevna.. Je 200 stolpcev veliko?
Lepa hvala, Grega
Avtor: skuta, objavljeno na portalu SloDug.si (Arhiv)
skuta - torek, 30. januar 2007
bojanv: bil sem, bil...brazilke sicer ni blo, sem bil pa v družbi g. Zupančiča in g. Vidmarja....Tip v rjavi usnjeni jakni...... No, mogoče pa naslednjič... Jaz sem imel temno moder hribovski flis ( tisti fant, ki je bil brez dveh dolgonogih Ukrajink poleg). Pa tud jaz sem 1X Zupančiča nekaj prišel vprašat...(hvala za odgovore)
MihaM - petek, 26. januar 2007
Da ne bomo smetili po pristni programerski debati, sem prenesel idejo semle:http://www.codezone-si.info/forums/thread/1954.aspx
spirit1 - petek, 26. januar 2007
jst sm tut za. vendar pod pogojem da je ta stran vidna samo registriranim uporabnikom.
bojanv - petek, 26. januar 2007
Jz sm takoj za. Čeprav malce pokvari ravno anonimnost, samo je pa dobr, k veš s kom se pogovarjaš. Še posebej, ko se s človekom pišeš, je boljši občutek.
MihaM - petek, 26. januar 2007
Priznam, meni se tudi včasih zgodi, da koga ne poznam (pa če sem ga že videl ali ne).Dokaj enostavna rešitev bi bila, da bi nosili kake priponke z imeni. Malo bolj geek rešitev pa bi bila s kakšnimi RFID čipi.Poleg tega bi tle na spletu lahko naredili imenik članov in zraven bi vsak dal svojo sliko.Kaj pravite?
bojanv - petek, 26. januar 2007
bil sem, bil...brazilke sicer ni blo, sem bil pa v družbi g. Zupančiča in g. Vidmarja....Tip v rjavi usnjeni jakni......
spirit1 - petek, 26. januar 2007
brazilk ni blo ker mene ni blo
skuta - petek, 26. januar 2007
Sorry, včeraj te nisem spoznal...Pa tudi kake brazilke ni bilo. :(
bojanv - sreda, 24. januar 2007
Zakaj pa se ne bi? Lahko bi našel žensko svojih sanj kje v Braziliji...
spirit1 - sreda, 24. januar 2007
skuta:Aha, zgoraj lahko kliknes Search, in potem spodaj levo Keep Customizing... No, to je ta obrazec, ki se potem zarola po gotovo miljonu zapisov v njihovem primeru...Ja sem sel pogledat ampak na uvodni strani me da samo Start looking in potem me redirecta naprej in mi pove da se morm registrirat... to pa ne bom! iz principa!
bojanv - sreda, 24. januar 2007
spirit1: well done little grasshoper! sam zanimal me je kaj bos reku
skuta - sreda, 24. januar 2007
Aha, zgoraj lahko kliknes Search, in potem spodaj levo Keep Customizing... No, to je ta obrazec, ki se potem zarola po gotovo miljonu zapisov v njihovem primeru...
skuta - sreda, 24. januar 2007
:) DogajaJa, mogoče sem mal pretrdo rekel... vse ali čimveč elementov mora klapat v aplikaciji, sam zdi se mi, da je fajn izhajat iz najbolj zahtevnega dela programa, pa gradit okol tega navzgor. User experience pa to, so tko samoumevno nujni in brez njih ne gre. Okna, miška... so najbl prepoznavni elementi modernga računalnika, kaj je pod pokrovom pa ljudje ne vedo.XML - pošta je interna, nobenega protokola. Zamislil sem si, da bi tako interno pošto parsal iz enega xml dokumenta na uporabnika. Ker lahko narediš ala <vsaPostaMojegaUserja><enoPismoUserja />.........</vsaPostaMojegaUserja> in izgleda enostavna resitev. Nekaj drugega kot resnicna posta je to - neke vrste interna zadeva , no.Jaz sem mislil bolj zmenkarske programe kot pa mySpace (uf, kake stevilke), btw tole o mySPace bo za prebrat. Tulele .
spirit1 - sreda, 24. januar 2007
well done little grasshoper! sam zanimal me je kaj bos reku
bojanv - sreda, 24. januar 2007
Veliko problemov te tudi čaka, če zgrešiš design aplikacije ( ne govorim o šminki ). Zato je najboljše, če eno zlije z drugim.....Se pa ne strinjam z trditvijo, da je baza najbolj pomemben del aplikacije. Je sicer eden izmed ključnih. Baza sama uporabniku ne koristi nič, če nima nekaj pred sabo, kar lahko vidi in uporabi. Ne me narobe razumet, mislim, da je baza odlična shramba podatkov in je enostavno delat z njo (kvečjemu je to en file)....so pa tudi druge alternative (kot npr. navaden file,...). Ne trdim tudi, da je design najbolj pomemben del, ampak da je tudi eden izmed ključnih. Oboje more delat optimalno, enostavno in ( v upanju ) brez kakšnih večjih problemov. Tako je volk sit ter koza cela....
spirit1 - torek, 23. januar 2007
ti kar sprasuj ce slucajno govoris o myspace-u:http://www.baselinemag.com/article2/0,1540,2082921,00.asps to bazo mora bit izjemno zanimivo delat... ce gredo podatki tam do 5 terabajtov... ufff...pri vsakem database driven projektu je baza najbolj pomemben del celotne aplikacije.Lahko sminkas UI kolikor hoces vendar ce zgresis dizajn baze te caka ogromno problemov v prihodnosti xml za posto? kako pa posiljas? prek smtp-ja? full text je pa cisto druga stvar in pa tudi on ne podpira iskanja po bit poljih
skuta - torek, 23. januar 2007
Tako je, Pril -tvoj search bi bil primeren, če imaš pravico nasloviti samo eno lastnost na vprašanje, npr išči osebo, ki ima višje šolsko izobrazbo. Potem bi bili taki searchi verjetno res ultra hitri. Čim pa imaš kombinacijo večih dovoljenih stanj (lanho ima ali VŠ, ali SŠ, ali PhD;)) je treba delat bitwise...Tako, jaz ne bom več spraševal, ker se mi zdi, da ste mi že ohromno pomagali. Hkrati z zanimanjem ugotavljam, da je aplikacija, ki sem se je lotil skoraj primarno SQL značaja (poznavanja strežnika, t-sql...). Torej mi ne uide ful branje tovrstnih knjig. Najprej sem mislil, da bojo najbolj važni lep narejeni objekti... itd. Pa še XML za pošto bo prišel v poštev. Hvala bogu SQL 2005 za XML podporo. Če koga ravno iz firbca zanima, najbolj obiskano tovrstno spletno mesto na svetu je narejeno na ASP.NET-u. In vsebuje iskanje po keywordih , torej full text search, ki išče po opisnih delih portretov (osebnih esejih). Hmm, le kako to : )
spirit1 - torek, 23. januar 2007
problem z varchari je ta da ne mores delati bitwise operacij na njih.torej tvoja metoda dela samo za tocno ujemajoce se podatke in ne za katerokoli kombincijo le teh.zatorej je tvoj nacin neuporaben za tukajsnjo zahtevo.ce se slucajno motim me razsvetli
pril - torek, 23. januar 2007
Tudi jaz ne :-) si pa mislim: ker fulltextsearch išče po indeksiranih podatkih verjetno veljajo ista pravila...torej najde hitro npr. določen string, ker pa je veliko teksta več časa porabi za samo indeksiranje.Tudi sam sem pristaš relacijskih baz, pri 200 strolpcih pa bi administriral raje programsko kot ročno...lp, pl EDIT: ups, spregledal sem zgornje poste: ja, sam bi se tvojega problema lotil drugače. Iz mojih izkušenj: z biti imam zapisano npr pravice, ki so v memoriji dela hitro , v bazi pa bi si privoščil malo potratno, zato pa za upravljanje enostavnejše: način zapisa bi bil kar 100010101001 v polju tipa string (s tem nimaš samo možnosti tru, false ampak tudi npr nedoločeno, ali pa še kaj, praktično 256 vrst tipov npr: 100AZ01 ipd). Zelo enostavno je tudi iskanje in predvsem zelo zelo hitro, ker to že sql server zelo efektivno indexira kratke stringe. 1 mio zapisov ni problem... Za vsako novo kategorijo samo dodaš en znak, 8k jih je na voljo... P.S. Tudi pri filtriranju podatkov v dataset-u v asp-ju uzporablja metode ki iščejo po indeksiranih podatkih, ne delati filtrov kar tako....
spirit1 - ponedeljek, 22. januar 2007
aja da ne pozabim. sem probal tisto z 50 tisoc zapisi na moji masini in je search trajal cca 300 ms pri normalni porazdelitvi podatkov.
spirit1 - ponedeljek, 22. januar 2007
no mene zal ne bo... tak da naslednjic...
bojanv - ponedeljek, 22. januar 2007
Seveda bomo tam...za pivo nas pa poišči..jz ne vem, kako izgledaš....domnevam pa da moja slika ni tko slabe kvalitete, da me ne boš našel....
skuta - ponedeljek, 22. januar 2007
Ne bodo bit columni, integer ali varbinary... z update-i je tako, da bom mogoce tvegal bolj zahtevno dodajanje nove kategorije.Lepo se mejtePS, ce boste na Slodugu v cet, castim pivo če čte :)
spirit1 - ponedeljek, 22. januar 2007
ja je bitwise and. malce sem se zatipku.ja lahko mas tudi tak where. problem s tem je da ce dodas novo kategorijo mors pol stored proceduro popravljat medtem, ko ce mas computed column ne rabis.in pa ce bos imel samo bit columne ti indexiranje le teh ne bo prineslo nic dobrega.lahko probas narest covered index cez vse bit stolpce ampak potem moras vedno uporabiti prvi stolpec v indexu da se lahko index sploh uporabi.osebno mi je computed column najbolj cista in simpl zadeva
skuta - ponedeljek, 22. januar 2007
spirit ful hvala, pa tudi ostali, zelo lepa hvala za pomoč. bitwise AND & je točno tisto, kar nisem vedel... SAJ JE BITWISE AND?Razmišljam, da bi vseeno malo drugače naredil - brez computed column, namreč v tabelo bi v stolpce vstavljal preračunane desetiške vrednosti binarne oblike profila in kasneje v SELECT stavku imel querryje podobne. WHERE id>0 AND (( columnProperty1INT & @columnProperty1INT)>0) AND ((columnProperty2INT & @columnProperty2INT)>0) AND ((columnProperty3INT & @columnProperty3INT)>0) AND ((columnProperty4INT & @columnProperty4INT)>0) AND ((columnProperty5INT & @columnProperty5INT)>0) .... še vedno bo teh polj cca 34 v najslabšem primeru.Mogoče pa ni treba primerjat ali je večje od nič, ampak true ali false? tudi še nisem preizkusil.Ves vprašalnik se deli na recimo 6 kategorij. Vsaka kategorija ima cca 5-6 vprašanj. Vprašanje pa ima lahko tudi 20 opcij.še vedno bo teh polj cca 34 v najslabšem primeru. Minimalno mora search zdržati real time pri 50.000-100.000 zapisih v bazi. Lahko pa tudi več. Parametre bi zopet zgradil iz obkljukanih <asp:CheckBoxList /> -ov kar s string builderjem(kjer ni kljukica APPEND "0", kjer je pa APPEND "1") in pretvorba v desetiški zapis, ali hex kot predlaga spirit (mogoče je hitreje - za procesor lažje)... Vse skupaj moram še premislit.Mega spirit, res.@bojanv, hvala tudi tebi. Profilov sem se že prej lotil podobno, kot si predlagal, le manj elegantno. Pač vsaka kategorija ima svoj class in ta class nudi svoj interface...
spirit1 - sobota, 20. januar 2007
bojan ima vsekakor prav. (tole bo en pir bojc )za pravilen design je treba poznat tvoj cilj. se pravi koliko zapisov (oseb) v tabeli mislis imeti? 10.00, 10.000, 100.000.000?kaksen bo tvoj razvojni model za naprej, ali se bodo novi atributi dodajali pogosto ali samo ob vecjih updateih itd.imas pravzaprav 2 moznosti:1. EAV model (ce uporabljas sql server 2005 lahko zelo elegantno resis to z XML datatypeom. poglej si tale moj post http://weblogs.sqlteam.com/mladenp/archive/2006/10/14/14032.aspx) 2. Vsaka kategorija naj ima svojo tabelo. Torej tabele: sport, zabava, umetnost, .... itd. Sedaj je tukaj par trikov ki jih lahko uporabis. Bitna polja so kompletno neustrezna za indeksiranje zaradi majhne selektivnosti (priblizno enaka porazdelitev) vrednosti. Tvoja OR iskanja pa kompletno rasujejo index kakrsne koli index seeke.zato bi moral razbiti vse OR-e na "union" select stavke kar pa spet pomeni n "union"-ov az n iskanj.Osebno bi naredil sledece:razbij glavno tabelo na vec tabel. 1 tabela na kategorijo. vsaka tablea naj ima not identity(1,1) na katerega daj Clustered index gorna FK do userja daj Non clustered index gor.naredi computed column tipa bigint v katerega shranis hex zapis vseh bitnih polj v tabeli. ta column mora biti persisted:create table bitCategory ( id int identity(1, 1) primary key, -- tole doda CI avtomatsko. ce noces da je ga dodaj sam z create index val1 bit, val2 bit, val3 bit, val4 bit, val5 bit, val6 bit, val7 bit, val8 bit, val9 bit, val10 bit, computed as ( val1*power(convert(bigint, 2), 36) + val2*power(convert(bigint, 2), 32) + val3*power(convert(bigint, 2), 28) + val4*power(convert(bigint, 2), 24) + val5*power(convert(bigint, 2), 20) + val6*power(convert(bigint, 2), 16) + val7*power(convert(bigint, 2), 12) + val8*power(convert(bigint, 2), 8) + val9*power(convert(bigint, 2), 4) + val10*power(convert(bigint, 2), 0)) PERSISTED ) create index NCI_bitCategory_computed on bitCategory(computed) Tvoji searchi se potem ne bodo vec OR-ali ker bos iskal po computed columnu.declare @search varbinary(20) select @search = 0x0000001001 select * from bitCategory where id > 0 and computed & @search > 0 Where id > 0 naredis zato da dobis seek po clustered indexu. Za vse vrstice, ki usetrezajo vsaj enemu tvojemu pogoju (to je pravzaprav OR) bo computed & @search > 0 torej bos dobil nazaj vse vrstice ki ustrezajo kombinaciji tvojemu pogoju. & je bitwise OR. 0x0000001001 je kombinacija tvojih zeljenih iskanj. najbolj desni bit je v mojem primeru val10. to seveda lahko obrnes (najbrz je tudi bolje da ga obrnes) ce hoces dodajati nove stolpce v tabelo jih dodas v tabelo in popravis v computed column expression-u dodas na zacetek nov power() da ti ne bo treba spreminjati vseh obstojecih vrednosti. Na koncu bodo tvoji searchi sami seeki in bodo hitri ko strela. Ce kaj ni jasno pa vprasaj
bojanv - petek, 19. januar 2007
Osebno mislim, da bi se tistih dvesto parametrov dalo zelo lepo razbit. Govorim iz stališča .NET-a (kako bi se jz lotil...na hitrco).V prvem delu lahko določiš osebe, ki imajo skupne karakteristike, recimo, ime, priimek, starost, kraj bivanja, rojstni dan, itd.,. Potem nardiš moškega, žensko, deduješ osebo, nato definiraš grupe karakterjev in lastnosti. Npr. razbiješ osebo na tri dele ali več. Recimo,Torso, Legs, Face ( vse implementirajo recimo nekakšen ICharacteristic, kjer so definirane, kaj se z temi karakteristikami dela). Potem imaš razrede, ki ti poskrbijo za hranjenje le teh. Kasneje pa maš še controle, ki ti to hande-jo.Za bazo sicer nisem večji specialist, lahko ti pa spirit1 (Mladen) bolj svetuje. Jz bi to, kar sem rekel v .NET-u, poskusil preslikat v bazo, torej isto bi imel karakteristike, ki bi jih porazdelil z vmesnimi tabelami po bazi. Torej hierhija PersonID - CharacteristicID. Kasneje pa lahko s pomočjo UNION-om ali kakšnim drugim mehanizmom urejal podatkovno bazo.Mogoče ti bo tole dalo kako idejo. Mogoče je to bolj tema za arhitekturo področje .....
skuta - petek, 19. januar 2007
ASP.NET () aplikacija.Pri medsebojnem iskanju imaš več možnosti searcha - po manj parametrih, mora pa aplikacija imeti tudi zahtevnejši search po skoraj vseh parametrih.Po slovensko bi search izgledal npr. nekako takole: Poišči vse ljudi, ki (radi hodijo v hribe ali radi smučajo ali radi kolesarijo ali radi igrajo tenis) in (poslušajo rock ali poslušajo klasično glasbo) itd, da ne dužim. cca 200 možnih parametrov. Razmišljal sem o kakem algoritmu, ki bi parametre preračunal v kako celo število, ampak se mi ne zdi mogoče...trenutno sem poleg tabele, ki shranjuje profile ljudi sestavil tabele, ki so vnaprejšnji rezultati searchev:da skrajšam število vrstic v iskanju. parametri so pa razdeljeni v skupine (naprimer skupina vprašanj prosti čas, zunanji izgled itd):::Res je, da ne vem še ali obstaja filtriranje dataset-a ali datareader-ja.Upam, da ne težim ;)Nekatere podatke sem zbrisal, ker mislim, da niso bistveni za vprašanje. Oprostite...
spirit1 - petek, 19. januar 2007
dej malo bolj razlozi tale tvoj model in aplikacijo.mam obcutek da si malce zgresil v nacrtovalski fazi.
skuta - petek, 19. januar 2007
Hvala, tole moram kar malo razmislit. Gre za to, da imam objekt z do 200 možnimi true ali false, med seboj neodvisnimi atributi - ti objekti so seveda ljudje.Še posebej hvala za link do wikija...
bojanv - petek, 19. januar 2007
Imeti 200 stolpcev v tabeli se mi zdi preveč, že za samo administracijo in urejanje tega. Tudi 40 je že kr visoka številka. Sem pristaš relacijske podatkovne baze. Magar to porazdeliš po tabelah, narediš med njimi relacije. In če že rabiš toliko stolpcev, narediš nad njimi View-e ali pa z stored procedurami rešiš zadeve. Bo enostavneje in bolj efektivno zate, kot programerja / načrtovalca. Pri perfomansi se pa ne bo to poznalo. SP so znane po tem, da se malce zoptimizirajo, če ne delaš bedarij v njih. Hm, pri podatkovnih bazah je fino, če imaš strežnik kr močen, saj se izvajajo (tudi) kompleksne operacije. Lahko pa za bolj odprto (mislim bolj globje) iskanje uporabiš full text search. Koliko pa to požre pa ne vem prav natančno.