- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Milyen okostelefont vegyek?
- Yettel topik
- Vivo X200 Pro - a kétszázát!
- MIUI / HyperOS topik
- Fotók, videók mobillal
- One mobilszolgáltatások
- Nem minden Nothing Phone (3) születik egyenlőnek
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
Aktív témák
-
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. -
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? -
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). -
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.com -
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 -
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. -
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. -
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
Aktív témák
Hirdetés
- Óvodások homokozója
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen processzort vegyek?
- Milyen videókártyát?
- ldave: New Game Blitz - 2025
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Napelem
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- További aktív témák...
- Antivírus szoftverek, VPN
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Assassin's Creed Shadows Collector's Edition PC
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- BESZÁMÍTÁS! MSI MAG321QR 32 165Hz WQHD 1ms monitor garanciával hibátlan működéssel - használt
- ÁRGARANCIA! Épített KomPhone Intel i7 14700KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- A Panasonic Toughbook CF-54 i5-5300u i5-6300u TN, IPS touch Budapest, MPL Foxpost
- Jo Nesbo: LEOPÁRD (nem olvasott)
- Xbox Ultimate előfizetések
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest