Adatbázis-kezelés kezdőknek - PostgreSQL tanfolyam?

Adatbázis: SQL, XML DB

Szervusztok!

Tudtok nekem olyan, kezdőnek szóló képzést, ami PostgreSQL-ben utazik, esetleg létezik ez ügyben aktuális magyar nyelvű könyv, mint pl. a php-vel kapcsolatban sok ilyet láttam? Vagy olvassam el inkább a manuált? - Magyar nyelven nem nagyon hasít a gyik gyártás ezen a téren, tudom, tanuljakvilágnyelvet. - Alapvetően az adatbázis-kezelés alapjai, fogalmai érdekelnek, ennek az adatbázis-kezelőnek a kapcsán. :) Vagy az minden kezelőnél ugyanaz. Szeretném megtakarítani, az „ennél az adatbázisban kicsit másként van” fél napig tartó megoldáskereső köröket.

Igazán a kérdést sem sikerült normálisan feltennem.

Köszönöm előre is, ha adtok ötleteket.

  • 1973 megtekintés

( Toth Lali | 2023. 03. 10., p – 20:17 )

Pontosítani kellene, hogy programozás vagy üzemeltetés (asszem...)

( n.balazs v | 2023. 03. 10., p – 22:59 )

Az adatbázis-kezelők alapjai, működése, elmélete az mennyire van meg neked? Pl: adatmodellek, normál formák, SQL nyelv stb.

+1 Én is ezt javaslom, hogy az elméleti alapokat tanuld meg előbb (vagy közben vagy utána, lényeg hogy ne hagyd ki)! Ez az a terület, amit ha gyakorlat alapján tanulsz meg, akkor esetleg elmehet melletted a lényeg. A netes példák is sokszor borzalmasak.

Adatbázisok esetén két dolog van, amit el szoktak rontani:

 * az adatok konzisztensen tartása

 * lekérdezések hatékonysága

Mindkettő olyan, hogy csak akkor tudod jóra megcsinálni, ha érted az elméletet.

A PostgreSQL szerintem jó választás. Én legalábbis szeretem. Hatékony és elméletileg is helyes motor van alatta amennyire tudom. Tananyagnak egy egyetemi tankönyvvel kezdenék pláne, ha nem megy az angol. (De tanulj meg angolul, igaza van a többieknek ebben is!) A BME-n mi Gajdos könyvéből tanultunk, ha jól emlékszem, ez pedig annak egy újabb változatának tűnik, és ingyen van: https://db.bme.hu/~gajdos/Adatbazisok2019.pdf Feladatok is vannak benne, amiket megvalósíthatsz például PostgreSQL-ben is.

( zeller | 2023. 03. 11., szo – 00:05 )

"tudom, tanuljakvilágnyelvet" - Igen, tedd azt első körben.

no no no. En is a noSQL-t preferalom egy csomo esetben, de azert nem ilyen fekete-feher a dolog. A NoSQL adatbazisok zome azert nem ACID. De pl a mai vilagban az eros schema mar csak bizonyos rendszereknel alapkovetelmeny, de ott nagyon. Es bar a NoSQL-nel is lehet eros shema kovetest beallitani szamos esetben, azert nem mindegy a felhasznalasi mod. A masik hogy manapsag mar a regi RDBMS rendszerek-et is kezdek kiegesziteni egy nagyon fontos tulajdonsaggal a distributed adatkezelessel (lasd postgresql citus), mert nem a replikacio az nem az.

Aztan ott az OLTP vs. OLAP kerdes. Mig a noSQL az OLAP-ban jo, addig az rdbms az OLTP-ben. De az otubbi evekben mind a ket vilag nagy erokkel tamadta be a szamara eddig idegen teruleteket. :D

Szoval ahogy a noSQL-ek ACID-osodnak kicsit, ugy a regi RDBMS-ek is mennek a NoSQL fele, pl a PostgreSQL timescale a timeseries adatoknak amik eredentdoen colomnar storage-be valok kivalo. Stb, stb.

A NoSQL adatbazisok zome azert nem ACID

Meglepetes, de a document store atomic update-t garantal document szinten. namost mivel a document egy komplett data model magaban, az az allitas, hogy "nem ACID", erosen szuklatokoru. Konkretan, ameddig belefer egy document-be az adat, addig optimistic locking-al megfejelve teljesen ACID.

 

Schema: ez inkabb zavaro, mint barmi egyeb. Hiszen ott van a model a kodban! Minek duplikalod egy teljesen masik rendszerben, gyakran megeroszakolva a termeszetes modellt az SQL limitacioival?

 

SQL-t nem igazan lehet cluster-elni, pont a tranzakcio altal nyujtott garanciak miatt. Gondolj bele, ha az olvasott/irt sorokat/indexet es a fantom row-kat replikalni kell minden tranzakcional a tobbi szerverre, az minden lesz, csak gyors nem. Elvi hibak vannak a SQL-ben, ami a 70-es evek mainframe-jein nem volt gond, de ma nagyon.

Meglepetes, de a document store atomic update-t garantal document szinten.

Meglepetés, de bármilyen adatbázisnál egy táblára vonatkoztatva az update atomic. Az ACID több tábla esetén jön szóba, a legtöbb NoSQL implementáció nem tud több táblára komplett ACID szolgáltatást.

namost mivel a document egy komplett data model magaban, az az allitas, hogy "nem ACID", erosen szuklatokoru.

Szerintem erősen szűklátókörű azt feltételezni, hogy a NoSQL = MongoDB.

SQL-t nem igazan lehet cluster-elni, pont a tranzakcio altal nyujtott garanciak miatt.

Hogyne lehetne.

Gondolj bele, ha az olvasott/irt sorokat/indexet es a fantom row-kat replikalni kell minden tranzakcional a tobbi szerverre, az minden lesz, csak gyors nem.

Viszont garantált az ACID. Ha meg gyors kell, akkor tudod úgy használni, hogy nincs tranzakció.

Elvi hibak vannak a SQL-ben, ami a 70-es evek mainframe-jein nem volt gond, de ma nagyon.

Amúgy ilyenkor mit értesz SQL alatt?

https://iotguru.cloud

Meglepetés, de bármilyen adatbázisnál egy táblára vonatkoztatva az update atomic. Az ACID több tábla esetén jön szóba, a legtöbb NoSQL implementáció nem tud több táblára komplett ACID szolgáltatást.

Ez igy van. Csakhogy amig egy tabla egy primitiv A=B lista, addig a document egy laza schema-ju fa, egy json document. Ossze se hasonlithato a ketto; az egyik egy excel tabla, a masik egy komplett adatmodell.

 

Viszont garantált az ACID. Ha meg gyors kell, akkor tudod úgy használni, hogy nincs tranzakció.

Osszevissza beszelsz. A SQL adatmodell arra epul, hogy az adatmodelled szetbontod mestersegesen tablakra, es azokon vegzel atomi muveleteket.

SQL-ben az ACID alapveto, mert hulye modon szetverted az amugy egyszeru, ertheto adatmodelled egy halom tablaba es azok kapcsolataiba.

ACID-ot garantalni SQL cluster-ben ugy, hogy az barmifele teljesitmenyt is nyujtson, nem lehet.

Ez az, ami alatt azt ertem, hogy a SQL alapveto, elvi hibakkal rendelkezik, es nem alkalmas a mai igenyek kielegitesere, csak massziv hekkelesekkel.

Csakhogy amig egy tabla egy primitiv A=B lista, addig a document egy laza schema-ju fa, egy json document.

A natív JSON/JSONB támogatás a PostgreSQL esetén a 9.2 verzió (~2015) óta, a MySQL és a MariaDB esetén az 5.7 verzió (~2015) óta, az Oracle esetén a 12.1.0.2 verzió (~2014) óta van. Nem néztem végig az összes RDBMS megoldást, de szerintem a többi ismertebb esetén van már jó ideje native JSON/JSONB támogatás. Szóval közel 10 éve lehetőség van RDBMS esetén flexible schema használatára, beleértve, hogy indexelhető, kereshető és relációban használható a JSON tartalom.

Ossze se hasonlithato a ketto; az egyik egy excel tabla, a masik egy komplett adatmodell.

Aham, még mindig ott tartunk, hogy nálad NoSQL = MongoDB és alapvetően nem ismered a többi megoldás tudását és lehetőségeit.

A SQL adatmodell arra epul, hogy az adatmodelled szetbontod mestersegesen tablakra, es azokon vegzel atomi muveleteket.

Lófaszt épül erre.

SQL-ben az ACID alapveto, mert hulye modon szetverted az amugy egyszeru, ertheto adatmodelled egy halom tablaba es azok kapcsolataiba.

Flexible schema esetén is alapvető, mert nem tudsz mindent egy darab dokumentumba belepasszírozni. Ezért volt igény MongoDB esetén is a multi-document ACID támogatás, amit kibővítettek később arra, hogy nem csak azonos shard esetén működik.

ACID-ot garantalni SQL cluster-ben ugy, hogy az barmifele teljesitmenyt is nyujtson, nem lehet.

De, lehet.

Ez az, ami alatt azt ertem, hogy a SQL alapveto, elvi hibakkal rendelkezik, es nem alkalmas a mai igenyek kielegitesere, csak massziv hekkelesekkel.

Az a helyzet, hogy a te hozzáértésed rendelkezik alapvető hibákkal és hiányosságokkal...

https://iotguru.cloud

Történelem:

1. Hierachikus modell
2. Hálós modell
3. Relációs modell
4. Á, ez nekem bonya, az én adataim mind hierachikusak, menjünk vissza az egyes ponthoz
5. Mivel az én egyszerű adataimra a hierachikus modell is jó, nyilván való, hogy a többi módszer elavult hülyeség.

Nem akarok vitatkozni veled, mert ugy latom "eleg szuklatokoruen" alkalmazod a noSQL fogalmat. De peldaul dokumentstore-ban igenis celszeru neha a schemat definialni. Lasd az ElasticSearch dynamic mappingja neha nagyon nem jo. Az also bejovo dokumentum semaja lesz a sema, ami azt okozza, hogy mondjuk a "http_response: OK" azaz string tipus lesz, mikozben ez mondjuk az egyik fejleszto hibas outputja, mikozben a valid mondjuk egy json objektum, ami a 99%-aban jon a dokumentumoknak. Azaz az adott indexben az adatok 99%-a el lesz dobva az invalid type miatt. 

Na ennyire zavaro semat kezelni egy nosql implementacioban. A masik monduuk a tomeseries es columnar storage. 

Aztan egy csomo esetben a nosql adatbazisok distributed modon mukodnek. Ennek egyik hatulutoje, hogy nem garantalhato a tranzakciok sorrendje, ami maris uti az ACID-ot. Mert sem az Atomic nem garantalt (ezert is van csomoszor szukseg a deduplikaciora), sem pedig az Isolation.

De hagyjuk is mert latom elegge erosen meggyozted magad a velemenyedrol :D

Es ja, lehet az rdbms szerevereket is clusterezni. Tobb modon is. De ezt mar elottem is irtak.

Namost normalis/modern architekturaban nem osztasz adatbazist tobb service kozott. Olyan nincs, hogy "egy fejleszto...", mert kezzel nem irunk production adatbazisba.

Masreszt, ha szemetet irsz az adatbazisba, akkor szemet lesz benne, igen. Ezert vannak ugye az automatikus integration tesztek, amik minden build-nel lefutnak.

Document store eseten megoldhato, hogy 1 master legyen minden dokumentumra, es optimistic lock-al tortenjen az update. ennek koltsege gyakorlatilag elhanyagolhato.

Distributed SQL-t nem tudsz csinalni, mert vagy a lock-ok propagalasa a tobbi szerverre prohibitiv idot lesz igenybe, vagy ha ezt nem teszed, a szejjelszabdalt adatmodell + auto-id allocation miatt commit kozbeni utkozesek gyakorisaga lesz prohibitiv nagy load alatt.

Document store eseten megoldhato, hogy 1 master legyen minden dokumentumra, es optimistic lock-al tortenjen az update. ennek koltsege gyakorlatilag elhanyagolhato.

Mi lenne, ha ilyen mondatokban kicserélnéd a "Document store" kifejezést arra, hogy "MongoDB"? Van sok document-oriented adatbázis, ami ebből adódan NoSQL (CouchDB, DocumentDB, DynamoDB, Elasticsearch, OrientDB, stb), de nem így működik.

Distributed SQL-t nem tudsz csinalni, mert vagy a lock-ok propagalasa a tobbi szerverre prohibitiv idot lesz igenybe, vagy ha ezt nem teszed, a szejjelszabdalt adatmodell + auto-id allocation miatt commit kozbeni utkozesek gyakorisaga lesz prohibitiv nagy load alatt.

Ez bullshit.

https://iotguru.cloud

Kicsit átmegyünk offenzivába, szokás szerint de: Én pl. nem ismerem a Mongodbt-t, amikor megmutatták, pont ez a "documents"-ekben lehetséges  komplex adattárolást elnézve lettek kétségeim. (ad hoc  strukturálatlan adatok)
Most nem a 24000 kiszolgálás/másodperc 10 000 ügyfélnek a weben-re gondolok, hanem kifejeztten és csakis  ügyviteli rendszerekre, ERP -re. Itt ugye az adatbázist az üzleti folyamatok alapján elkészítik. Ha módositás kell, akkor az általában az adtbázisban történik , a programok ezek kiszolgálói. Sok nagy erp adatbázisa túléli a programváltásokat is. SQL adatbázis marad, többi változik.

Nosql-nél pl. az üzleti logikát  be kell vésned a programokba. És hát lesz módositás , bővítés. Szóval ami előnynek jellemeznek, azt   ügyviteli rendszereknél  nem látom előnyösnek. 

Vagy én gondolom rosszul ? Van ERP nosql  alapokon ? 
 

https://blog.claryel.hu

Ne ess abba a hibába, hogy a NoSQL = MongoDB vagy abba, hogy a NoSQL szükségszerűen document-oriented. A mindenféle hype elvitte a fókuszt, de a NoSQL alapvetően non-relational database, lehet graph database, lehet key-value database, lehet document-oriented database, lehet wide-column database, lehet in-memory database, és még sok egyéb.

Általában az van, hogy egy komplexebb rendszer igényeit nem lehet lefedni egyetlen technológiával, ilyenkor jön az, hogy bizonyos dolgok RDBMS alapon vannak, bizonyos dolgok meg olyan adatbázisban, ami az adat természetének sokkal jobban megfelel. Nyilván lehet szopni azzal, hogy gráfban könnyen ábrázolható adatokat document-oriented adatbázisban tárol az ember vagy a wide-column adatokat megpróbálja key-value alapon tárolni, csak a szopás ilyenkor garantált.

Vagy én gondolom rosszul ? Van ERP nosql  alapokon ? 

Elvileg semmi akadálya, hogy egy ERP lényegi része NoSQL adatbázison legyen, ha az adatok természete azt kívánja, de érzésre az ERP adatok természete nem olyan.

https://iotguru.cloud

akkor mi egy parhuzamos univerzumban elunk,mert nem igaz amit irsz, de Franko le is irta. Distributed sql-re meg renegeteg pelda van, nem is ertem hogy jelentheted ki ilyen hatarozottan hogy nincs distributed sql..ahogy Franko irta..."ez bullshit" :D

de akkor okulj kicsit: https://en.wikipedia.org/wiki/Distributed_SQL

es akkor meg arrol nem is beszeltunk hogy van egy csomo olyan "adatbazis" ami specialisan tarol distributed adatot, de sql-el kerdezed le. Mert eleg szabadon kezled az SQL fogalmat, ami szamomra egy nyelv es nem az RDBMS-t jelenti. Nem tudom milyen rendszerekkel dolgozol, de ketlem hogy sok distributed rendszert lattal volna.

Ehhez adalék az olyan PostgreSQL wire kompatiblis distributed SQL DBMS-ek, mint a CockroachDB (https://www.cockroachlabs.com/) vagy a YugabyteDB (https://yugabyte.com). Utóbbi ráadásul a Postgres natív frontendjét használja, a backendre gyógyították rá a saját distributed motorjukat.

Ugyanez MySQL / MariaDB fanoknak, ráadásul CNCF projektként: https://vitess.io/

 

Nyilván egy distributed SQL DB-be nem ugyanazt a sémát kell belerakni, mint egy sima DB-be, ezt is tudni kell használni, megvan, hogy mire jó és mire nem ... stb. stb.

Meg az hogy "SQL" adatbazis az elegge tag fogalom. Kb millio backend van, akar distributed is amit sql nyelven lehet lekerdezni. Az hogy milyen modon taroljak az adatokat meg kb. lenyegtelen amig megfelel a felhsznalasnak es van aki uzemeltesse. Pl. ugye az elasticsearch-nek is van sql lekerdezes lehetosege, hogy a sok data analyst aki powerbi-on nott fel ne zavarodjon ossze a json-os lekerdezo nyelvtol :D

Distributed SQL-t nem tudsz csinalni, mert vagy a lock-ok propagalasa a tobbi szerverre prohibitiv idot lesz igenybe, vagy ha ezt nem teszed, a szejjelszabdalt adatmodell + auto-id allocation miatt commit kozbeni utkozesek gyakorisaga lesz prohibitiv nagy load alatt.

Ezt a ChatGPT mondta neked?

replikalni kell minden tranzakcional a tobbi szerverre, az minden lesz, csak gyors nem.

Itt jön be a kérdés, hogy erre vajon mindig szükség van-e.

de a document store atomic update-t garantal document szinten.

Csak aztán rá ne jöjj, hogy az egyes dokumentumaid relációban állnak egymással ;)

- Szeretnék megtanulni biciklizni, hogyan álljak neki?
- Tanulj inkább vezetni, a bicikli egy elavult szar.

Szerintem nagyon-nagyon leegyszerűsítve van olyan feladat, amihez a modern nosql-féle megközelítés jobb, meg van, amelyikhez a relational. Remélem, ezzel most senkinek nem mondtam újat. :)

- minek tanulnal barmit is a biciklizesen kivul, hiszen az mindenre jo, es mar ismered az osszes nyugjet

tapasztalatom 6-8 ev nosql production-ben hasznalata utan: a dev-ek 95%-a mereven elzarkozik mindentol, ami nem sql. Mindenben sql-t lat, es a schema/normalizalas/tabla/join/id/... -ba szukult agyaval keptelen es nem is akar mas megkozelitest tanulni.

Ha bekerul egy nosql team-be, huzza a szajat, hogy fura, nem erti, tanulni kell, mi ez mar, ki talalta ki ezt a sz**t, miert nem sql, sql-ben minden egyszerubb/jobb, ...

 

keseru tapasztalat. sajnos keves, nagyon keves ember van, aki nyitott, kepes es akar fejlodni. a 95% csak nyugit akar es fizetest, semmi se valtozzon, az kenyelmes, nem kell erolkodni.

