ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
HOVD 2018 - Kedvenc adatbázis-kezelőamazon dynamodb, google bigtable, azure cosmos db 2% (10 szavazat) apache derby, java db, h2, sqlite 5% (28 szavazat) db2 2% (11 szavazat) firebird 1% (4 szavazat) gráf adatbázisok (például neo4j, marklogic) 1% (7 szavazat) mariadb, mysql, percona server 42% (258 szavazat) microsoft sql server 6% (36 szavazat) mongodb 3% (21 szavazat) oracle 4% (26 szavazat) postgresql 35% (219 szavazat) Összes szavazat: 620
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
Minden evben mindossze ket olyan szavazatot teszek le, amit jo erzessel teszek, tehat ugy erzem "rá" szavazok es nem "alá" (mint legkisebb rosszra).
Az egyik a PostgreSQL. Ebben a szemetdombban amit IT-nak hivnak a keves dolgok egyike, amirol erzem, hogy nem fog szarban hagyni, es esszel terveztek.
(Masik az nginx, de a PostgreSQL-t nehezebb volt jol megcsinalni)
+1 A PostgreSQL baromi jó szoftver.
Az valóban, csak sajnos a toolok körülötte... hát khm. Hagy maga után kívánnivalót. Ebben sajnos néha igazat kell adnom kollégáim hisztijének.
Bármennyire is kedvencem.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Jetbrains DataGripje, kulonallo szoftverkent es mas Jetbrain termek pluginjakent is eleg jo. Sajnos mindenhogy fizetos.
Mostanaban a DBeaver-t probalgatom, nem tunik rossznak es ingyenes is.
Mikor utoljára néztem - kb. másfél éve - nem volt benne grafikus explain, ami viszont egy igen hasznos funkciója a PgAdmin-nak (meg az SSMS-nek).
Az, hogy fizetős valami, az kevésbé probléma, ha megéri az árát. (Előző munkahelyemen is vetettünk PHPStorm licenceket, ill a mostanin is van lehetőség ReSharperre, ha valaki kéri.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Miben jobb mint a MySQL?
Hosszú hallgatás után nem régen előállt az Oracle friss MySQL kiadással, és ez a 8-as nagy fejlődést hozott.
Bár nem nagyon értek hozzá, de kb. mindenben.
Amennyire érintettem mindkét rendszert, úgy az egyikben "meg lehet oldani azt is...", a másikban "van ilyen benne, csak jobb" különbséget találtam.
postgresql-hez van már phpmysqladmin tudású tool?
Mi hiányzik nekeda meglévő toolok közül? Ott van a PgAdmin, ott vannak a JDBC alapú multiplatform eszközök, mint például a DBeaver. Mi kell neked?
Évekkel ezelőtt amikor körbefutottam témát, akkor még minden tool kicsit volt csak jobb, mint a parancssor.
a pgadmin szerintem bőven vállalható.
Tud elemzést és javaslatot is?
Atr kérdezed, tud-e explaint futtatni? :D
Nem:) phpmyadmin tud javaslatot tenni az optimális mezőformátumra.
Ez így önmagában értelmetlen. Mi szerint optimális? Tárhely? Elérési idő?
Az, hogy mi az optimális, azt mindig csak akkor tudod megmondani, ha megmondod, hogy mire optimalizálsz.
Ez javaslat függő. Mindenképpen érdemes elgondolkodni a javaslaton.
Amikor nulláról ír valamit az ember, akkor nem biztos,hogy a megfelelő mezőformátumot választotta.
Nem tudom, életemben nem kerestem ilyen funkciót ezekben :-/
pgAdmin 4, hát, ööö, értem az érveket, de azért mindig elmorzsolok egy könnycseppet a pgAdmin 3-ért, mikor elindítom.
Verziót nem mondtam. A 4 borzasztó.
Van. Adminernek hívják. Az nem csak MySQL-t tud, hanem több adatbázist, többek között PG-t is.
https://www.adminer.org/
Bár nem tudom, mennyire elég a tudása a kérdezőnek.
Van featurelista az oldalon, meg összehasonlító a PHPMyAdminnal.
Ez is?
Használtam adminert, szerettem is, de (legalábbis néhány éve) még kevesebbet tudott, mint a phpmyadmin.
Gőzöm sincs, hogy ezt tudja-e. Meg kell kérdezni tőlük és ha nem, akkor request feature.
Önkény és nem objektív az összehasonlítás.
Mi hiányzik belőle?
EMS SQL Manager for PostgreSQL - Wine-al is tökéletesen fut.
+1
> Postgresql
> wine
Lol
az ugye megvan hogy az EMS SQL Management-hez kell a wine, nem a pghez?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Miért akarna bárki is php*admin-t rakni bárhova is? PHPMyAdmin az oka, hogy egy halom rossz üzemeltetési gyakorlat elterjedt.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Mint pl?
Pl, hogy kinn van az egész adatbázis egy webes felületen valami gyenge jelszóval védve, mert "könnyen elérhető".
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Értem. Ez valóban gáz.
Ez semmiképpen sem a PMA hibája, ugyanis alapból (ha epelből teszed fel tutira) csak localhostról fogad el kéréseket, azaz a debil admin szándékosan teszi ki a netre.
A jelszavak "gyengesége" is inkább az admin hibája, ha jól emlékszem manapság már van bekapcsolt jelszó policy a MySQL-ben (belefutottam korábban), amit ki kell kapcsolni, hogy engedje az admin/admin szintű jelszavakat.
Én használom, mert nagyon hasznos eszköznek tartom, rendszergazdaként pont annyit tudok vele csinálni, hogy ne kelljen DBA-t fizetni, de nem teszem ki a netre, nem adok illetékteleneknek hozzáférést, minden adatbázishoz csak arról az IP-ről férnek hozzá, ahol az alkalmazás fut, stb. Szóval csak ésszel!
HeidiSQL, PgAdmin III tud SSH tunnelen keresztül csatlakozni OOTB. Mi a tökömnek kell egyáltalán bármi ilyet felrakni egy szerverre?
Egyébként hozzáteszem, az IP dologtól sem kell még önmagában hasra esni. Ha rendesen akarod csinálni, akkor már verify-full-os SSL, anélkül igazából false sense of security.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Várj, én nem mondtam, hogy a PMA-t a MySQL szerverekre tettem fel. Szerintem félreértettél.
Akkor meg végképp minek PMA? Egy halom olyan plusz dolog kell hozzá szemben egy sima klienssel, amihez elég egy SSH tunnel.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
A postgres/postgres kb ugyanilyen bevált gyakorlat és nem sokkal enyhébb.
Az ipar előrehaladtával ez a kérdés már némiképp értelmét veszti ebben a formában. Kb. olyan, mintha azt kérdeznék tőlem, hogy "mi a kedvenc szerszámod?". Modjuk nekem a kalapács, mert mindent meg lehet vele csinálni (oldani).
Kedvenc adatbázisaim felhasználás szerint:
SQL db - mariadb (erre szavaztam, mert ez volt)
key-value db - redis
time series db - influxdb
A postgres nem azért nem a kedvencem, mert nem tartom jónak, csak valahogy úgy alakult, hogy keveset használom, ezért nem is értek hozzá annyira.
A többi viszont biztos nem a kedvencem.
Épp a minap jött szembe a Guardian cikke, hogyan és miért migráltak PostgreSQL-re Mongo-ról.
Ennél szerintem érdekesebb az, hogy a Diaspora-sok hogyan és miért váltottak PostgreSQL-re.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Tudsz linket adni?
Ha jól emlékszem ez volt: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
ehe, anno egyik ex munkahelyemen hamarabb bebukott a dolog: üres, sharded mongo cluster segfaultolt bármilyen DML-re.
Dehát, dehát...az Über meg PostgreSQL-ről migrált MySQL-re! Hol itt az igazság? :D
Az egy specialis use case volt, ahol mar nem lehet fully relational database-zel dolgozni, es a mysql-ben az o szuk keresztmetszetuket okozo relational tuljdonsag elkerulhetosege veletlen pont jobban volt implementalva. De ilyenkor mar nosql a megoldas altalaban, persze vannak olyan nemrelacios feladatok is, amikben meg a postgres motorja veri az egyebkent nem is relacios es jol ismert nosql alternativat.
Igen, ezért tettem röhögő smileyt. A legviccesebb az volt, hogy (az SE Daily interjú alapján) azért vezették be a PostgreSQL-t, mert valamelyik technikai főnök tudta, hogy ott van rollback schema update-re. Ez tényleg egy PGSQL spec feature, imádom.
Viszont ha ez felmerül, mint migrációs ok, akkor azt jelenti, hogy korábban nagy problémáik voltak ebből...ami felvet egy-két kérdést a folyamataikkal kapcsolatban.
Hab a tortán, hogy a visszamigrálás után meg MySQL fölé húztak valami schemaless layert, merthogy az sokkal egyszerűbb a fejlesztőknek. Itt hagytam abba a követését a storynak... :)
Mert a MongoDB-t (és BigData-t) sokan sokszor divatból használják, aztán rájönnek, hogy abban az adatmennyiségben és elosztottságban csak szopás a MongoDB (és a BigData).
--
https://iotguru.live
A mostani uj irany, hogy a kliensoldalra toljuk le az adabaziskezeles egy reszet.
Mondjuk egy 10MB-nyi chunkban, majd o ott elmolyol az SPA-ban. Processzora van, hadd izzadjon:)
Az window.indexedDB.open() elbir 2GB-tal vegulis:)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Hat a MariaDB-t azt en kulonvennem a MySQL-tol, es a Percona servertol :/
Szöveges file!
Read inteface: grep és cut
Write interface: echo és sed
Joker interface: awk és printf
Backup software: cp és xz
Debugger: hexdump -C és szemmelverés
Skálázódás: vegyél gyorsabb procit
Security: rot13 és mindenki bek4phatja
Nna. Az vesse rám az első követ, aki még sosem tárolt adatot szöveges fileokban! :-)
:-)
En egyebkent szoktam ilyet csinalni, akar plain szoveges fajllal, akar XML, akar JSON-nel.
Sokszor ha nincsenek komplex lekerdezesek es tranzakciok, akkor boven elegendo a fajlokat megfelelo konyvtarrendbe tenni, es kesz. Esetleg be lehet indexelni az egeszet, ha kell.
Ja, es az egeszet be kell dobni git-be, es elosztottan is lehet hasznalni!
"Sokszor ha nincsenek komplex lekerdezesek es tranzakciok, akkor boven elegendo a fajlokat megfelelo konyvtarrendbe tenni, es kesz. "
Szóval igazából minden olyan adat, ami egyébként kukába is mehet, senkit nem izgat, ha nincs meg? :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
ezt kifejthetned. SEnki sem mondta, hogy ne lenne backup.
Egyebkent meg rengeted olyan dolog van, amit csak te hasznalsz, es mas nem (pl. email is ilyen),
szoval nem kivanja igazabol az adatbazist. Mondjuk pont emailnel pont a mongodb egy jo valasztas, de az alapotlet az az, hogy amit az ember sajat maga hasznal, sajat maga modosit, ahhoz mi a turonak adatbazis?
A git-nek se kell adatbazis.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
A git repository egy speciális object database egyébként, de a kérdés inkább az, hogy te mit nevezel adatbázisnak.
adatbazis az amit masik program hasznal;)
Nekem a git meg nem adatbazis. Van par programom ami hasonloan* mukodik.
*: Nehany 5letet a gitbol vettem ki.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Bizony, nagyon keverik a népek! Több projekttel kapcsolatban megkerestek a naaagy hozzáértésem miatt. Némi visszakérdezés után mondom, de hát EZ, ANNÁL A CÉGNÉL oracle, amihez nem és máshoz sem értek. De azt írtad... Igen, sok adattal dolgoztam, de nem RDBMS alapon.
Az adatbázis pl. egy vagy több szövegfájl: kuki|maki tartalommal. :-)
Az adatbázis rendszer meg lehet olyan is, ami ezeket a szövegfájlokat kezeli, indexeli, stb.
Tehát akár awk is lehet. :-D
Ha ugyanazokat az adatokat tárolod RDBMS-ben illetve XLS-ben vagy egyszerű szövegfájlban, akkor ugyanaz a logikai adatbázisod. A fizikai eltér, mint ahogy az adatbázis kezelő rendszered is.
Az, hogy nem célszerű, nem hatékony, esetleg nem biztonságos valamely fizikai adatbázis, attól még adatbázis lesz.
Másrészről egy fájlrendszerben tárolt adatbázis is lehet célszerű, hatékony és biztonságos is. Attól függ, hogy mit és hogyan tárolsz benne, hogyan éred el.
+1
Pontosan ilyesmire gondoltam. De van egy lényegi különbség. A szakemberek kivétel nélkül "adatbázist" mondanak, ha "(relációs) adatbázis kezelő rendszerre" gondolnak. Már pedig az utóbbinak része pl. a wiev, meg sok-sok egyéb, ami a kezelési és megjelenítési funkciót látja el.
Számtalan esetben nincs szükség "kezelésre", vagy megjelenítésre, és ilyenkor a komplex "kezelő rendszer" abszolút feleslegessé válik. Egy komplex rendszer általában korlátokkal és side-effect halmazokkal gondosan ellátott entitás, ahol ezeket a tulajdonságokat csak kerülgetni kell.
A fájlrendszerben tárolás is alap dolog, bár ott is létezik overhead. Sok esetben még többet is tud a kelleténél, illetve nem elég biztonságos. (Gondolok itt az elemes diszk cache-re.)
Itt azért érdemes elgondolkodni olyan tényeken, hogy az Oracle miért vette meg a BerkeleyDB-t. Hacsak nem azért, mert az utóbbi pont azt tudja, mint amit az előbbe csak a mesében - hiába piacvezető. :)
" és ilyenkor a komplex "kezelő rendszer" abszolút feleslegessé válik."
Egészen addig, ameddig el nem kezdesz olyan problémákat megoldani (vagy felelőtlenül ignorálni), amiket már réges-rég megoldottak más "komplex" adatbáziskezelő rendszerekben.
Adatokat perzisztálni _JÓL_ bonyolult.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Ez a perzisztálni nyilvánvalóan echte hungaricum. ;)
Értem miről beszélsz. Saját adatbázisoknál is felmerült, hogy tényleg sikerült-e tárolni az inputot (3..100M adat). Vagy néha a gépi úton kitöltött adatok tényleg azok-e amire gondoltam. Ilyenkor van egy "list" funkció és utána egy diff.
Két megvalósított algoritmusomat megpróbáltam lefordítani angolra és rákerestem. Ez egyik kisértetiesen hasonlított az IBM mainframe könyezetben szabadalmaztatott algoritmusához, míg a másik egy Oracle szabadalomhoz. Persze csak hasonlított, ráadásul teljesen más környezetben.
Ezzel nem azt akarom mondani, mint amikor nekem szegzik a "Mindenki más hülye, te meg a helikopter!" véleményt (különben is: én a rénszarvi vagyok). Inkább némi gondolkodás és alaposság után el lehet jutni a jó, vagy a célnak leginkább megfelelő megoldásig.
Persze lehet vitatkozni, hogy mikor megbízhatóbb a rendszer? Ha én írok small footprint - azaz átlátható - algoritmusokat, vagy használjunk helyette oracle-t, ami ...
Nemrég láttam egy brilliáns ellenpéldát. Log készül postgres vagy mysql alapon (??), amihez kell "index". (Pótkérdés: Hol akarod megjeleníteni?) Méghozzá azon célból, hogy - ha időszakosan nincs kapcsolat a központtal - tudjuk meddig sikerült a logot felküldeni. Aztán az említett adatbázis úgy leakadt, hogy nem is lehetett vele mit tenni. :-D (keresztkérdés a kollégához: Hallottál már a SIGPWR signal-ról?)
Próbáltam magyarázni: Nem index, hanem pointer. De index! - Nem adatbázis, csak szöveges sorok. ... és így tovább.
Ráadásul az AIX-től a Windows-ig nem így logolnak. (Kolléga nézett, mint a boci.)
Tehát az sql ismeretek helyett érdemes megvizsgálni, hogy a világ értelmesebbik fele hogya tárolja a logokat! Aztán NEM HASZNÁLNI olyan eszközt, ami nem oda való. Így nem keletkezik olyan probléma, aminek semmi köze a feladathoz, ráadásul meg sem kell oldani.
Nem korlátoztam az adabázis fogalmát az RDBMS-ekre.
Az, hogy a világ egy jelentős része mit csinál a logokka, arról meg ne beszéljünk, mert egyesek szerint a plain text log ahol egy logentry egy sor, már a technológia csúcsa, minek strukturált logolás.
Amúgy meg azért szép az IT, mert mindenre lehet hozni példát és ellenpéldát. Nekem a személyes kedvencem, amikor valaki úgy gondolta, hogy á, legyen lightweight, ne legyen külső függőség és csinált egy txt alapú, tranzakciózott kulcs-érték adatbázist. Az, hogy szopás volt, mert csak primitív típusok voltak támogatva az adat meg igazából sokszor relációs és egyébként is sokszor komplett rekordokat kellett volna tárolni (emiatt sokszor egy adat 5-6 kulcson is volt szétszorva), az más más kérdés. Egy SQLite-val már kiegyezett volna mindenki, kivéve, aki az eredeti kódot írta.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Tehát itt van egy fogalmi különbség köztünk. Szerintem nem attól adatbázis valami, hogy több processz tud hozzá beszélni egyszerre (így kiesne pl. a sqlite is).
Pl. a Gerrit-ben mostanában fejezik be a migrálást PostgreSQL backendről Git alapú NoteDb backendre.
Saxus hozzászólása:
> "Sokszor ha nincsenek komplex lekerdezesek es tranzakciok, akkor boven elegendo a fajlokat megfelelo konyvtarrendbe tenni, es kesz. "
> Szóval igazából minden olyan adat, ami egyébként kukába is mehet, senkit nem izgat, ha nincs meg? :)
Én a fentiekre reagáltam, ahol saxus leszólta, hogy valaki adatot fájlrendszeren tárol.
Most akkor ez olyan, hogy "mehet a kukába", vagy nem?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Persze, nem gáz, lehet tárolni random fájlokat is a lemezen. Csak kezeld le az összes létező hibaesetet (van sok), legyenek konzisztensek az adatok, itt már előjön a tranzakcionális adatkezelés vagy journaling vagy más egyéb implementáció, stb. Vagy mondjuk csak szimplán akarsz egy konzisztens backupot, ahol lehetőleg az indexed ne legyen eltérve az adattól, mert külön fájl és külön időpillanatban backupolódott a kettő. Igen, tudom, ott az FS snapshot, AFAIK tudja a ZFS, BTRFS meg az NTFS, aztán az alkalmazásod vagy felkészíted a támogatására vagy nem.
És akkor még sorolhatnám azon hibalehetőségek sokaságát, amiket azok a komplex rendszerek már többé-kevésbé, de valahogy megoldottak.
Persze, lehet ignorálni is ezeket az eseteket, csak akkor azt ne nevezzük mérnöki munkának, hanem nevezzük valami összetákolt szarnak.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™