DBMS contra táblázatkezelő - "megfelelés"

 ( sas | 2019. május 22., szerda - 18:27 )

Sziasztok, egy elméleti kérdésem van:

Közoktatási szempontból keletkezett. Azt kellene minél jobban megvilágítanom pár srácnak, hogy az adatbázis fogalmának ismeretével, bármilyen típusú, tehát például hierarchikus vagy relációs adatbázis használatával mi az, ami előny, mi az, amit például NEM tudnának hatékonyan megcsinálni (alapvető informatikai szint) egy akármilyen fejlett táblázatkezelő alkalmazással, de például egy hierarchikus vagy egy relációs adatbázissal igen?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szerintem elsősorban méret és sebességbeli (non-functional) különbségek vannak.
Tehát mondjuk egy 8millió soros táblába még be kéne tolni 100ezer sort.
Ezt egy RDBMS megeszi, az Excel meg hanyattesik.
A többfelhasználós működésről is lehet beszélni.

Mondjuk vicces, de a Google Sheet meg mindkettőt kibírná, már amennyire az "táblázatkezelő alkalmazás" a szó hagyományos értelmében.

--
Gábriel Ákos

igen, persze, ez világos, de igazából azt a minimumot kéne megmondanom ennek a pár srácnak, hogy egy egyszerű hétköznapi életben, tehát azért nem AKKORA NAGY adatoknál, hanem inkább szerkezetileg mi az, amit már egy táblázatkezelővel nem tudnának hatékonyan megcsinálni, de elméletileg valamilyen adatbázis-kezelés alapon már igen?

Szerintem nincs ilyen. Legalábbis olyan amit egy ötödikesnek érdemes lenne elmagyarázni.

--
Gábriel Ákos

Ekszhelben eleve 1M a max sor per worksheet.
(régiben meg 64k)

Talán olyan dolgokról beszélnék, hogy
1) jogosultságok
2) triggerek
3) kívánság szerinti lekérdezések SQL-lel
4) ugyanígy SQL-lel bizonyos sorokat törölni vagy update-elni (persze, lehet kézzel is excelben, csak egy sok tabos sok soros táblázatban kézzel kimazsolázni azért kicsit tovább tart).
5) tranzakciókezelés esetleg

szerk: az igazság az, nem tudom, hogy a VBA mit tud. Lehet, hogy lehet vele tárolt eljárásokat meg triggereket is építeni.

fú, köszi, de ezek még mindig nem azok a dolgok, amiket a fenti kommentben írok, hogy valamivel meg tudjam magyarázni egy "ötödikesnek", hogy na, ha az ilyen adataidat szeretnéd egy hatékony szerkezetben tárolni, arra már nem igazán lesz jó neked egy mezei táblázatkezelő alkalmazás... :)

Nézd, az excellel mindent meg lehet tenni, amit adatbáziskezelővel, csak vannak dolgok, amik sokkal lassabbak, és sokkal nagyobb az esélye, hogy kézzel elrontod.

Pl. a relációs adatbáziskezelő a nevét a táblák közötti relációkról kapta.

Primary key, foreign key...

Rendesen definiálod, a program biztosítja, hogy a primary key oszlopában ne lehessen ismétlődő érték, és ha akarod, törölheted, átírhatod, leválogathatod az adott kulcshoz tartozó dolgokat más táblákból is.
Excelben ugyanez egy csomó kézi kereséssel és kézi törléssel, átírással, adatok kigyűjtésével menne.

Megoldható, igen, de senki se állna hozzá szívesen.

Hogy a szokásos autós példánál maradjunk:
az ötödikes gyerek a haverjait egyenként is felviheti a hegyre talicskával, vagy megkérhet valakit, akinek van jogsija, és mindenkit egyszerre felvihet a hegyre, sokkal hamarabb, sokkal kevesebb fáradtsággal és sérüléssel.

Ha már ötödikes, akkor van egy órarendje. Nálunk az összes egyetemi előadásról, gyakorlatról van egy közös egy munkalapos táblázat tucatnyi oszloppal, ami jól kereshető, szűrhető, de az, hogy maga táblázat konzisztens (azaz nem raktak be valakinek ütköző órákat, egy terembe nem raktak be egyszerre két különböző órát), nem olyan egyszerű megvizsgálni.
A levelező képzés órarend-tervezőjébe 9 táblát kellett felhasználni, hogy ez pár SQL lekérdezéssel kiderüljön, illetve, hogy 5 ember párhuzamosan, egymást nem gátolva készíthesse az órarend rá vonatkozó részét.
Talán a 9 munkalap még megoldható (hogy minden tábla külön munkalapra kerüljön), a párhuzamosság desktop Excel-nél már kérdőjeles, de a konzisztencia - melybe beletartozik a fentebb említett primary és foreign key - igen körülményes.

Más. Pici (van ki e nevet nem ismeri?) azt mondta valaha, hogy az adatbáziskezelés egymillió rekordnál kezdődik. A táblázatkezelő pedig nem erre készült, bár nagy megkötésekkel lehet rá használni. Igaz hallottam olyan emberről is, aki az Excelt használja ERP helyett, és működik.

@AszaltSzilva, kösz, ez a konzisztencia-hangsúlyozás, ez már kezd egy jó irány lenni, sok viszonylag szabad formátumú adatnál már nem látod át, ha rosszul vetted fel őket az ellentmondásokból adódó hibákat, azt hiszem, ez már lehet az egyik jó érv az adatbázisok szemlélete tekintetében...

A relacios adatbaziskezelo a nevet nem a tablak kozotti relaciokrol kapta.
wikipedia

A nagyon gyakori felreertes oka a Codd modell nem feltetlenul szerencses terminologiajaban keresendo. A relacio itt nem kapcsolatkent (relationship) ertendo, hanem rendezett n-esek halmaza. Ha igazan szorszalhasogatoak vagyunk, akkor kiemelhetjuk, hogy Codd modell a eltekint a rendezettsegtol, a formalis matematikai definicioval szemben.

Ha mi is eltekintunk a fentebb hivatkozott elmeleti hattertol, a dolog hetkoznapi logikaval is atlathato:
- a relacios adatbazis tablak kapcsolata nelkul is relacios marad. Pl. egy onmagahoz logikailag nem kapcsolhato tabla relacios adatbaziskezeloben
- nem relacios adatmodellekben is leteznek kapcsolatok, sok esetben meg explicitebben reprezentalva. Pl: hierarhikus v graf alapu modellek

OK. Mindig tanul az ember.

Akkor a második mondat kivételével mondd a többit.

Adj nekik házit és megvilágosodnak. Adj egy 10.000.000 soros adathalmazt, mondjuk 64 mezővel. Rendezzék vagy bármi, mondjuk Excelben. Akinek sikerül, az ötössel vizsgázott, a többiek meg megvilágosodnak.

Redundancia, összefüggések kezelése... amikor van mondjuk egy iskola, benne diákok, minden diák tartozik egy osztályba, minden osztálynak van osztályfőnöke, vannak tárgyak, tanárok, jegyek, és mondjuk keressük az osztály átlagát matekból, és legyen valami változtatás, tanítson egy tárgyat ezentúl valaki más vagy nemtom.

A kulcsszó egyébként az adatbázis normalizáció.

Adj nekik egy akár ezer soros Excel táblát, aminek az egyik oszlopa számokat tartalmaz. Feladat, hogy összegezzék és mondjuk egy kimutatástáblával csoportosítva összegezzék. Aki megoldja a feladatot és jó a megoldása, ötös, mindenki más egyes.

A trükk? A 3398. sorban szövegként szúrd be a számot és rendezd jobbra ;)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A trükk? Az ezer soros táblázat 3398. sorába bármit is tenni.

No offense, csak egy feliratkozás akart lenni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az se rossz trükk, de ötödikben elég lehet az akár "csak pár" ezer soros is... :) Nekem meg időként proofreadelnem kéne a dolgaimat :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A kérdésed koncepciózus. Olyasmit keresel, sőt, el is akarsz magyarázni a gyerekeknek, ami nincsen. Ha nem informatikából fog a többségük megélni, sokkal többre mennének azzal, ha az Excel képességeit magyaráznád el nekik, belecsenve az adatbáziskezelés alapjait is.

Jó lenne, ha a gyerek nem koncepciót, hanem hasznot vinne magával az iskolából.

Az excellel egyetértek (ötödikben).
A koncepció vs haszon megfogalmazással nem értek egyet.
A koncepció (elméleti alapok) kell. De helyesen kell.

--
Gábriel Ákos

Rendben van, akkor finomítok. A gyereknek meg kell tanulnia, hogy az Exceltől nem kell elvárnia tranzakció kezelést, oké. Egy DBMS-től meg nem kell elvárni, hogy pivot table-t tudjon. Az informatika órán esetleg megtanítják neki, hogy eszik-e az SQL-t vagy isszák, de ki tanítja meg neki, hogy mire jó egy HLOOKUP? Pedig a való világban egy szűk réteg fog SQL-t használni és MINDEN érettségizettnek ismerni kellene az Excelt, magas fokon. Szörnyűek a tapasztalataim a pályakezdő fiatalokkal.

Mindkettőnek megvannak az előnyei.
Már mások említették a méretezést, a párhuzamos kezelést stb.-t.
A táblázatkezelő kisebb, áttekinthetőbb adatsorok kezelésére, prezentációk, grafikonok készítésére megfelelő. Ezeket az "analíziseket" általában manuálisan, cellákat bökdösve készítik el, ami nagyobb adatmennyiségnél hibaforrás lehet.
Ezzel szemben egy "igazi" adatbázis (a tárolt procoktól eltekintve) csupán az adatokat tárolja, és az analízist és a prezentációt külön programmal (amit persze meg kell tanulni vagy írni) lehet elvégezni. Így hogy az adatok tárolása és az analízis szét van választva, egyrészt az adatok nagyobb biztonságban vannak, másrészt tetszőleges analízist tetszőleges számban lehet végrehajtani ugyanazon az adatokon.

--
eutlantis

> párhuzamos kezelés

Így van. Pl. Excelben hogy tudod megcsinálni, hogy valaki módosít az adaton, más pedig a már módosított adatokat látja? Anélkül, hogy az egyik és a másik mentene, kilépne, új munkamenetet indítana?

vicces módon az o365-be kötött excel tudja.
google sheet meg teljesen tuti tudja.
--
Gábriel Ákos

Szóval tettek róla ezek a mocskos kapitalisták, hogy alig legyen érvünk a DBMS mellett... :-)

... és akkor meg az ilyenekről mint mongodb, elastic még nem is igen esett szó.
Szerintem érdemes elgondolkozni azon, hogy az RDBMS (és az SQL) nem lejárt lemez-e már.
Kb. mint a procedurális nyelveket is elfelejtettük már nagyrészt.
Marad egyfajta öröksége nyilván hiszen része az "evolúciónak", de lehet hogy nem érdemes már megtanulni.
Nem tudom, ehhez több idő kéne eldönteni.

--
Gábriel Ákos

Figyeljetek csak gyerekek! :)
Van két lista: Osztálynévsor és Kívánság.

Az Osztálynévsorban nevetek van, hogy tudja a Télapó, hogy kinek kell ajándékot hoznia.
A Kívánság listán is ott van a nevetek, de a nevetek mellé betudjátok beírni, hogy milyen ajándékot kértek.

A Télapónak sok dologgal kell foglalkoznia ilyenkor és a szeme sem a régi, ezért amikor elmegy beszerezni az ajándékokat, akkor csak azt a listát olvassa el, amin azoknak a neve van akik ajándékot kapnak. Ha megtalálja a nevedet, akkor megnézi, hogy Kívánság listán, hogy mit kértél.

DE van egy krampusza, aki szeret rosszalkodni és megviccelni a Télapót, azzal, hogy az Osztálynévsorból a varázsradírjával eltüntet neveket. Így ha a tiedet kiradírozza, akkor a Télapó nem talál meg téged, nem fogja tudni, hogy te kértél-e ajándékot.

Ha a Télapó Excelben vezeti az ajándékozást, akkor a Krampusz a varázsradírjával bizony kitudja törölni a nevedet, annak ellenére, hogy te kértél ajándékot.
Ha viszont DBMS-t használ a Télapó, akkor még a Krampusz varázsradírja sem tud téged kiradírozni az Osztálynévsorból, ha a Kívánság listán már kértél valamit.