Ilyenek az emberek.

tapasztalatom 6-8 ev nosql production-ben hasznalata utan: a dev-ek 95%-a mereven elzarkozik mindentol, ami nem sql.

Nem lehet, hogy ugyanolyan faszul adod elő, mint itt? Mert akkor nem csodálom.

Mindenben sql-t lat, es a schema/normalizalas/tabla/join/id/... -ba szukult agyaval keptelen es nem is akar mas megkozelitest tanulni.

Baszki, te mindenhol MongoDB-t látsz... :D

Ilyenek az emberek.

Ilyenek, bizony, sajnos kevés, nagyon kevés ember van, aki nyitott, képes es akar fejlődni, ehelyett nyomja a faszságokat a MongoDB-ről.

https://iotguru.cloud

ezt a 6-8 ev nosql-t nem ertem, mert akkor mar csak latott volna a csavo egy ElasticSearch-ot is nem? :D

a fejlesztok blame-elesenel nagyobb faszsagot meg nem is tudok kitalalni. Akit en ismerek fejlesztot az mindennel is szeret gdolgozni. Csak kodolhasson  :D

( Qury v | 2023. 03. 11., szo – 00:21 )

1. korben tanuld meg az SQL alapokat. Inkabb sqlite, mysql, mariadb.dokumentaciokbol, az a nagy altalanossagban ugyan az. 0. korben tanulj angolul.

Support Slackware: https://paypal.me/volkerdi

( solt87 | 2023. 03. 11., szo – 11:24 )

Nem tudom, mennyire felel meg az igényeidnek, és hogy elérhető-e még, de ez a könyv foglalkozik PostgreSQL-lel is.

Hát, átfutva a tartalomjegyzéket és néha beleolvasva, ennek kb. a fele mára már elavult... sőt, szerintem sajnos már '94-ben is elavult volt egy része, gyönyörűek az olyan mondatok, mint például "a mai adatbáziskezelő rendszerek többsége COBOL-szinten szemléli az adatbázist".

https://iotguru.cloud

Azt elismerem, hogy egy 2006-os PostgreSQL könyv elavult, mert ki tudja mi minden került bele a szoftverbe azóta a sok-sok verzióváltás során. Például Obádovics 2001-es valség könyvéről ezt nem mondanám; mert amit akkor leírtak, az szerintem még mindig igaz, s ezt szinte az összes matematika könyvre el lehetne mondani. Az elméleti számítástudományról nem szokás így gondolkodni, mert az informatika folyton fejlődik. A technológiák valószínűleg igen, de az elmélet nem. A korábbi algoritmusokat nem dobjuk ki, esetleg kiegészítjük. A hetvenes évek objektumorientált elképzelései óta túl sok újítás nem jelent meg a programozási nyelvekben, noha újabb meg újabb nyelvek szinte naponta jelennek meg. A relációs adatbáziskezelők elmélete sem sokat változott az elmúlt ötven évben. Halassy könyve ezt ismerteti, illetve módszertant, sőt még inkább szemléletet ad hozzá. Bármilyen hihetetlen, ahogy a rendszergazdaság vagy a programozás vagy épp a villanyszerelés, úgy az adatbázisok megtervezése, illetve a későbbiekben azok üzemeltetése is egy szakma. Lehet kontárként is csinálni, de ne csodálkozzunk, ha lassú, nehezen továbbfejleszthető termék kerül ki a kezük alól. A könyv ez ellen próbál tenni a saját eszközeivel. 

A könyv jó, de nem az "első könyvem az adatbázisokról". Az SQL szó egyszer fordul elő a könyvben, míg egy kezdő rendszerint SQL lekérdezésekkel indul el már meglévő adatbázisokat használva. (Nagyjából ilyesmi szokott előfordulni alkalmazói versenyeken vagy éppen érettségin is.) Aztán megtanulja, hogy hozhat létre táblákat, azokat hogyan kötheti össze, de hogy adott feladat megoldásához milyen táblákat kell létrehoznia, azoknak mit kell tartalmaznia, de hogy azok időálló adatbázist alkossanak és ne csesszük el sokak idejét egy újratervezést követő migrációval, azt még az egyetemi oktatásban sem igazán fogják fel a diákok. 

Sajnos itt sincs királyi út. Mire megjelenik egy magyar nyelvű könyv, ami leír egy programot, az a program elavul. Érdemes angolul megtanulni, mert különben csak távolról tudjuk követni az aktuális technológiákat. Miután az SQL egy közös nyelvnek tekinthető az adatbázis-kezelőknél, szinte bármelyik gyakorlati irányú egyetemi jegyzettel el lehet indulni, s szükség szerint az angol nyelvű PostgreSQL könyvek/jegyzetek szövegét gépi fordítással talán meg lehet érteni. A megfelelő gyakorlat megszerzése után viszont már érdemes beleolvasni ebbe a könyvbe. 

AL

Ezzel most hosszan írtál keveset. Egy olyan könyvről beszélünk, amelyik például nem ismeri a NULL fogalmát, csak körülírja többféleképpen is. Nem fogom elolvasni végig, átpörgettem, de szerintem ez tényleg már akkor elavult volt minden szempontból, amikor kiadásra került. Ha úgy érzed, hogy a mai világban ebből a könyvből meg lehet tanulni értelmesen használni adatbázis kezelőt és van haszna, akkor a te tudásod is már elavult.

https://iotguru.cloud

Szerintem ez nem a 90 -es évek közepén íródott, hanem 10-20 évvel korábban (dbase stb) . Az adatmodellezés , normalizálás ugyanaz maradt, az érvényes. 

Mondjuk rendszerszervezővel se sűrűn  találkozni, itt ott  bankok-nál, multiknál talán.

https://blog.claryel.hu

Az adatmodellezés , normalizálás ugyanaz maradt, az érvényes. 

Szerintem tipikusan ezek változtak a legtöbbet, a normalizálás helyett manapság inkább duplikált adatok vannak, főleg NoSQL adatbázisoknál, illetve vannak olyan esetek, amikor update helyett insert van és olcsóbb az utolsó insert értékét visszaolvasni, mint az update és/vagy tranzakció költségét kifizetni. Ezek mind gyökeresen más adatmodellezést és normalizálást igényelnek...

https://iotguru.cloud

Nem univerzálisak az igények. Az SQL és a NoSQL adatbázisoknak más a célja, más a dologra optimalizálnak, és emiatt nagyon jól elférnek egymás mellett. Egy valamire való cégnél meg is található mindkettő. Sőt vannak további megoldások is, amiért egyesek hajlandók nagyon jól fizetni (pl. kx.com).

Az, hogy volt egy fellángolás a NoSQL esetén, aztán szép lassan megtalálta a saját helyét; az nem annulálja a relációs adatbázisokat, s az ott felhalmozott elméleti tudást. Az jó kérdés, hogy milyen elméleti hátteret lehet a NoSQL mögé berakni.

AL

Az, hogy volt egy fellángolás a NoSQL esetén, aztán szép lassan megtalálta a saját helyét; az nem annulálja a relációs adatbázisokat, s az ott felhalmozott elméleti tudást.

Senki sehol nem mondta, hogy a NoSQL majd lenyomja az SQL-t. A NoSQL egy (alapvetően non-relational) adattárolási paradigma, amit lehet művelni RDBMS rendszereknél is bizonyos körülmények között. Nyilván nem így hívták eleinte, mert SQL se volt akkoriban, de már több mint 60 éve velünk van. Akinél ez úgy csapódott le, hogy majd a NoSQL lenyomja az SQL-t, az nem sokat értett meg az egészből.

Az jó kérdés, hogy milyen elméleti hátteret lehet a NoSQL mögé berakni.

Szerintem olvass utána... jelenleg nagyobb irodalma van, mint a relational adattárolásnak, ami egy kicsi szelete az adattárolási lehetőségeknek.

https://iotguru.cloud

"a normalizálás helyett manapság inkább duplikált adatok vannak, főleg NoSQL adatbázisoknál,"

A kérdező RDBMS felé indulna, én ezért azt javasolnám, hogy első körben ismerje meg az OLTP "felhasználást" és működést, a normalizálással együtt, és ha ez megy, csak akkor kezdje az ismerkedést a denormalizálással meg az OLAP jellegű felhasználással. A NoSQL az meg egy totálisan más "állatfaj", nem keverném ide.
 

A normalizálás vagy denormalizálás kérdésköre nem OLTP vs OLAP kérdéskör, mert lehet mind a kettő normalizált vagy denormalizált, illetve van élet az OLTP és OLAP világon kívül is, lásd ODS vagy OPAP vagy bármi egyéb használatú adatbázis.

A NoSQL az meg egy totálisan más "állatfaj", nem keverném ide.

Bármelyik SQL tud működni NoSQL módon, ez nem állatfaj, nem is új állatfaj, mert kb. 60 éve létezik, csak nem így hívták... a NoSQL egy adattárolási metodológia, amiről egy szót nem szól a linkelt könyv, ahogy a CAP és ACID sincs benne értelmesen említve, hogy a tranzakciókról ne is beszéljünk. Rettentő sok alapdolog hiányzik abból a könyvből és rettentő sok elavult dologról ír terjengősen, mintha karakterre fizették volna.

https://iotguru.cloud

Ha egy OLTP DB-ben denormalizálásra van szükség (szándékosan nem azt írtam, hogy nincs rendesen normalizálva), akkor ott valami "sántít" - az ilyen eseteket az első insert/update/delete/select köröket futó kollégával még ne kezdjük el megcsócsáltatni - mert ha megtanulja, hogy hogy kell korrekten összerakni egy DB-nek a táblaszerkezetét, hogy "okos" struktúrát kelljen kezelni "buta" programmal, akkor még fog tudni a normalizálásból visszalépni, ha valamiért szükséges lesz.

Azzal a megjegyzéssel, hogy "A NoSQL az meg egy totálisan más "állatfaj"" csak azt akartam jelezni, hogy ne vigyük el abba az irányba szegényt, hiszen ő nem versenytáncos akar lenni, hanem most keresi a kályhát a tánciskolában...

Abban persze igazad van, hogy kritikus szemmel kell nézni a több évtizedes könyveket, mert az alapok is változtak azóta nem is kicsit, és való igaz,hogy egy sok évvel ezelőtti könyvből hiányoznak olyan ismeretek, amiket ma alapvetőnek tekintünk az adott témában. (Nekem mondjuk szerencsém volt, mert huszonx éve Oracle SQL PL/SQL tanfolyammal indítottam ezen a téren, és kifejezetten jó dokumentációból és oktatóktól tanulhattam.)

 

Ha egy OLTP DB-ben denormalizálásra van szükség

Nem sántít, egyszerűen vannak esetek, amikor jobb. Mert manapság storage van dögivel, memória és CPU meg nem annyira.

Abban persze igazad van, hogy kritikus szemmel kell nézni a több évtizedes könyveket, mert az alapok is változtak azóta nem is kicsit, és való igaz,hogy egy sok évvel ezelőtti könyvből hiányoznak olyan ismeretek, amiket ma alapvetőnek tekintünk az adott témában.

Elavult és hiányos.

https://iotguru.cloud

 

Azzal a megjegyzéssel, hogy "A NoSQL az meg egy totálisan más "állatfaj"" csak azt akartam jelezni, hogy ne vigyük el abba az irányba szegényt, hiszen ő nem versenytáncos akar lenni, hanem most keresi a kályhát a tánciskolában...

epp ezert kellene nosql. egy document storage _egyszeru_. nezz meg egy meteor peldaprogramot! nincs benne sql, ddl, tipusok, tranzakciok, tablak, normalizalas, semmi. komplett konyveket kihagyhatsz cakkunpakk es egy delutan alatt mar tolod is az adatokat egy olyan adatbazisba, amelyik skalazhato, HA es tud shardingot.

a sql alapvetoen egy iszonyu tulbonyolitott valami, ami manapsag nehezen eladhato komplexitas ahhoz kepest, amit ad erte cserebe.

persze ezt csak az tudja, aki tanult es dolgozott mar egy tisztesseges nosql-el, mert ugye ugy, hogy valaki 20 eve exkluziv sql-t tol, nem meglepo, hogy meg a szog is SELECT -bol van :/

nincs benne sql, ddl, tipusok, tranzakciok, tablak, normalizalas, semmi. komplett konyveket kihagyhatsz cakkunpakk es egy delutan alatt mar tolod is az adatokat egy olyan adatbazisba, amelyik skalazhato, HA es tud shardingot.

Nekem ebből úgy tűnik, hogy nálad a NoSQL = MongoDB. Van élet a MongoDB-n túl is és van élet a NoSQL világán kívül is. Amúgy keep up, ilyen helyekre szoktam járni helyre tenni a problémákat, amelyeket az okoz, hogy mindent is MongoDB-vel akarnak megoldani, aztán néznek, mint a kiszántott egér, amikor különféle megoldhatatlan problémáik vannak.

a sql alapvetoen egy iszonyu tulbonyolitott valami, ami manapsag nehezen eladhato komplexitas ahhoz kepest, amit ad erte cserebe.

Nézd, például a Spotify is használ RDBMS rendszereket, mert van egy csomó használati eset, amire sokkal jobb, mint más megoldás, szóval használnak ők mindent is: Cassandra, MongoDB, MariaDB, MySQL (!), PostgreSQL, FlockDB pár in-memory database, néhány graph-database... satöbbi. Nem a gombhoz veszik a kabátot, hanem a problémához keresik meg a legjobb eszközt.

https://iotguru.cloud

"Nem a gombhoz veszik a kabátot, hanem a problémához keresik meg a legjobb eszközt." - Talán ez a legfontosabb... Szerintem tudnánk napestig sorolni azokat az eseteket, ahol ezt a nagyon fontos dolgot ignorálták, mert csak sql-es ember volt/van, vagy mert "redissel nincs tapasztalat" (és a session adatokat a backend db-be tolják ezerrel...), vagy ami legjobban "tetszik", a "máskor is így csináltuk, és működik"...

Ezektől tudok heveny lábrázást kapni...

Jaaj, az a legjobb amikor van egy probléma, "meg vagyunk baszódva Béláim" szinten.

- Elastic-kal, redis-sel, kicsit átvariált architektúrával így-és-így oldanám meg.
- Mem, új "szoftver" nem lehet mert nem és nem.
- Na most akkor eddig akik csinálták (ti) hülyék voltak és nem értettek a postgreshez, vagy esetleg postgressel ezt nem lehet megcsinálni?
- Hümm.

Gábriel Ákos

persze ezt csak az tudja, aki tanult es dolgozott mar egy tisztesseges nosql-el, mert ugye ugy, hogy valaki 20 eve exkluziv sql-t tol, nem meglepo, hogy meg a szog is SELECT -bol van :/

hu de kemeny szavak ezek, kicsit nagy az a melleny :D

En dolgoztam/dolgozom rdbms adatbazisokkal ugy 1999 ota es ugy 2012 noSQL-es dolgokkal is.  Kb, azt tanultam meg ennyi ido alatt hogy mindegyik jo valamire es hogy helyesen valasszak a technologia es penzugyi igenyeknek megfeleloen. De en csak egy hulye vagyok nem nosql evangelista :D

Azt hiszem értem mit akarsz mondani, de nem azt mondod :)
Szerintem nem az SQL a túlbonyolított valami hanem az objektum perzisztálás, az ORM.

Azt gondolom hogy az SQL és az OOP "házasítása" nem sikerült igazán jól, nem is sikerülhetett hiszen van a két technológia között vagy két évtized.

Ebben az értelemben a NoSQL motyók egy része sokkal jobb API-kat ad(hat) és megcsinálja az object storage-t és/vagy document storage-t.
Persze olyan irgalmatlan nagy csodák nincsenek, valahogy "az összes bitnek le kell kerülnie diszkre", egyszerűen másik méreteknél jön el "az igazság pillanata".

Aki sose ér el ezekig a méretekig (vagy komplexitásig) annak a NoSQL "végtelen jó".

Gábriel Ákos

( FeriX v | 2023. 03. 11., szo – 19:37 )

Szia.

Ha kezdő lennék a mostani világban, és SQL-t szeretnék tanulni, nem az ágyúval (PostgreSQL) lőnék verébre. Könyvet pedig nem keresnék, főleg nem magyar nyelven.

Ha nem vagy egy olyan projektben vagy ahol fürtökben lógnak a PostgreSQL adatbázisok, vagy mondjuk nem léed túl a 8000 cikk napai adatforgalmát, 6.5 milliós egyéni napi forgalmat 200 alkalmazottal, akkor javasolnám hogy SQLite-al kezd. Félreértés ne essék, a végcél lehet a PostgreSQL, de kezdésnek fölösleges feltelepíteni tárolni csomó fájlt a gépeden, csak azért, hogy végre lefuttathass egy SQL parancsot. Az SQLite adatbázis egy üres fájl, "AzÉnElsőAdatbázisom.sqlite" vagy .db kiterjesztés, de mindegy. A teszteléshez, fejlesztéshez, ajánlom a https://antares-sql.app/ ingyenes, nyílt forrás, multiplatform, fejlesztésre optimalizálva. Nekem bejött, de ahány ember…

Ha ragaszkodsz a könyvírók vagy online oktatók saját szemléletéhez, és hogy azon keresztül miként oldják meg a feladatot, amit szeretnének megtanultatni Veled, hát sok szerencsét kívánok. Létezik a mai világban egy igen szuper online segítség, ezt csúnyán lebutítottam, mindenhez "is" értő mesterséges intelligencia, ami a legjobb arra hogy SQL-t "is" tanulj. https://chat.openai.com/chat

Bátran lehet tőle kérdezni, de a társalgás előtt köszönés után, (illedelmes egyébként) konkretizálni kell az aktuális beszélgetés tárgyát. Mint normál esetben ember és ember között. Példa a beszélgetésből rád szabva az én logikám szerint és a tapasztalatom, hogyan kell kérdezni ettől az MI-től, de ezeket a kérdéseket a Te elméleted szerint tedd fel:

A példák előtt még annyit hogy ezek a kérdések, az egyszerűbbek közé tartoznak. Bár nem vagyok jós, de nem fogsz csalódni a komplexebb SQL kérdésekkel kapcsolatban sem. Vagy "Milyen adattípusokban tér el a PostgreSQL, MySQL és SQLite?"

Én ezt az irányt ajánlom tanulásra.

 

------

Megjegyzés: Érdemes elmenteni a válaszokat egy jól indexelt, és gyors és komplex kereséssel ellátott adatbázisba. :) Én erre a gmail-t és a címkéit használom.

------

Én: Szia, PostgreSQL és SQL kérdésem lenne.

Ő: Szia! Miben segíthetek a PostgreSQL és SQL kérdéseiddel kapcsolatban?

Én: Megmutatnád egy egyszerű példával, magyar nyelvű adatokkal hogyan kell létrehozni egy táblát?

Ő: Természetesen! Itt van egy példa, hogyan hozzunk létre egy egyszerű táblát PostgreSQL segítségével, magyar nyelvű adatokkal:

Tegyük fel, hogy egy egyszerű növényadatbázist szeretnénk létrehozni. A táblánk neve "növények" lesz, és az adatok az alábbi mezőket tartalmazzák:

Növény neve
Termés mennyisége
Termés egysége
Ez lenne a SQL kód, amit futtatnunk kell a tábla létrehozásához:

CREATE TABLE növények (
    neve VARCHAR(50) NOT NULL,
    termés_mennyisége INTEGER,
    termés_egysége VARCHAR(20),
    PRIMARY KEY (neve)
);

Ez a kód létrehozza a "növények" nevű táblát a megadott mezőkkel. Az első mező, "neve", egy karakterlánc, amely legfeljebb 50 karakter hosszú lehet, és nem lehet üres. A második mező, "termés_mennyisége", egy egész szám, és a harmadik mező, "termés_egysége", egy karakterlánc, amely legfeljebb 20 karakter hosszú lehet. Az utolsó sor az első mezőt jelöli elsődleges kulcsként, ami azt jelenti, hogy az adatokat ezen mező alapján rendezzük és keresünk a táblában.

Remélem, segített ez a példa a PostgreSQL tábla létrehozásában! Ha további kérdéseid lennének, ne habozz megkérdezni!

Én: És hogyan kell feltülteni a növények nevű táblát adatokkal?

Ő: Az adatok feltöltése a PostgreSQL-ben az INSERT parancs segítségével történik. A következőképpen adhatjuk hozzá a növények táblához az adatokat:

INSERT INTO növények (neve, termés_mennyisége, termés_egysége)
VALUES ('Paradicsom', 100, 'kg'),
       ('Répa', 50, 'kg'),
       ('Uborka', 75, 'kg');

Ez az SQL utasítás azt mondja a PostgreSQL-nek, hogy adjon hozzá három sort a növények táblához. Az első sor az adatokat tartalmazza a Paradicsom nevű növényről, amelynek a termés mennyisége 100 kg, és az egysége kg. A második és harmadik sorban az adatok a Répa és az Uborka nevű növényekről szólnak.

A VALUES kulcsszó után zárójelbe kerülnek a mezők értékei. Fontos, hogy az adatok sorrendje megegyezzen a mezők sorrendjével, amelyeket a táblában létrehoztunk.

Remélem, ez segített a növények táblához adatok hozzáadásában. Ha bármilyen további kérdésed van, ne habozz megkérdezni!

------

Néhány gondolat és válasz az OpenAI-tól a mai napra:

Én: Szia megint, a növények táblából hogy tudom lekérdezni hogy mennyi volt az összes termésem?

Ő: Szia!

Ahhoz, hogy megtudjuk, mennyi volt az összes termésem, először ki kell számolnunk minden növény összes termését, majd ezeket össze kell adnunk. Az összes termést egy SUM függvénnyel tudjuk kiszámolni, ami összegezni fogja az összes termést a "növények" táblában.

Az SQL lekérdezés a következőképpen néz ki:

SELECT SUM(termés) as összes_termés FROM növények;

Ez az SQL kód összegezni fogja az összes "termés" értéket a "növények" táblában, majd az "összes_termés" nevet fogja adni az eredmény oszlopnak.

Remélem, segítettem! Ha van bármilyen további kérdésed, ne habozz megkérdezni!
 

Én: És ha csak bizonyos termések mennyiségére vagyok kiváncsi?

Ő: Ha csak bizonyos növények termésére vagy kíváncsi, akkor a WHERE feltételt használhatod a lekérdezésben, hogy korlátozd a lekérdezés eredményeit azokra a növényekre, amelyekre vonatkozik a kérdésed. Az SQL kód így fog kinézni:

SELECT SUM(termés) as összes_termés FROM növények WHERE neve = 'Növény1' OR neve = 'Növény2';

Ez az SQL kód össze fogja adni a "Növény1" és "Növény2" nevű növények terméseit a "növények" táblából, majd az "összes_termés" nevet fogja adni az eredmény oszlopnak.

Természetesen a WHERE feltételt testre szabhatod a saját igényeid szerint, hogy a megfelelő növényeket kérdezd le az adatbázisból. Például, ha csak azokra a növényekre vagy kíváncsi, amelyek a "Föld" helyett az "Üvegház" körülmények között nőttek, akkor az SQL kód a következőképpen fog kinézni:

SELECT SUM(termés) as összes_termés FROM növények WHERE feltételek;

Ahol a "feltételek" helyére a saját feltételeidet írod, például:

SELECT SUM(termés) as összes_termés FROM növények WHERE körülmények = 'Üvegház' AND évszak = 'Tavasz' AND termesztő = 'XY';

Remélem, segítettem! Ha van bármilyen további kérdésed, ne habozz megkérdezni!

Én: A "körülmények" oszlopot nem találom a tegnapi példában, ezt hogyan kell hozzáadni a táblához és feltölteni utólag adatokkal?

Ő: Elnézést, valóban nem volt a tegnapi példában a "körülmények" oszlop. Az új oszlop hozzáadásához a következő SQL parancsot kell használnod:

ALTER TABLE növények ADD körülmények varchar(255);

Ez a parancs hozzáad egy új "körülmények" nevű oszlopot a "növények" táblához, amely varchar(255) típusú.

Az utólagos feltöltéshez használhatod a következő SQL kódot:

UPDATE növények SET körülmények = 'Föld' WHERE neve = 'Növény1';
UPDATE növények SET körülmények = 'Üvegház' WHERE neve = 'Növény2';

Ez az SQL kód frissíteni fogja az "Növény1" és "Növény2" nevű növények "körülmények" oszlopát a megfelelő értékekre.

Természetesen, ha több növény van a táblában, akkor az SQL kód további frissítéseket tartalmazhat, amelyek az összes növény "körülmények" oszlopát frissítik a megfelelő értékre.

Remélem, segítettem! Ha van bármilyen további kérdésed, ne habozz megkérdezni!

Ez szerintem egy nagyon jó javaslat. A Sqlite egy szuper eszköz, nagyon könnyű használni, jól dokumentált, kb. minden nyelvhez van hozzá binding ... stb. És nem "csak" tanulásra jó, mobilappokban gyakran ezt szoktuk használni, Androidnak és iOS-nek is a része.

Lett volna több opció bőven, az SQLite pont döcög, szar, nehézkes, lassú, korlátolt, satöbbi, szóval nagyon sok Android alkalmazás nem használta, hanem behúzott maga alá egy sokkal gyorsabb adatbázis réteget vagy egyszerűen fájl alapon tárolt adatokat.

Amúgy a legtöbb kritikus belső adattárolásnál már rég kidobták, mert lassú és nehézkes, energiazabáló, ami rontja a felhasználói élményt, csak meghagyták ugyanazt a criteria API-t a lekérdezéshez a content provider-en keresztül...

https://iotguru.cloud

Ebből a "több opció"-ból kértem, hogy nevezz meg néhányat... Az "egyszerűen fájl alapon tárolt adatokat" az is megoldás lehet, ahol nem kell a faék egyszerűnél bonyolultabb adatszerkezetekkel dolgozni. Egy  szimpla név-érték párosokat tartalmazó adathalmaz valóban egyszerűbb fájl alapon, de vannak azért ennél bonyolultabb adatkupacok, amiket tárolni szokás...

"már rég kidobták" - mennyire rég? Arra kérdeztem rá, hogy amikor indult a dolog, akkor mi lett volna alkalmasabb. Azt én is tudom, hogy azóta "bármi is" elfutkározik azokon a hardvereken, amik manapság Android alá kerülnek...

Ebből a "több opció"-ból kértem, hogy nevezz meg néhányat...

Elég sok embedded DB volt már akkor is, ami jobb lett volna, nem mindegyik tud annyit, mint az SQLite, de nem is kellett volna annyit tudnia. Azért nem kerültek kiválasztásra, mert nem volt pure Java implementációjuk, az SQLite-nak pedig volt. Nem az volt a kiválasztási szempont, hogy az adott feladatra jobb-e, hanem az, hogy bele lehet-e tenni gyorsan. És sok egyéb modul pont így került bele az Android-ba.

Amúgy sok alkalmazás máig BerkeleyDB-t használ, vagy más key-value adatbázist, amiben lehet index alapján nem csak a kulcs alapján keresni. Felmerült az Apache Derby, mert ez elsődlegesen Java, vannak alkalmazások bőven, amelyek szinte rögtön áttértek erre, mert full SQL92 support van benne, nem pedig partial SQL92, mint az SQLite-ban, de ennek jóval nehezebb lett volna az integrálása. Felmerült a H2 is, ezt is szokták használni, ennek is integrálási problémái voltak.

Röviden: az SQLite időhiány miatt került bele, gyorsan ki kellett adni... nem azért került bele, mert már akkor is ideális választás volt a feladatra.

Arra kérdeztem rá, hogy amikor indult a dolog, akkor mi lett volna alkalmasabb.  Azt én is tudom, hogy azóta "bármi is" elfutkározik azokon a hardvereken, amik manapság Android alá kerülnek...

Nem azért dobták ki, mert bármi is elfutkározik már a mai hardveren, hanem azért, mert még a mai hardvereken is lassú és limitált.

