- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- AMD Navi Radeon™ RX 7xxx sorozat
- Alacsony fogyasztású, 128 GB-os szervermemóriát kínál a Micron
- Kormányok / autós szimulátorok topicja
- Mini PC
- Milyen belső merevlemezt vegyek?
- Fujifilm X
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
Hirdetés
-
A virágcsokor mellé hardvert is ajándékozhatunk anyák napján
ph A héten desktop PC-k, monitorok, gamer kiegészítők és házak vannak a kirakatban.
-
Egyre nagyobb a balhé a Helldivers II körül
gp Úgy tűnik, hogy egyre több sötét felhő kezd gyűlni a játék körül a Sony döntése miatt.
-
A franciáknak elege van abból, hogy minden gyerek mobilozik
it Vissza akarják szorítani a gyerekek és tinédzserek közösségi média- és okostelefon-használatát.
Aktív témák
-
nagyúr
Sziasztok,
javaslatokat-segítséget kérnék az alábbiakhoz.
(mindekelőtt megemlítem, hogy abszolúte nonprofit a dolog, nem mással akarok pénzt kerestetni :), mindössze egy, az élő nyelvekkel kapcsolatos gondolatnak próbálok a végére járni, de ezt egyelőre nem részletezem.).
Elméleti kérdések-követelmények:
Szeretnék egy gráfot tárolni egy adatbázisban. A gráfnak több speciális tulajdonsága is van.
- a pontjaihoz tetszőleges információ legyen rendelhető és lekérdezhető
- az élek irányítottak, és szintén egyedileg lekérdezhető és hozzárendelhető tulajdonsággal rendelkezzenek
- meg kellene oldani, hogy a gráfban tudjak utakat letárolni, és adott pontról eldönthető legyen, hogy az adott kiindulópontú és adott végpontú útnak eleme-e.
- két pont között az összes utat egyszerűen fel lehessen térképezni, nem elég az utak számát tudni, hanem az egyes utak tagjait is ismerni kellene.
A gráf pontjainak száma (N) nagyságrendileg 1000-10000 körül mozog, a kapcsolatok száma pedig 100000-1000000 között.
Kérdés: SQL-t használjak a gráf tárolására, vagy egyedi adatbázist? (azért szimpatikus egy ''hivatalos'' adatbáziskezelő, mert egy ekkora adatbázist rendes indexelés/egyebek nélkül szerintem nem lehet kezelni)
Kérdés: milyen formában tároljam le? Gráfokat ugyebár összekapcsolási mátrix formában szokás tárolni. Egyelőre nem jutott más az eszembe, mint egy olyan sql tábla, amely gyakorlatilag egy kvadratikus mátrix, de ezzel több gond is van, pl. az, hogy n^2-el arányos a táblaméret, másrészt minden egyes új pont felvételekor egy új oszloppal és egy új sorral kellene bővíteni a táblát, amely elég macerásnak tűnik..Ráadásul egy adott pont tulajdonságait is kellene tárolni, amelyet nem tudom, hogy oldjak meg - minden pontnak új tábla :?..
Kérdés: Hogy oldjam megy a harmadik problémát anélkül, hogy túl sok felesleges adatot tárolnék le? Én arra gondoltam, hogy minden útnak lenne egy azonosítója. Ha egy út átmenne egy ponton, akkor a ponthoz hozzárendelnénk az út számát.
Programozási kérdések-követelmények:
- A gráf variálását interneten keresztül is meg kellene tudni oldani, tehát parancsok bevitelével kellene tudni új pontot létrehozni, új kapcsolatot létrehozni, stb. Erre lehetne mondani, hogy PHP, de:
- jó lenne, ha konzolszerűen lehetne elérni az adatbázist, tehát nem html formokkal, hanem kliens-szerver-szerűen (ez persze nagyképű megfogalmazás, magyarul mint egy irc kliens kellene működjön, de webről, és nem letölthető kliensprogrammal).
- a gráf miatt a főprogramnak rengeteg mátrixműveletet kellene elvégeznie, tehát egy php szóba se jöhet.
Javában még nem tudok, de ha alkalmasnak találjátok erre a feladatra, akkor annyit megér, hogy egy kicsit beletanuljak. Valahogy nem lehet megoldani, hogy C programot használjak internetes alkalmazásokhoz? Ehhez a részéhez abszolúte nem értek, szóval ha valakinek van ötlete...
köszi a javaslatokat előre is.while (!sleep) sheep++;
-
Clyde22_
tag
Miért relációs-elvü adatbázist akarsz használni? Pont erre nem igazán megfelelö... :DD
Ne egyél a sárga hóból!
-
Szalma
őstag
Hmmm... Szerintem itt olyan problémát próbál megoldani, kedves Mester, amire a nagyon nagy és nagyon drága szoftverek sem képesek napjainkban. (IBM kepeszt most egy ''mindent eltárolunk, majd kérdezünk'' adatbázis kezelővel.)
Sql-t nem szabad használni, ha elfogadható időben kell választ kapni. Mindenképp javaslok egy egyedi fejlesztést (C-ben vagy C++-ban jó gyors is lehet) és meg kellene próbálni minden adatot a memóriában tartani (mondjuk valamilyen trükkös bitmap indexxel...?). (1G RAM is olcsó mostanában.) A memóriát pedig lehetne egy alacsony prioritású threaddel körkörösen file-ba írni, ha kritikus az állapota. C++ nagyon jó gráfokban egyébként... Esetleg körülnézni XML adatbázisok környékén, de... :(
Java jó ötlet, de ha nincs tapasztalat, akkor inkább ne. Elég távoli a C-s rokonság...
TCP/IP felületet pedig egyszerű rárakni egy stdin/out-ot használó programra...
Most több gondolatom nincs, ha vmi eszembe jutna még, írok...
Szeretettel:
Szalma -
nagyúr
Na újabb apróság.
Adott egy rekord (C, CPP). Szeretnék hozzárendelni információkat, azonban ezek számát nem szeretném maximálni. Tehát lehet, hogy egy 5000 elemű tömb csatlakozik hozzá, lehet, hogy 1. Nem lenne jó egyből valami óriási területet lefoglalni, ellenben problémamentesnek kellene lennie gyakorlatilag korlátlanul sok adat hozzárendelése esetén is.
Nyilván fájlban egyszerűen tárolhatónak kellene lennie.
Amire én gondoltam: adni minden egyes rekordnak egy id-t, majd egy másik fájlban
[id][adat] formában tárolni az adatokat. Ezt id szerint rendezve kellene tartani, így könnyen megtalálható lenne az adott id-hez tartozó összes adat. Azonban hogy ne kelljen minden egyes adatfelvételkor újrarendezni az adatbázist, a rendezett adatok után lenne egy rendezetlen adatsor, amit - miután az adott id-hez tartozó adatokat kiolvastuk a rendezett tömbből - lineárisan végigkeresve még kibogarásznánk a lényeges adatokat.
(ez az egész a gráf pontjaihoz tartozó adatok tárolására szolgálna)
Van valakinek gyorsabb ötlete?while (!sleep) sheep++;
-
Szalma
őstag
Érdemes lehet ilyenformán elgondolkodni egy journal-os filerendszer adatbáziskénti használatában. id -> filenév, adat -> file tartalom. Egy jó rendszer (mondjuk IBM JFS) simán megküzd ~1M kis filelal... Ha lassú, lehet RAID-be tenni... Esetleg elosztott NFS-re... Csak agymenés volt. :) Memóriában pedig vektor a barátod, nem a tömb...
Szeretettel:
Szalma -
HÁZIGAZDA
Ez utóbbi tipikusan objektum-relációs adatbázis-táblákban tárolandó.
TABLE rekord (
id,
...
);
TABLE rekord_adat (
id,
rekord_id,
...
);
Mivel a kapcsolatok kizárólag 1 rekordhoz sok adat irányba mennek, ezért a relációs táblát nem is kell külön megcsinálni, a rekord_id mezővel ez a rekord_adat táblában van. Indexeket innentől kezeli az SQL, pár millió elemig tuti jó vagy, 100 milliós nagyságrendben nem tudom.dicranum scoparium + genista pilosa = :)
-
Hory
aktív tag
Algoritmuselmelet orakon aludtal? :)
A problema a dinamikusan valtoztathato meretu tomb megvalositasa. Erre meg rengeteg megoldas van, attol fuggoen, hogy _PONTOSAN_ mit akarsz csinalni vele, milyen muveleteknek kellene gyorsaknak lenniuk, stb...
2 modszer.
1. Alias java-s arraylist
lefoglalsz egy adott meretu teruletet, ha jon uj adat, akkor szepen oda pakolsz, ha megtelik, realloc()-olsz egy X-szer nagyobb teruletet, es goto 10 (ahol X adja meg, hogy a CPU/memoria kozul melyiket zabalja jobban).
Ez eleg primko, de kis meretekben kivalo.
2. Alias stl-es vector (legalabbis asszem az igy muxik)
Lancolt listat kepzelj el, amiben az adat az irt memoriablokkok. Igy az iras konstans ido, mint a villam, es ha vegig kell menni szep sorban az adatokon, az is gyakorlatilag olyan gyors, mintha egyben lenne az egesz. Hatranya, hogy eleg bonyolult megvalositani benne egy adott elem elereset, illetve a torlest. De ha ez utobbi ketto (es a hozza hasonlo muveletek) nem jellemzoek, akkor ez messze a leggyorsabb.
Amugy meg: jozan paraszti ez rulez. belaim, gondolkodjunk. -
Hory
aktív tag
Haaat, mi csinaltunk ilyesmit. Nem egy leanyalom. Szerintem, amit akarsz, azt nem lehet megcsinalni, de meg ha ossze is jonne, tetu lassu lenne.
DAG-ot lehet csinalni vele, de eleg maceras lekodolni.
Itt is 2 modszer.
1. Oslistaval
Redundansan letarolod minden ponthoz az osszes oset. Ertelemszeruen ilyenkor egy kulon mezoben jelezni kell, hogy az adott rekord hanyadik ose.
Igy teljes gyerek/os listat tetszoleges ponthoz egy sima select-el le lehet kerdezni, indexek hasznalataval eleg gyors, es ha nem tul mely a fa, akkor meg nem is tul redundans (bar ez manapsag kevesbe szempont, ilyen irdatlan tarolokapacitas mellett).
2. Intervallumos modszer
Ez nem redundansan kepes tarolni fat (de csak azt, szemben az 1. modszerrel). Az otlete nagyon ugyes: minden rekord (=pont, ha eddig nem lett volna vilagos) tartalmaz egy intervallumot is. Amelyik rekord tartalmazza a mi intervallumunkat, az osunk. Az osok kozotti sorrendet meg pl. az intervallum meretevel lehet legkonnyebben meghatarozni.
Ez egy ugyes modszer, gyors is, de nagyon limitalt azon muveletek szama, ami elvegezheto rajta emberi idoben.
PS: most egy darabig nem leszek netkozelben, bocs -
nagyúr
1. Alias java-s arraylist
Ez elvetve.
2. Alias stl-es vector (legalabbis asszem az igy muxik)
Láncolt listával nem foglalkozom, szerintem nem biztonságos, ráadásul piszkos lassú. A keresés-beszúrás nem probléma, de oly mértékben lassú, hogy bármi más módszer alkalmasabb lenne rá..while (!sleep) sheep++;
-
nagyúr
Redundansan letarolod minden ponthoz az osszes oset
Itt sajna nem egy fáról van szó, hanem egy általános gráfról (kivétel, hogy a kapcsolatok irányítottak és többfélék). Szóval az ősös módszer elvetve, ráadásul iszonyat tárkapacitást igényel. Lentebb írod, hogy ez képes tárolni általános gráfot is, de azt meg nem ezzel érdemes megvalósítani.
Azt hiszem, egyelőre kézenfekvő egy sql-es vagy ahhoz hasonló C-s megoldás, ahol egy tábla a pontoké [id, name] (ha C-s, akkor megcsinálom az indexelt elérést úgy, hogy egyszer az id, egyszer a name a kulcs), a másik tábla pedig a pontok adataié, amely gyakorlatilag egy bucket hashing-indexes kutyulmány lesz.
Egyelőre az sem biztos, hogy lesz értelme annak, hogy mindezt megcsinálom (esetleg).
Mégegy: C-ből milyen libraryval lehet sql-t elérni?
Köszi a gondolkodást mindenkinek. :Pwhile (!sleep) sheep++;
-
lao ce
aktív tag
hatha latsz benne fantaziat, ket eleg elrugaszkodott otlet:
olap - maga a struktura szerintem hasznalhato, lasd pl itt: http://www.him.upmc.edu/courses/hrs2424/notes/OLAPServices_Final_1203.pdf
a kovetkezo egy delphi vizualis tree komponens -talan nem huzhato ra a felatdatra, de eleg gyors (1 millio node hozzaadasa 438 ms a gepemen), save/load, tetszoleges ertekek egy tagban adhatok es lekerdezhetoek, azonositott kapcsolatok, meg nagyon sok minden megoldna tok automatikusan, es persze az egeszet latni lehet, szoval talan erdemes vetni ra egy pillantast (free):
Virtual Treeview http://www.delphi-gems.comnicht kompot
-
bocs
csendes tag
hm legalább 2 fő probléma van itt.
- nagy mennyiségű adat eltárolása, beolvasása
- útkeresés
attól függ a javasolt megoldás, hogy milyen a kettő aránya, tehát sokszor kell-e adatokat
felvinni/módosítani vagy inkább statikus adatokról van szó, ahol a tipikus művelet a keresés.
Mivel ilyen nagy tömegű adatot akarsz kezelni, és rugalmas rendszert akarsz (''tetszőleges''
attribútumok hozzárendelése entitásokhoz) nem érdemes egyedi adattároló rendszert
használni, csakis a jól bevált standard SQL alapú adatbázisokat. Saját rendszer kifejlesztése
gyengén fizetett melónál nem javasolt...
tipp:
Table Node (NodeId, MainAttribute1, MainAttribute2, ...)
Table Edge (EdgeId, BeginNodeId, EndNodeId, MainAttribute1, ...)
Table Path (PathId, MainAttr1, ...)
Table PathElement (PathElementId, PathId, EdgeId, PathSerial)
opcionálisan:
Table Attribute (AttrId, Name, Type)
Table NodeTextAttribute (NodeId, AttrId, Serial, Text)
Table EdgeTextAttribute (EdgeId, AttrId, Serial, Text)
Table PathTextAttribute (PathId, AttrId, Serial, Text)
Table PathElementTextAttribute (PathElementId, AttrId, Serial, Text)
stb
A keresést kétféleképpen lehet elképzelni:
- állapotmentes kereső motorral, ahol mindig csak az adatbázisból kell kivenni kevés adatot,
tehát itt az RDBMS indexek végzik a piszkos munkát. Hogy ezt meg lehet-e csinálni, az a gráf
bonyolultságától függ (mennyi a tipikus kapcsat/pont, milyen hosszú utakat akarsz keresni).
CGI-hez mindenféleképpen ez javasolt, PHP-ben lazán megcsinálható, feltéve ha a feladat
megengedi.
- két fázisban működő motorral: C++ progi, ami benyalja az adatbázist, majd a memóriában
végzi a keresést. Tipikus C++ STL feladat. a vektorokat el kell felejteni, map<> és
multimap<> segítségével O(logN) sebességű keresést kaphatsz. Ez nem igazán alkalmas CGI
rendszerben való használatra, hiszen kizárt, hogy minden lekérdezésnél betöltse az összes
adatot. Ha mindenképpen CGI kell, akkor lehet olyat csinálni, hogy írsz egy primitív C++
szerverprogramot (pl c++ builderben, Kylix-ben sem nagy etvasz, ami elindulva betölti az
adatokat, X porton figyel kérésekre, és pl HTML-ként visszadobja az eredményeket).-bocs a hardwerláma-
-
nagyúr
''gyengén fizetett melónál nem javasolt... ''
Nem munkaköri dolog.:)
''Table Path (PathId, MainAttr1, ...) ''
Na itt a gond (azaz nem gond, végülis van rá megoldás), tehát külön tárolni az utakat sokkal több keresés, mintha pontokhoz rendelném őket (de azt hiszem, ezt is kipróbálom, sqlben).
A második részét illetően fogalmam sincs, mi az a c STL, de biztos rájövök:D.
Azt hiszem, előszőr mégis marad valami lassú, de működő megoldás, hogy lássam, egyáltalán működik-e amit akarok.
Köszi.,while (!sleep) sheep++;
-
rog
addikt
a grafban tetszoleges ket pont kozott keresel utat, es az meg nincs letarolva az adabazisban, akkor hogy kellene mukodnie?
beolvassa az osszes pontot, felepiti a grafot a memoriaban es megkeresi az utat majd visszairja.
vagy ugy hogy az adatbazist folyamatosan olvassa es azonnal keresi az utat? -
nagyúr
Kérdés:
VC++-ban mysql-t akarok használni. Adott a libmysql.lib és libmysql.dll.
Szépen bemásoltam őket a ...../lib-be és a windows/system-be is; de a program fordításánál kapok egy ilyet:
Linking...
test.obj : error LNK2001: unresolved external symbol _mysql_stat@4
test.obj : error LNK2001: unresolved external symbol _mysql_list_tables@8
test.obj : error LNK2001: unresolved external symbol _mysql_error@4
test.obj : error LNK2001: unresolved external symbol _mysql_list_processes@4
test.obj : error LNK2001: unresolved external symbol _mysql_get_server_info@4
test.obj : error LNK2001: unresolved external symbol _mysql_get_host_info@4
test.obj : error LNK2001: unresolved external symbol _mysql_get_client_info@0
test.obj : error LNK2001: unresolved external symbol _mysql_free_result@4
test.obj : error LNK2001: unresolved external symbol _mysql_num_fields@4
test.obj : error LNK2001: unresolved external symbol _mysql_fetch_row@4
test.obj : error LNK2001: unresolved external symbol _mysql_fetch_field@4
test.obj : error LNK2001: unresolved external symbol _mysql_num_rows@4
test.obj : error LNK2001: unresolved external symbol _mysql_store_result@4
test.obj : error LNK2001: unresolved external symbol _mysql_query@8
test.obj : error LNK2001: unresolved external symbol _mysql_close@4
test.obj : error LNK2001: unresolved external symbol _mysql_select_db@8
test.obj : error LNK2001: unresolved external symbol _mysql_real_connect@32
test.obj : error LNK2001: unresolved external symbol _mysql_init@4
LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@16
Debug/UVE.exe : fatal error LNK1120: 19 unresolved externals
Error executing link.exe.
UVE.exe - 20 error(s), 0 warning(s)
Hogy tudom megoldani?while (!sleep) sheep++;
-
-
WaterLo
aktív tag
''- meg kellene oldani, hogy a gráfban tudjak utakat letárolni, és adott pontról eldönthető legyen, hogy az adott kiindulópontú és adott végpontú útnak eleme-e.''
Úgy érted, hogy a legrövidebb útnak eleme-e?
Mert tetszőleges hosszúságú útnak szerintem mindenképpen eleme.
De javítsatok ki, ha tévedek.....What's up!....
-
yerico
senior tag
Mi már fejlesztettünk nagy magyar távközlési cégnek nagy relációs adatbáziskezelőben gráfot kezelő rendszert.
Külön tároltuk a pontokat, és külön az éleket (pont1, pont2, irány (0/1/2), az utak pedig útID, pont1, pont2 rekordok halmaza volt
Útvonalkereséskor az egészet felolvastuk memóriába, ott szépen felépítettük a gráfot 3 tömbbe, és ott folyt a keresés. Az tény, hogy erre még hatékony algoritmust nem sikerült írnunk, pedig nekiláttunk már párszor, ellenben garantáltan működött, mivel teljes bejárást végzett, megkereste az összes lehetséges utat, és visszaadta a kívánt feltétel szerintit.
Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest