Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

mala pomoć oko strukture, kako je najbolje

[es] :: MySQL :: mala pomoć oko strukture, kako je najbolje

[ Pregleda: 2825 | Odgovora: 4 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

dragancesu
subotica

Član broj: 38340
Poruke: 2189
*.dynamic.isp.telekom.rs.



+73 Profil

icon mala pomoć oko strukture, kako je najbolje25.05.2015. u 07:34 - pre 108 meseci
Imam ideju da napravim sistem za upravljanje dokumentima, danas toga ima u svakoj firmi ima mnogo, a ni skeneri nisu retkost, neko je izrazio zelju da bi mu mnogo pomoglo kad bi dokumente skenirao i sad treba napraviti deo za indeksiranje toga. Ako zanemarimo osnovna polja tipa id, datum, vrsta, opis... problem nastaje sa pojmovima koje treba uneti i indeksirati i posle ih pretrazivati. Gledao sam neke sisteme, recimo wordpress ima interesantno resenje, u jedno polje se unose kljucne reci odvojene zarezim pa na na osnovu toga pravi indeksiranje.

Imate li ideju kako organizovati podatke (pojmove, kljucne reci) da se lako nadju, da li u jednom polju, da li u vise, mozda u vise tabela?
Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: mala pomoć oko strukture, kako je najbolje25.05.2015. u 11:15 - pre 108 meseci
ima mnogo nacina da se to resi, trebaju ti polja za metadata, metadatu
definises sam prema svojim potrebama vezano za to kakvi su dokumenti,
metadata se u glavnom rucno unosi (datumi, kategorije, naslov, kljucne
reci), treba ti polje da sacuvas original dokumenta (neki jpg ili pdf
ili png ili u sta si ga skenirao, mozda docx, xls .. sve su to dokumenti
mozda i nisu samo skenirani) i treba ti polje sa tekstualnim sadrzajem
koje se puni automatski nekim ocr-om ili doc2txt ili pdf2txt ili ... e
sad sve zavisi koja kolicina, kakve ce vrste pretrage biti... za
pretragu spremas razne indexe, naravno kroz metadatu, u metadati imas
rucno unesene kljucne reci, ali takodje moras da indexiras i generisani
sadrzaj dokumenta (mozda neces imati to odma ali vec za koji mesec ce se
javiti potreba) .. ja bi licno zaobisao mysql u toj prici ... ima danas
toliko modernijih document storage sistema koji su mnogo bolji fit za
bazu koja ima samo inserte (ti ces tu imati update / delete u promilima)
i koja realno cuva dokumente ..
 
Odgovor na temu

dragancesu
subotica

Član broj: 38340
Poruke: 2189
*.dynamic.isp.telekom.rs.



+73 Profil

icon Re: mala pomoć oko strukture, kako je najbolje25.05.2015. u 11:57 - pre 108 meseci
Sto mi ubi volju za MySql? Sta mu fali? Ne bi dokumente cuvao u bazi nego u folderima kao origilal, a program da zna gde su i da ih pokazuje po potrebi

Ne bi trebalo da je nista toliko ozbiljno, vise da je korisno, tokom vremena dolazi mnogo ulaznih faktura i drugih dokumenata, i ako neke smatra da bi bilo olaksao posao (pratkticno pretrage) oko dokumentacije onda sam raspolozen da to pravim. Skenrati, indeksirati i arhivirati je verovatno jednostavnije nego se posle penjati i traziti po registrima

No, kako svaki projekt pocenje "bice samo dve-tri stvari..." uvek se iskopmplikuje i prosiri

Ako zanemarimo sada da se tekst provuce kroz ocr i ubaci u bazu, ostaju doc, pdf i skenirani dokumenti (iz aplikacije i sa drugih strana)

Gledao sam malo open source resenja i na ekranima za unos nije bilo bas mnogo podataka, ali wordpress ima interesantan nacin indeskiranja stranica, prilikom unosa clanka ima jedno polje za KEYWORDS i tamo se unese tekst "REC1, REC2, REC3, REC4, ..." onda svaku rec indeksira i kljuc smesti u neku tabelu pa je posle lako traziti (mada je to prakticno po jednoj reci), indeks tabela je jednostavna

ID KEYWORD
1 REC1
2 REC2
3 REC3
4 REC4
...

i posle uz clanak u nekoj tableli ubaci gde se koristi neka kljucna rec

clanak id_keyword
516 1
516 2
516 4
520 1
520 2
520 3
...

na naslovno strani su prikazane kljucne reci (ima i broj povaljanja ali nebitno) i kad se klikne na REC2 lako je napraviti SELECT da se to pojavljuje u clancima 516,520,...

Ucinilo mi se interesantno (i jednostavno) samo je pitanje koliko je efikasno, ovo je prakticno priprema i lako je pokazati spisak kljucnih reci, naravno treba ostaviti i "slobodan" unos za pretragu






Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2377 Profil

icon Re: mala pomoć oko strukture, kako je najbolje25.05.2015. u 12:19 - pre 108 meseci
Citat:
dragancesu: Sto mi ubi volju za MySql? Sta mu fali?


ne fali mu nista, ali ako vec mozes da biras bolje odaberes alat koji ce bolje da se poklopi sa potrebama, ja bi za taj projekat izbegao mysql ali ako treba da se budzne to u mysql svakako moze ..


Citat:
dragancesu:
Ne bi dokumente cuvao u bazi nego u folderima kao origilal, a program da zna gde su i da ih pokazuje po potrebi


to stvara brdo drugih problema
- neko moze da promeni dokument bez znanja baze, da ga obrise, promeni mu poziciju, sadrzaj ...
- bekap postaje uzasno komplikovan
- sutra ako treba da izbacis HA resenje opet imas dodatne komplikacije
- sutra ako treba da skaliras stvar, opet ..

etc etc ..
realno je kontent dobro da je na disku umesto u blobovima ali to nosi sa sobom komplikacije ... nfs deluje super na papiru, kad krenes da ga koristis uzivo dodje ti vrlo brzo da se roknes .. a kad ti neko napipa deljeni disk i da moze "brze" da pristupi pa slucajno uradi .... da ne idem u detalje, ima to svoje prednosti ali su mane ogromne

Citat:
dragancesu:
Ne bi trebalo da je nista toliko ozbiljno, vise da je korisno, tokom vremena dolazi mnogo ulaznih faktura i drugih dokumenata, i ako neke smatra da bi bilo olaksao posao (pratkticno pretrage) oko dokumentacije onda sam raspolozen da to pravim. Skenrati, indeksirati i arhivirati je verovatno jednostavnije nego se posle penjati i traziti po registrima

kao sto rekoh, moras da znas "svrhu" da bi mogao da odlucis sta i kako. no kao sto sam kazes:
Citat:
dragancesu:
No, kako svaki projekt pocenje "bice samo dve-tri stvari..." uvek se iskopmplikuje i prosiri


zato planiras "in advance" :D

Citat:
dragancesu:
Gledao sam malo open source resenja i na ekranima za unos nije bilo bas mnogo podataka, ali wordpress ima interesantan nacin indeskiranja stranica, prilikom unosa clanka ima jedno polje za KEYWORDS i tamo se unese tekst "REC1, REC2, REC3, REC4, ..." onda svaku rec indeksira i kljuc smesti u neku tabelu pa je posle lako traziti (mada je to prakticno po jednoj reci), indeks tabela je jednostavna


da i to radi zato sto je tako mnooooooooooooooogo brze nego da koristi mysql FTS .. isto rade i neki forum software-i, tj nude ti da biras os FTS ili njegovo lokalno indexiranje, lokalno indexiranje pravi vecu bazu ali radi znacajno brze.

Citat:
dragancesu:
Ucinilo mi se interesantno (i jednostavno) samo je pitanje koliko je efikasno, ovo je prakticno priprema i lako je pokazati spisak kljucnih reci, naravno treba ostaviti i "slobodan" unos za pretragu


super je efikasno, mnogo efikasnije od FTS-a

 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: mala pomoć oko strukture, kako je najbolje26.05.2015. u 09:45 - pre 108 meseci
Cisto da malo pojasnim FTS pricu, radi se o tome dda koristis FULLTEXT index na nekom polju i da radis MATCH... AGAINST , ili da ides na externi servis, tipa Sphinx. Evo lep link za ubuduce:

https://www.percona.com/resour...-56-full-text-search-throwdown

Ovo sto si ti napisao je super resenje, imas tabelu dokumenata, tabelu kljucnih reci i jednu veznu tabelu koja ce imati indexe po svemu i realno je brza - radis prost SELECT nad njom, nemas JOIN nemas nista. Ovo je zapravo najbrze moguce resenje. :D
Uostalom, ocekivanoo je da nesto sto ima indexe, i cemu se pristupa uvezano preko primarnih kljuceva i cistim poklapanjem radi par redova velicine brze. AKO ti je to dovoljno, tj. ako ti FTS ne treba, bez' od njega :). Ako moras, bar se dobro udubi u problematiku.

NFS isto nije neresiv problem, stavise - ima raznih dobrih resenja, od klasicnih heartbeat / drbd klastera, preko zamena tipa Ceph+RADOS, komercijalnih storage-a (EMC, NetAPP...), ili nekog Hadoop resenja sa NFS GW-om. Nista od toga nije nemoguce za implementaciju, ali jedna stvar stoji: Ako ti ovaj sistem bude trebalo da skalira trebace ti TIM. Ne jos jedan covek, vec bar jedan da ti projektuje sistemski deo posla, plus jedan da se bavi FTS-om, plus neko za front-end.... i to da ti SysAdmin i Search developer dele i DBA posao. :)

Konano, dobro osmisli backup celog sistema, jer ce ti vristati svi zivi ako pocnes da gubis fakture! Vodi racuna i prodji kroz checkliste, tipa :

- Dodatni direktorijum nije backup
- RAID nije backup

Konacno, pogledaj ta namenska resenja, moz' se desi da je jevtinije da kupis nesto nego da ga sam pravis, treba i o tome razmisliti.

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

[es] :: MySQL :: mala pomoć oko strukture, kako je najbolje

[ Pregleda: 2825 | Odgovora: 4 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.