https://iotguru.cloud

Arra kérdeztem rá, hogy amikor indult a dolog, akkor mi lett volna alkalmasabb.

De ez miért érdekes? 10+ főverzió megjelent azóta mind iOS-ből, mind Androidból. Nekem is rengeteg projektem van, amit manapság már teljesen máshogy csinálnék, még ha akkoriban jó ötletnek is tűnt. Ahol megérte, ott meg is történt az upgrade.

Lett volna több opció bőven

Ha valaki ilyen nagy tudással rendelkezik mint Te, sorolj fel a "bőven"-ből 5-öt, de mindenféle mellébeszélés és hosszas magyarázkodás nélkül, ami gyorsabb és jobb volt 15 év ARM-ra a C-nél. 

az SQLite pont döcög, szar, nehézkes, lassú, korlátolt, satöbbi

Kiváncsi lennék azokra a bencmarkokra amiket csináltál, összehasonlításként más, nem döcögő, nem szar, nem nehézkes, nem lassú, nem korlátozott satöbbi adatbázisokkal. Azok csak számok egy táblázatban, a feliratokat nyugodtan cseréld le, könnyű ide beszúrni. De nem kell a magyarázkodó jól megmondom, mert az amit mondok az az igaz sallang.

szóval nagyon sok Android alkalmazás nem használta, hanem behúzott maga alá egy sokkal gyorsabb adatbázis réteget

Mindig csak a mások és mások. Meg az a sok fránya lett volna több opció. Na de a saját életedből mi a példa a sok opcióra? Felsorolnád? Mert a beszélgetésed csak ilyen "jól megmondom", de nem igazán tartalmaz konkrétumokat.

( andrej_ v | 2023. 03. 11., szo – 19:45 )

Nekünk anno ez volt: https://www.regikonyvek.hu/kiadas/adatbazisok-lsi-oktatokozpont

Maga az elméleti adatbázis rész elég jó benne szerintem, és eléggé elvonatkoztatva van talán.

Ahogy előttem írták elsőre az átfogó elmélet a fontos, hogy mégis lásd a koncepciót, és nagyjából rendes sémát rakj alá össze. Ha ez megvan, akkor lehet az ízlés szerinti konkrét adatbázis kezelőbe belemerülni. A helyzet ugyanis az, hogy mindengyiknél "minden" másképp lesz. Adattípusokban, optimalizációkban, a query plannerben, meg eleve az szintaxisban (a nem pont SQL szabvány kiterjesztések, pluszok) lehet különbség. A külső kulcsok, triggerek és társaik kezeléséréről már ne is beszéljünk. A bónusz, hogy a mindenféle optimalizációs beállításban pláne eltérőek ezek. :)

Rögtön hozzáteszem, hogy kb. 20 éve volt a fenti, 15 éve kellett postgresql-eznem, azóta inkább MySQL/MariaDB vonallal találkozom. Sajnos alapvetőe kérdésekkel/problémákkal találnak meg, és fogom a fejem rendesen általában, pedig nem vagyok egy adatbázis/rdbms szakértő.

Többen írták az angolt. Nos ezzel nagyon meg kell barátkoznod, mert a számtek/info nyelve alapvetően az angol.

( ggallo | 2023. 03. 12., v – 09:42 )

Az informatika bármely területén való elinduláshoz elengedhetetlen az angol nyelv ismerete, legalább olvasási szinten. Én magam nem is értem, hogy ez hogyan kerülhet még  mindig elő, hogy bárki IT tudást magyarul keres, IT vonalon akar mozogni angol tudás nélkül...

A magyar egy kevesek által beszélt nyelv (világszinten), ráadásul nem az IT alapnyelve (nem magyarul születnek az új anyagok, amiket aztán másra kellene fordítani). Emiatt egy adott szakmában - jelen esetben az IT területem - még kevesebben beszélik. A magyar fordítás eléggé drága dolog erre a nagyon szűk piacra, így nem készül el nagyjábül semmi szakirodalomból. Pláne nem olyan ütemben, ahogy az IT szakma változik-fejlődik. Mire egy könyv egy szoftverről megjelenik magyarul, már nemhogy az a verzió, de lehet maga a szoftver sem létezik. Emiatt bele sem fognak a magyar kiadásba, mert biztosan nem fog megtérülni. Ugyanis a szakemberek rég elolvasták angolul, aki meg csak magyarul olvasná mert nem megy az angol, az nem fog 20-30 ezret adni egy-egy szakkönyvért. Pláne úgy, hogy a neten ingyen elolvashatná, ha tudna angolul (és ez a tény erősen befolyásolja a vásárlási szándékot annak ellenére, hogy nem tudja angolul elolvasni).

Magyar nyelven a felsőoktatási jegyzetek némelyike jó (némelyike meg tele van hasznontalan és/vagy hülyeséggel), mert azok javarészt az elméleti alapokat tárgyalják, nagyjából bármilyen valódi rendszeren kipróbálható példákkal. Akit érdekel és tovább lépne az alapokról, az angolul kell olvassa a folytatást, ha valamire vinni akarja IT területen.

Ráadásul ha találsz is egy tuti könyvet magyarult pont arról ami érdekel, és még aktuális is (ilyen mondjuk nincs, de játsszunk el a gondolattal), akkor is az első 4-5 valódi parancs kiadása közben kapni fogsz egy hibaüzenetet, amire csak angolul találsz választ/megoldást a neten. Egy oldalról túl kevés magyarul tudóra jut túl sok rendszer, így bizonyos IT területekkel igen kevesen foglalkoznak a magyarul tudok közül, más oldalról a magyarok nem a tudásuk ingyenes megosztásról híresek, irtózat kevés ember oszt meg valódi tudást magyarul, magyaroknak (arányaiban), kurrens dolgokról.

Igen, erre gondoltam... MS SQL Server 2000, MS Access 2000, MySQL 5.0

Valójában az egyszerű alapok működni fognak az aktuális verziókban. De van sok dolog, ami rettentő sokat fejlődött és/vagy átalakult, így a régi verziókra vonatkozó írások már nem relevánsak. El lehet velük indulni, de olyan nagyon messzire (az aktuális  felsőoktatási jegyzeteknél messzebbre) nem visznek szerintem.

Bevallom, én nagyon örülnék, ha lenne kurrens, magyar nyelvű szakirodalom, folyamatosan frissülve. Rettentő szomorú vagyok, hogy nagyon kevés képzett IT szakember van, és azt látom, hogy az angoltudás hiánya okozza sokak "képzetlenségét", nem az IT-hoz szükséges képességeik vagy a (szakmai) szorgalmuk, érdeklődésük hiánya. Valahogy az angol tanulástól félnek (vagy kidobott időnek tartják?) sokan olyanok, akik akár a legmodernebb számítástechinkai trendek iránt viszont érdeklődnek. De amíg az aktuális tartalmú magyar nyelvű szakkönyvek elérhetősége nem oldódik meg (ilyen nem lesz szerintem soha), addig muszáj megtanulni angolul olvasni (meg aztán angolul írni, hogy hibánál tudjunk kérdezni a megfelelő helyen).

Egyetértek. Magyarra fordított kiadványok jelennek meg, de azokkal az a baj, hogy mire elkészülnek, megjelennek, addigra el is avult, mert addigra a tárgyalt szoftver, 2-4 főverzióval arrébb jár. Mondjuk SQL alapokhoz vannak magyar nyelvű könyvek, amikből az alapok alapjai megtanulhatók, azok nem változnak már, feltétlen Postgre se kell hozzá, jó bármilyen adabázis, ami tud SQL-ül, MS Access, LibreOffice Base, SQLite (ezek eddig tipikusan fent szoktak lenni az adott rendszeren máris), MariaDB, vagy amit akar a kérdező, persze lehet Postgre-vel is gyakorolni, de magának a kezdő anyagnak nem kell specifikusan feltétlen rámennie pont arra.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Egyetértek. Magyarra fordított kiadványok jelennek meg, de azokkal az a baj, hogy mire elkészülnek, megjelennek, addigra el is avult...

Kétszeresen téves állítás.

Magyar kiadványok legalább egy évtizede nem jelennek meg, ha pedig megjelennének, akkor az olyan alaptémák, mint ami a kérdezőt érdekelné kellően hosszan nem avulnának el.

Science for fun...

Nem téves az szimplán sem. Általában írtam. Ez az SQL-es téma azért speciális, mert ennek az alapjai nem változnak. De a Postgre már változhat, főleg az üzemeltetés (telepítés, konfig) része. Egyébként ugyanazt írjuk, én sem ajánlom, hogy valaki magyar anyagokra támaszkodjon. Ha valamire vinni akarja a témában, megtanul angolul (nem, nem kell felsőfok, meg társalgási, stb., elég ha csak érti a doksikat) és megtanul önálló lenne, utánamenni az infóknak, és nem megvárni, míg valaki magyarul meg könyv formájában belerágja a szájába. Főleg nagyon könnyű ez már ma, doksik, kézikönyvek mind kint vannak már online, ezen túlmenően pl. genesis library-vel szinte minden könyv letölthető már angolul, illetve a YouTube tele van ingyenes képzési videókkal, így már csak tényleg az nem tud valamit megtanulni, aki annyira lusta vagy élhetetlen.

