(A rekord egy lineáris, direkt hozzáférésű adat szerkezet… így nem ellenőriz semmilyen adatszerkezetet.)Megint másik kérdés, hogy a komolyabb oo szerkezetekben nem használnak direkt hozzáférésű szerkezeteket, inkább függvényekkel oldják meg a hozzáférést, így pl. könnyebben szabályozható, hogy az adat írható, olvasható legyen-e.Egyébként mi az amire egy osztály nem képes és egy "rekord" (puszta adathalmaz) képes? Nem igazán értem...Művelet alatt függvényt értesz? Mert úgy kellene. Írj egy példát, hogy mi nem működik.

– A kérdésed az volt, hogy az egész táblát be kell tölteni, a válasz az, hogy nem. Nem pedig az, hogy semmit nem kell betölteni.- Azt amibe keresel, mindenkép be kell tölteni. Miért varázslatra talál meg a gép neked egy dolgot?- Egyébként azt mondtam, hogy az oo hierarchiára épült rendszer nem tölt be mindent egyszerre, hanem csak a memória címeket. Ha van egy Lista objektumod, az nem fogja tartalmazni a Lista Elemeit, hanem egy iterárort, egyéb függvényeket, mely léptet stb. Ettől függetlenül mozgatható az adathalmaz, adott esetben nem is kell a memóriában tartani, attól függ hogy van megírva.- A "findByPK"-nak objektumban kell lennie, mert ez Java. Teljesen mindegy, hogy oszlopnak, recordnak, tárolónak, művelet osztálynak nevezzük (meg oldjuk meg). Mivel úgyis használni kell az adatbázis interface-eket, a saját függvényeket értelmetlen is máshol definiálni (érdemes származtatni).- A "findByPK" nem "lehet" a rekordnak a függvénye, mert a visszatérési értéke a rekord. (Rekord nem kereshet a rekordokban, mert nem "látja" őket.) Az úgy egy logikátlan, komoly problémákat is okozhat. Pl. ne csodálkozz rajta, ha nem lesz szálbiztos/felülírsz valamit véletlenül, nem fordulnak le a templateid, vagy épp nem fér hozzá nem statikus változókhoz. Ez most nem gond, de később még lehet az.A ResultSet (a tábla "eredménye"), mely sorokból áll (nők adatai, férfiak adatai - amik származhatnak az adatokból pl.), melyekhez hozzá lehet adni, törölni lehet, (korlátozottan) keresni lehet, léptetni lehet és metaadatokat tartalmaz. Ez további adatokból áll, amit oszlopoknak hívunk, melyben a rendszer csak a cimkék szerint tud keresni.Ha te a rekordjaidban tárolsz egy nevet, címet, születési időt halálozási időt és ezekben is keresni szeretnél, vagy a cimkék között pl. "idő", akkor bizony saját függvényeket kell írni, mert nem fogja megkeresni neked a táblázatkereső, mert nem ez a feladata, nem univerzális.(Persze akár lehet feljebb is helyezni a szintet: lehetnek férfiak táblái, nők táblái, így már 3d-s az adatbázis. Persze, jelen példában ez hülyeség, de nem ez a lényeg. Meg persze, ha jól tudom Array és a ResultSet "korlátlanul" egymásba ágyazható. A ResultSet-nek van getArray, az Array-nek van getResultSet fügvénye.)Továbbá, ha nem tetszenek a Java függvények, akkor még mindig futtathatsz - elvileg - sql utasításokat (executeUpdate). Erre megírhatod a saját osztályaidat, függvényeidet. Nyilván sokkal testreszabottabb lesz, mint a Java kód.Nem akarom - végül is - ráderöltetni a már megírt beépített kódokat sem, meg ezt a - ha jól értem - róka-fogta csuka statikus definiálós elvetését sem, csak a véleményemet írtam le.

(Nem kell find osztályt létrehozni, lád pl. egy sztring tároló osztály összes függvénye… érdemes ezt tanulmányozni.Abszolút nem értem, hogy neked az ilyenek "UserRecord().findByPK(id)", miért "könnyebbek". A UserRecord keres a UserRecordok között? Ennek nincs értelme, hacsak nem a szándékos hibák /rögtön szálbiztonság dobása/ és átláthatatlanság kreálása. Persze ezzel a dinamikusságot és a rugalmasságot is csökkentetted, mert a UserRecord nem ismerheti a UserRecordokat, csak, ha egy darab statikus Lista van, vagy akkor, ha átadod a Listát. Az utóbbi a szálbiztosságot azonnal dobja, azon kívül baromira lassú is lehet átadni a Listát, ha rosszul van megírva... márpedig, ha nincs Lista kezelő objektumod (és tömböt adsz át), akkor bizony rosszul van megírva.)Neked a tároló és a tároló tartalma egy osztály, ami több problémát okoz.A templateknél tuti szívni fogsz, ha jól értelmezem szívni is fogsz. (Meg még ki tudja hol.)A Java sokkal kötöttebb, mint a C++ így egy bonsolultabb szerkezeteknél, a származtatásoknál szintén gond lehet.Ezen kívül átláthatatlanabb, mint egy szép hagyományos Java (sőt standard C++) struktúra, ezért nem szokás ilyet alkalmazni.Igen jól látod, a tároló struktúrát (származtatásokat) ajánlott az elemek struktúrájától külön definiálni. Sőt egy iterátort is. (Bár jelen esetben az utóbbival nem érdemes foglalkozni, mert van remek beépített.)A Java egy sokkal erősebben objektum orientált rendszer. Bár a C++ is ettől lesz struktúrált, átlátható. Ezek nem felesleges dolgok, erre van a rendszer kitalálva, ki kell használni. Sőt ilyen esetekben (kivéve természetesen a paraméteres műveleteket) még C-ben is érdemes objektumokat létrehozni. Java esetén a műveleti függvények is objektumok.Nézz meg bármilyen oo tárolót, mindenhol ilyet használnak. Vagyünk pl. egy sztringet, widget rendszert stb. (Java, std C, gobj, qt) mind így struktúrálja... valami oka csak van.Van egy előre definiált konténer (List, Vector, akármi), ebből származik a Record tárolód (pl. RecordList), minden kereső, összehasonlító függvényt ez tartalmaz, lásd a String-et, mely pl. karaktereket tárol. (Te a karakterek helyett Recordokat ill. Recordból származó osztályokat tárol.)

Attól függ, hogy milyen műveleteket akarsz végrehajtani.Íme néhány példa.Ha csak kereső algoritmus kellene, akkor a tárolót egy tároló osztályból (List, Vector) származtatnám.Minden adott az elemek hozzáadásához, törléséhez stb.Record

„AR record”-nak miért kéne UserRecord-ot visszaadni?De, ha pl. valamiféle lista elemet akarsz létrehozni, melynek a UserRecord az eleme AR a tárolója, akkor nem származtatott osztály kell.Valami ilyesmi lenne:

(Lásd.: pl. List... sőt elméletileg, ha van megfelelő beépített tároló, akkor elvileg lehet abból is származtatni.)Nyilván lehet a UserRecord is egy olyan osztály, melynek származtatott osztályai vannak, ha pl. többféle (kezelés szempontjából specifikus) UserRecordokat szeretnénk kezelni.