Én már valami 7-8 éve a rendszereimet sem használom magyarul. Lokalizálatlan (US) beállításokkal, így nem kell várnom magyarításokra, fordításokra, nem kell nyelvi csomagokat lehúzogatnom. Korábban tipikus volt, hogy néhány szoftvernek az új verziójára várni kellett, mert csak lokalizálatlanul jött ki, és eltelt egy kis idő, mire a magyar verzió is tölthető lett. Rendszeren is felesleges a magyar nyelv, úgyis megszokásból, rutinból, reflexből használja az ember a rendszert, és nem olvasgat el elölről minden szót. Természetesen ez csak a nyelvi beállítások, attól még az UTF/Unicode tudja természetesen a magyar karaktereket, nyomdai jeleket, stb. megjeleníteni, meg magyar billentyűzetkiosztás is beállítható, szerkesztőrprogramokhoz magyar nyelvi támogatás, magyar helyesírási szótár is hozzáadható, ezek teljesen független dolgok az alkalmazások nyelvétől. Plusz így a félrefordítások, félig lefordított bénaságok is elkerülhetők.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( valek | 2023. 03. 12., v – 18:31 )

Ejha! Köszönöm a sok választ! Okulok!
Va

( NevemTeve | 2023. 03. 14., k – 07:40 )

Még az jutott eszembe, hogy vajon mennyit ment előre az adatbázisok világa azzal, hogy már nem az 'Xmldb', hanem a 'Jsondb' a mindenreválaszcsodaszer?

Ha végig nézek a csővezetéken a JSON szemével, a fájlrendszeren kisebb, kevesebb memóriát igényel a feldolgozása, a hálózaton kisebb adatforgalmat generál, és mire eljut mondjuk egy REST API-n keresztül a klienshez ezek a többlet igények sokat számítanak. A kliens oldalon is ugyan az a helyzet, mint a kiszolgáló oldalon. Kevesebb tárhely marad mondjuk a mobilon, több memóriát igényel az app amíg feldolgozza, ami az akkumulátor is megérez. Persze ha csak azt nézzük, hogy az XML cellákból ugyan olyan buta módszerrel vesszük ki az adatokat, mint a JSON-t.

Mert ugye az XML önmagában nem sokat ér, kell hozzá séma, ami leírja, hogy mi micsoda. Persze itt is látszik hogy mi micsoda, bool, date, string, stb, de modjuk az én szememnek jobb a JSON.

De biztos van más szemlélet is.

Kabáthoz a gombot... Szerintem nincs olyan, hogy a JSON vagy az XML a jobb vagy rosszabb. Hasonló a funkciójuk, de különböznek "képességekben", vannak előnyeik-hátrányaik.

A JSON önmagában még annyit sem ér, mint az XML, mert az XML-ben (ha normális), legalább kitalálható nagyjából, mi-mi akar lenni. A séma ismeretében meg minden egyértelmű. A JSON struktúrája meg a programban van kódolva, ergo a program releváns része kell a megértéséhez. XML-t szerintem könnyebb olyan projekteknél használni, amit nem egyetlen fejlesztő/cég visz, hanem többen építenek rá. Persze közzé lehet tenni a JSON struktúrához is valami leírást.

A programkód, fejlesztői leírás nélkül az XML-t szerintem könnyebb ellenőrizni a séma alapján, JSON esetében kb. annyi ellenőrizhető, hogy meg van-e minden nyitó zárójelnek a párja...

A hsz-em után jutott az is eszembe, hogy nem kell tömör JSON-ban gondolkozni, key-value párokat is lehet bele írni, és akkor sokkal jönnyebben értelmezhető a sémáját nem ismerő számára is. De úgy már messze nincs akkora méret beli előnye az XML-het képest (ha ez lenne a választási szempont).

A JSON ott nagyon jó, ahol az natív ábrázolási forma, mert könnyű vele dolgozni. Ahol nem az, ott pont ugyan annyi meló van vele (szerintem), mint az XML-lel.

A tömör meg a json eleve oxymoron, (a világ összes webes apija hangosan hahotázik)  :D Na jó, az xmlhez képest nem. Illetve szerintem az xml mérete sosem volt akkora hasfájás (bár egyébként a proper xml namespacelve az anyámat is, hát azért tud hosszú lenni), a json elterjedése mögött szerintem inkább az áll, hogy:

  • javascript, ott az van, jshuszároknak nyilván egyszerűbb, és hát szereti/nemszereti az IT jelentős része jelenleg javascript
  • az xmlt nagyon fos olvasni szemmel
  • az xml ökoszisztéma elég bonyolult a schémaval, xsd, xsltvel, wsdllel, namespacekkel, xpathtal, anyámmal, és ez a bonyolultság elég hamar előtüremkedik a toolingból, az "easy things easy" emiatt nem annyira megy jól
  • vagy hát legalábbis az indításnál elég lapos a tanulási görbe

Ehhez képest a json szög egyszerűen kezdődik bármi nyelven, kb egy darab load_json függvénnyel kapsz egy natív adatstruktúrát aztán hajrá.

Aztán persze kiderült, hogy jó-jó, de komplexebb eseteknél azért mégse olyan nagy marhaság az a sok lófasz az xml ökoszisztémában, van neki haszna.

Szóval -- és itt érünk el az eredeti kommentem kifejtéséhez -- szépen nőt hozzá mindenféle tooling. Szóval van hozzá schema (egyébként több is, de kb a fixen befutó) a json schema, amivel frankón le lehet írni az adaszerkezetet, van hozzá xpath / xslt szerű dolog több is, jq (ez talán az elterjedtebb), jmespath (ez meg a kulturáltabb, főleg ha kódolni szeretnél, usernek nem biztos), van jsonpath, sőt, emlékeim szerint az xpath is tud már jsont :). A SOAP helyett meg vannak a mindenféle api leírók, ezekből van vagy 4-5 elterjedtebb, a leginkább goto azért az openapi. Ezek mondjuk általában kicsit a dokumentáció irányából közelítenek inkább, de megvan hozzájuk a generáljunk hozzá szerver/kliens kód stubot tooling, megvannak a libek az introspectionhez, hogy kb lehessen a soaphoz hasonlóan használni, megvan az az irány is, ha tulajdonképpen inkább generálnád a saját kódodból / modelledből ezeket, ha nem schema first dolgozol. Van jsonlines, hogy legalább valamennyire streamelhető legyen, ilyesmi.

Szóval a fedés egyébként kb megvan. Cserébe igen, kicsit kuszább, helyenként nincs golden standard, a legtöbb cucc max draft állapotú rfc (dehát mit várunk a living standard html világában), helyenként kicsit savanykásabb. On the plus, nincs összegyógyulva, ha tényleg csak a faék kell, akkor használhatod csak a faéket. Eléggé ízlés / környezet függvénye.

És azért zárójelben azt még hozzátenném, hogy bár az xml egyik nagy előnye elvileg, hogy mindenhol van hozzá korrekt tooling, valamiért mégis az van, hogy olyat még sose láttam, hogy valaki string baszással rakott volna össze jsont, olyat viszont, amikor ezt tette valaki xmllel, olyat többször is. Olyan kis garázscégektől is, mint pl a juniper.

Az openapi alapvetően csak egy struktúra, hogy le lehessen írni egy egységes szerkezetben egy HTTP API schemáinak összességét. A konkrét adatok leírására annyira jsonschemát használ, hogy a specben is csak annyi van, hogy "kivéve ezt a három dolgot, ami nem úgy van, lásd a jsonschema specet".

Kizártnak tartom hogy valaha is beleütköztél volna az XML többlet-mérete miatti teljesítmény problémába.

Ha valaha is XML-el kapcsolatos teljesítmény problémát tapasztalhattál az a DOM parser (vs SAX parser) miatt sokkal valószínűbb.
JSON-t is lehet jól csinálni, XML-t is lehet szarul. A kulcs a dokumentáció és a (saját) szabályok betartása.

Gábriel Ákos

Még a SAX parser is brutál sokat pazarol. Például az összes attributum értéket és szöveget betölti egy objektumba, amit aztán kidob. Kellene egy olyan API, ami csak akkor tölti be ezeket, ha szükség van rájuk, alapból a "streamben hagyja". Például volt egy olyan feladat mostanában, hogy baromi nagy XML-ekben kellett keresnem egyetlen dolog előfordulását. Elvben nagyon közel kellene lenni a megoldásnak a grep sebességéhez, hiszen egyszer kell végigolvasni mindent. Amit csinálni kell vele, az mind cache-en belül megoldható, valami minimális állapotgép kell csak az XML entityk feloldásához. Ezzel szemben pörög a GC mint a ringlispil, mert az összes szöveget beteszi string objektumokba, ha kell ha nem. Létezik olyan XML API Java-hoz, amivel megoldható, hogy csak csak azt töltse be stringbe, amit valóban ki is akarok olvasni?

Ilyen esetben nem lehetne megoldani, hogy az XML-t előállító oldal szűrjön, és az XML-be csak a téged érdeklő adat kerüljön? Lehet még úgy is gyorsabb lehetne, ha több különböző tartalmú XML-t kérnél le, mint egy bazi nagyot, amit aztán fel kell dolgozni. Na persze ha a kiszolgáló oldal fekete doboz, akkor így járás esete, de ha nem...

Nyilván nem tudom pontosan mi volt a feladat és az egyéb lehetőségek, így nem ítélkezésként, csak érdekességként írom: én egyszer jártam úgy ügyfélnél (üzemeltetésben vagyok érdekelt), hogy a fejlesztő azt mondta, erősebb gép kell kliensnek, mert nagyon lassú a program a mostani gépeken (ügyviteli rendszer, nem atomhasadás-modellezés). Ilyen i3-i5 gépek voltak 8-16 GB memóriával, SSD-vel. Kicsit jobban megnéztem a kliens-szerver kommunikációt, milyen téren is kell erősebb gép, és kiderült, hogy a kliens progi "SELECT * FROM table;" kérésekkel betöltött minden számára szükséges táblát minden egyes kereséshez (olykor 6-8 komplett táblát, ami év vége felé már nem volt kicsi), és kliens oldalon, programból "végezte" a relációs adatbázis kezelést... Hát, ezért kellett volna erősebb kliens gép a program alá... Írtam egy ilyen több táblás riporthoz nekik egy SQL-t JOIN-okkal meg WHERE meg LIMIT varázsszavakkal, és azonos kimenetet produkáltam 0.15 mp-es futásidővel szerver oldalon, hogy az igazam bizonyítsam... Javasoltam, hogy talán ha az RDBMS csinálná ezt - mert főleg erre van, nem hálózati megosztásként funkcionálásra -, a kliens meg csak megjelenítené az eredményt (ahogy az normális helyen szokott lenni), akkor kenyérpirító is elég lenne képernyővel az user-nek.

Az esetemben logokat dolgoztam fel, adott volt az input. Nem volt kritikus a futásidő, csak zavart kicsit. Éppen annyi időt töltöttem vele, hogy kimértem hogyan viszonyul az XML parszolás a sima végigolvasáshoz és meglett a tipp, hogy a stringek létrehozása és a végén a GC-je viszi el az idő nagy részét. Úgy szoktam dolgozni, hogy az adatmennyiségek és a szükséges algoritmusok alapján megbecsülöm mennyi ideig kell valaminek tartani és ha nagyon nem olyan, akkor utánanézek. Ezért néztem ennek is utána. Tanulságos volt, de szerencsére nem kellett feltétlenül megoldanom a problémát. Létezik ilyen XML lib Java-ra egyébként, ami nem példányosít le minden egyes stringet amit ér feldolgozás közben?

Ezt mondjuk nem ertem. Mi az a jsondb meg az xmldb? Mert lehet hogy xml adatot kuldesz be a db-nek vagy json-t de az nem cml-ben vagy json-ben lesz tarolva. Ahogy az sql sem sima insertekkent lesz tarolva egy rdbms-ben. Akar timeseries-be is tolhatom a json workloadot, ettol meg az columnar storage-ban lesz tarolva (akar sql- insertet is tolhatok) es majd az engine megoldja hogy jsonkent, sql tablakent vagy akarmikent legyen tarolva vagy adja vissza.

Mi az hogy xmldb meg jsondb? Tudsz peldat dobni?

De ettol az adat nem lesz json vagy xml a storage backenden (ha csak valaki nem mazohista es/vagy teljesen orult). Azt meg korulbelul le lehet szarni hogy az engine-t mivel szolitod meg. Ha data analyst-nek is oda akarod adni akkor legyen SQL forntendje (ne basszunk mar ki a szegeny powerbi userrel :D), ha IT-snak akkor legyen JSON-os is (had automatizaljona csavokam). :D

De ettol az adat nem lesz json vagy xml a storage backenden

Kár megállni itt, valójában kvarkok és leptonok tárolják az adatot, vagy ha a tudomány talál kisebbeket, azok. Csak az nem mindegy, hogy ezekből mennyi kell az XML és mennyi a JSON tárolásához. Ezt nem lehet egy egyszerű kit izgat felkiáltással elintézni. Sajnos *izmus megfizetteti a többletköltség árát, mi a JSON vs. XML harcot illeti.

jo, ne vicceljuk mar el. en ugy ertettem, hogy az adat formatum a backend storage-ben szinte sosem clear text "insert into.." vagy json vagy xml, hanem valamilyen olyan datttarolasi frma ami a felhasznalaslnak megfelel es a legjobban tamogatja azt. Az engine meg felelos azert hogy ugy add hozza es vedd ki az adatot ahogy az neked legjobban tetszik, legyen az sql, json, xml vagy whatever. Igy azon is ertelmetlen vitatkozni hogy mennyi adat kell egy xml vagy sjon tarolasahoz, mivel az adat nem azokban lesz eltarolva. hanem peldaul columnar storage-ben, vagy innodb-ben, vagy akarmiben. Igy peladaul mondjuk elasticsearch-ben is hozzaadhatod az adatot JSON-kent, de az nem jsonkent lesz tarolva, hanem lucene indexenkent, aminek mar semmi koze magahoz a json formatumhoz. Es lehet hogy 2GB JSON tarolasa csak par szaz megabyte helyet foglal, mivel mondjuk nem indexelsz egy csomo mezot csak tarolod oket, stb, stb. Ugyanakkor lehet hogy 100KB sql adat is tobb megabyte-ra rughat pedig ott csak "insert into .." text-el tolod be az adatot es nem JSON-ben.

Megegyszer. Az adattarolas formatumanak a backend strorage-ban semmi koze ahhoz, hogy milzen formatumban toltad be az adatot es milyen formatumban veszed ki. Igy ertelmetlen arrol beszelni hogy egy CSV, egy JSON vagy egy XML foglal e tobbet. Ugyanazzal az adattartalommal mindegyik foglalhat akar ugyannyi teruletet is fuggetlenul a formatumtol. Nem file-okat tarolsz egy RDBMS vagy egy noSQL db-benhanem adatot!!!

Ez azért kemény válasz annak arányában, hogy teljesen jogos és igaz amit ír...

A JSON meg az XML adat _ábrázolási_ formátumok, nem adat _tárolási_ formátumok. Mind a kettő különböző rendszerek közötti adat cserét szolgál, nem az adat tárolását. Jellemzően csak adatátvitel során használatosak, sem a forrás sem a célállomáson nincs JSON meg XML (string) tárolva, csak adat van, az adott rendszer saját módján tárolva. Kvázi konténerek, amikbe bekerül, majd kikerül az adat.

Az adatbázis tárolja az adatot ahogy tudja, majd a kliens kérésére előállítja a JSON vagy XML formátumú adatcsomagot. Ez elkerül bárhogy a klienshez, aki a formátum ismeretében "kiveszi" az adatot a kapott csomagból és eltárolja egy számára könnyen feldolgozgható módon.

A méretük valóban különbözik és ez akár jelentős átvitt adatmennyiség különbséget is adhat. De pl. az XML a séma segítségével bárhol validálható út közben, ellenben a JSON-ról csak a kliens tudja megmondani, hogy jó-e tartalmilag... Ha meg az átvitt adat mennyiség ilyen kritikus, akkor az adott adatbázis-rendszer natív bináris formátumát használva (ha van ilyenje) még kevesebb lesz az átvitt adat valószínűleg, mint akár JSON formátumba öntve.

Pl. a JSON formátumban megkapott adatot nem string-ként teszel el és interpretálod minden egyes alkalommal amikor kell belőle valami mező, hanem egy objektumba töltöd be (a JSON string megy /dev/null-ba) és azt használod onnantól adatforrásnak a kliens appban. Aztán visszafelé az objektumból csinálsz string-et, amit átküldesz a csatornán az adatbázisnak...

Hát, ez egy nyilvános fórumon lévő nyilvános topik. Ha nem is kérdezék, véleménye attól még lehet, és semmi nem tiltja/akadályozza, hogy megossza ezt... Ráadásul a hozzászólásodból nem derül ki, hogy pontosan mire volt reakció, így az egészre (utolsó utáninak gondoltam volna a felkijáltójelek száma a probléma).

Az írásképről meg annyit, hogy én is rosszul vagyok a magyarul, de ékezet nélkül író, mondat tagolást nélkülöző vagy rosszul használó, stb. hozzászólásoktól, de én túllépek rajta. Ezt jelezni nem tesz hozzá érdemben a témához, és nagy valószínűséggel nem is fogja a másik írását megváltoztatni (sőt, itthon a "csakazértis" sokkal népszerűbb, mint a "tényleg, valóban").

Nem, nem kerdeztel.

De te reagaltal eloszor a hozzaszolasomra, mikozben en sem kerdeztelek. 

Ezek utan llbagatelizaltad a dolgot az adattarolshoz tartozo hozzaszolasommal kapcsolatban, hogy de valojaban atomi szinten taroljuk az adatokat. Ezzel tulajdonkeppen azt uzenve, hogy olyan hulye vagyok, hogy nem is ertem mi a kulonbseg a JSONdb es XMLdb kozott (ilyenek nincsnenek is). 

Erre reagaltam, hogy ne bagatelizaljuk el a dologt es leirtam hogy tok mindegy hogy json-be, xml-be, kiskutyaba szervezed az adatot, az az adattarolas szempontjabol lenyegtelen. 

Ezek utan meg jossz azzal, hogy mi a helyzet az en csaladomon belul. :D

Nice, de kb. mint fing a szelben. Mondjuk en voltam a hulye hogy megprobaltam elmagyarazni neked, akinek sem tudasa, sem affinitasa nincs a dolgok mikentjehez es nem is erdekel csak szeretsz faszsagokat bofogni bele mindenbe. :D

Ja most sem kerdeztel, de azetr elmondtam. :D

Érteni én sem értem, de minden trendi dologhoz lesznek lelkes emberek, akik vallássá fokozzák, és lesznek hiénák, akik meglátják ebben az üzleti lehetőséget, és előállnak olyanokkal, hogy "szóval van egy xml/json/whatnot" fájlod? A mi programunk mesterséges intelligenciával kitalálja belőle az adatszerkezetet, és te ott állsz megkönnyítve!"