Új hozzászólás Aktív témák
-
martonx
veterán
Ahogy mondtam a backup-ot sokféleképpen lehet értelmezni. Nálunk pl. a fő DB szerverről real time mirror-ing van más helyen lévő szerverre.
Szóval backup-ról most nem beszélve, szerintem minimum az alábbiakat érdemes legalább hétvégente lefuttatni:Check Database Integrity
Shrink Database
Reorganize Index
Rebuild Index
Update StatisticsÉn kérek elnézést!
-
martonx
veterán
Ha kocka vagy a szó jó értelmében, akkor mindenhez PostgreSQL-t érdemes használni (már persze MySQL összehasonlításban, én egyébként MS SQL-re szavaznék a jelenlegi SQL felhozatalban).
Ha nem akarsz belemélyedni, csak annyit akarsz, hogy menjen, és az alapfunkciókat használod, akkor a MySQL elsőre szvsz jobban kézre áll.Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1456 üzenetére
Mert a motorháztető alatt, illetve skálázhatóság (gondolok itt elsősorban a fürtőzésekre, azaz horizontális skálázhatóságra) szempontjából a PostgreSQL sokkal többet tud, sokkal finomabbra hangolható.
És ahogy mondtam, az már más kérdés, hogy a userek 99%-a ezeket a MySQL-hez képest extrának számító feature-öket az életben soha nem is fogja kihasználni.
Ellenpéldának meg ott van a Facebook, de ők már rég agyonhack-elték mind a PHP-t, mind a MySQL-t, és jó példák arra, hogy szarból is lehet várat építeni, ha erre több milliárd dollárod van.Másrészt bevallom nem vagyok 100%-osan naprakész ez ügyben. Postgre-nal lemaradtam a 9-es főverziónál, MySQL-t érdemben utoljára 5.4-eset használtam. Szóval lehet, hogy közben MySQL lépett előre, bár magának az Oracle-nek sem érdeke, hogy igazi konkurenciát támasszon házon belül az Oracle DB-nek.
Én kérek elnézést!
-
martonx
veterán
válasz lakisoft #1459 üzenetére
Miért is nincs értelme az összehasonlításnak? Ráadásul nem is hasonlítottam össze, tényt közöltem, hogy az Oracle tudatosan tartja bután a MySQL-t. Persze fejlődget, de tudatosan hagyják ki belőle azokat a funkciókat, amitől horizontálisan jól skálázható, központilag könnyen üzemeltethető lenne (backup, mirror, stb...), adattárházként használható, azaz amitől a nagyvállalati szegmens számára vonzó lehetne.
Mivel a kolléga erre volt kíváncsi, illetve mások is kérdezték, hogy miben jobb a PostgreSQL. Pont a fentiekben jobb (minusz adattárház, mert az abban sincs igazán).
Ettől még nagyon is össze lehet hasonlítani mindent mindennel, pláne amikor DB platform választás előtt áll valaki.
Én is csak mellékesen jegyeztem meg, hogy én személy szerint nem választanék se MySQL-t, se PostgreSQL-t. Manapság egész jó ingyenes verziói vannak az Oracle db-nek, ennél többet tud az ingyenes MS SQL. Induláshoz ezek bőven elegek. Aztán, ha bejött a nagy üzlet, akkor el lehet gondolkodni ezek fizetős verzióin, illetve amit nagyon ajánlok az a felhő. Amazonws, azure, google felhője, már mindenkinek van felhő szolgáltatása, és szépen csökkengetnek az árak.Én kérek elnézést!
-
martonx
veterán
válasz lakisoft #1461 üzenetére
Fejlesztőként, de néha muszáj valamennyit üzemeltetnem is.
Abszolút nem szeretnék belemenni MS SQL, Oracle flame war-ba. Vannak olyan képességei az Oracle-nek, amikben valószínűleg jobb (a motorháztető alatt értem), de az általad írt példák éppen nem ilyenek, hanem tökéletesen szubjektív szintaktikai példák.Én kérek elnézést!
-
martonx
veterán
na, ezt felejtsd el nagyon gyorsan. A NoSQL-ek jellemzően memóriában futnak, minél inkább ott tartják az adatbázisukat. Ezért is szokták javasolni, hogy NoSQL-t 64 bites oprendszerekre tegyünk, hogy bőven legyen alattuk memória. 1Gb memóriában fusson egy oprendszer, meg egy NoSQL és még erre akarsz rakni SQL szervert, meg web kiszolgálót is???
Ráadásul ha jól vettem ki a szavaidból a webkiszolgálást Java alapokon tervezed, ami alá a webszerverek nem éppen a karcsú memória igényeikről híresek. Ez így nagy bukta lesz.Én kérek elnézést!
-
martonx
veterán
"itt anti tárolt eljárás szellemiség van" - szóval gányoltok, vagy annyira kicsiben játszotok.
Mondok egy gyors példát, hogy mikor jó a tárolt eljárás és egyáltalán nem csak ASP.NET-nél
Egy táblába be kell szúrnod egy adatot, más táblák adainak függvényében.
Ezt megoldhatod úgy, hogy fogod, lekéred az adatokat 3-4 táblából a webszerverre, majd kódban megvizsgálgatod őket, ezek alapján összeraksz egy insert-et, és beszúrod az adatokat. Ez így mondjuk 4-5 DB-hez nyúlást jelent, mindig felépíted/feléleszted a kapcsolatot, az adatok jönnek mennek feleslegesen, kezeled a kivételeket stb...Ehelyett írhatsz egy tárolt eljárást, amivel SQL DB-n belül tudod megoldani ugyanezt. Egy adatbázis hívással, nulla felesleges adatmozgással.
Én kérek elnézést!
-
martonx
veterán
No, de mind a NoSQL, mind a hagyományos SQL-ek, annyi cuccot tartanak memóriában, amennyit csak tudnak, vagy amennyit kell.
Tehát ha most a teszt db-idben mind a 10 táblában van 10-10 sor adat, így persze, hogy egyik sql sem foglal sok memóriát. Csakhogy ez éppen semmit nem jelent, mert ha mind a 10 táblában lesz táblánként 200.000 adat, és ezeket másodpercenként 10-szer lekéri a webszerver, akkor mindjárt más lesz a leányzó fekvése.
Plusz a webszerver terhelése is gondolom nulla. Majd ha párhuzamosan 10-20 kérést fog kiszolgálni, és mindegyikre indít 1-1 VM-et, a maga 30-40 Mbyte-jával, akkor fogsz te nagyot nézni, és azt mondani, hogy pedig még a laptop-omon is milyen pöpecül futott minden, míg egymagam fejlesztgettem.
Nem véletlen, hogy kereskedelmi java hosting szinte sehol sincs (bár ennek szvsz másik oka a milliónyi java-s nyelvjárás is), ellentétben a PHP-s, ASP.NET-es hosting cégekkel, amikkel Dunát lehetne rekeszteni.Én kérek elnézést!
-
martonx
veterán
válasz DonThomasino #1527 üzenetére
Tényleg csak pár hsz-t kellett volna visszaolvasnod...
Én kérek elnézést!
-
martonx
veterán
Nem a táblát cache-eled, hanem a választ. Mondjuk ASP.NET-tel egy programsor beállítani az adott válasz cache stratégiáját. De gondolom PHP-ban se kivitelezhetetlen feladat normális cache stratégiát felépíteni.
Hogy jobban megértsd:
Kliens oldalon lekérsz adatokat. Ezt úgy teszed meg, hogy elküldöd a kérést a webszervernek, és az odafordul az SQL-hez, lekéri az adatokat, ezekből mondjuk json-t, xml-t, html-t csinál, és azt visszaküldi a böngészőnek (ami persze lehet vastag kliens, bármilyen program, csak manapság a böngésző a legelterjedtebb).
Nos ezt a webszerver választ tudod cache-eltetni, függetlenül attól, hogy mennyi sor van az sql tábládban. Adott kérdére mindig adott választ fog adni X ideig. Sőt továbbmegyek, a választ a kliensben is el tudod tárolni, így legközelebb még a webszerverig se fog eljutni a kérdés, mert a válasz már ott van a kliens memóriájában.Én kérek elnézést!
-
-
martonx
veterán
Azért a materialized view, illetve indexed view-k korántsem olyan hatékonyak, mint egy sima webszerver cache, mert ezek ha nem is olyan mértékben mintha elölről indulna mindegy egyes lekérdezés, de azért mozgatják az SQL-t. Az adatok felesleges mozgásáról, felesleges SQL-hez fordulásokról nem is beszélve. Szvsz nem is arra lettek kitalálva, hogy kvázi cache-t alkossanak bizonyos táblák felett, inkább az indexelt lekérdezéseket könnyítik meg nagyon komplex lekérdezéseknél (legalábbis MSSQL vonalon, ott használtam már indexed view-t).
Én kérek elnézést!
-
martonx
veterán
Fordítsunk a dolgon. Azt mond meg mit szeretnél. Milyen program alá, milyen platformon, mindenféle részlet jöhet, amu publikus. Aztán megpróbálunk segíteni. Mert ennyi részletből "Kereséshez van szükségem erre, szóval egy 7*20000 soros táblát kéne a cache-ben tartani." nem sok minden derül ki.
Én kérek elnézést!
-
martonx
veterán
Rossz hírem van, mert ez tipikusan nem cache-elendő, nem cache-elhető eset. Illetve lehet próbálkozni a Zeratul által leírtakkal (bár mysql-nél pont ezt sem tudod megtenni). Pont erre való lenne az SQL, hogy szabadszavas kereséskor villámgyorsan kiszolgálja az alkalmazást.
Gondolom azért akarod cache-elni, mert lassúak a válaszok?
Pedig ez még nagyon nem is sok adat. Én a helyedben inkább annak néznék utána, hogy miért lassúak a válaszok, mert ennyi adat nem sok. Vagy eleve rossz a DB felépítése, vagy hiányoznak index-ek.Én kérek elnézést!
-
martonx
veterán
válasz DonThomasino #1545 üzenetére
De hiszen ez kezdőknek szóló könyv. Onnan indul, hogy hogyan hozzunk létre táblát, meg hogy kérdezzük le select * from tabla-val. Mit akarsz ennél kezdőbbet? Hogyan installáljunk SQL szervert? Letöltöd netről, majd next-next-finish.
Én kérek elnézést!
-
martonx
veterán
válasz lakisoft #1550 üzenetére
"- A tárolt eljárásként írt kódot nehézkes verziókövetővel használni"
Butaság, miért ne lehetne, bár valóban nem annyira triviális. Én pl. TFS-ben egy külön mappát tartok fenn a DB scripteknek, amik ugyanúgy verziókezelődnek."- Az adatbázisok által biztosított fejlesztői eszközök a 60-as évek színvonalát idézik"
Ez mondjuk nagyon függ attól, hogy milyen DB-t használunk. Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn), MySql vonalon szeretem a Toad for MySql-t (mysql-hez van kismillió jó SQL IDE), PostgreSQL-hez meg egészen használható a PgAdmin.Klasszikus hibás programozói attitűd, amikor valaki nem akar megtanulni SQL-ezni (pedig gyakran nagyon hasznos), hanem mindent java-ban, c#-ban, php-ben akar programozni. Én használok ORM-et (sőt mostanra csak ezt), de az ORM-el ha a feladat azt kívánja meg akkor tárolt eljárást hívok meg. Sokan az ORM-et is félreértik.
Attól, hogy ORM-et használ valaki, miért ne lehetne összerakni DB oldalon egy view-t, vagy egy tárolt eljárást, és azt használni ORM-mel?Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1556 üzenetére
mert az egy php-s topik, minek offolni benne SQL fejlesztő eszközökről. Annak meg nem látom értelmét, hogy egy szemmel láthatóan nem képben lévő, ám annál arrogánsabb embert, megpróbáljunk picit is képbe hozni.
Én kérek elnézést!
-
martonx
veterán
"A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz."
Ez miért előnye a php-nak? Miért más nyelveken mit tárolnak a verziókövetőben? Szerelmes verseket?"Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van."
A relációs SQL az egy rohadt nagy halmaz, rengeteg alhalmazzal, amik között halmaz műveleteket tudsz elvégezni rohadtul gyorsan. Hol akarsz ebben fejlődést? Legyenek örökölhetőek, interfészelhetőek a tárolt eljárások? Legyen bennük lambda, meg generikus függvények??? Ráadásul vicces pont PHP oldalról fanyalogni az SQL nyelv egyszerűsége miatt..."A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást."
Ne általánosítsunk már ennyire. Lehet, hogy a te eseteid kimerülnek abban, hogy egy darab adattábla van a weboldalad alatt. De hidd el, amikor komoly adatlogikákat kell kivitelezni, és komoly algoritmusokat kell kivitelezni, akkor azt próbáld már meg webszerver oldalon kivitelezni. És ha készen vagy vesd össze a futásidőket. Tudnék mutatni olyan tárolt eljárásokat, amik több ezer sorosak, és percek alatt lefutnak. Az egyikkel konkértan egy 4 óra futásidejű webszerver oldali tákolmányt váltottunk ki.
Csak gondolj bele. Minden egyes db-hez fordulás idő. Ha van egy komplexebb feladat, amihez több db hívás kell, hívásonként visszad az sql szerver pár millió adatot. Utána for-al megforgatod az adatokat, megcsócsálod, majd visszaírod db-be, akkor az nagyságrendekkel könyebben, gyorsabban, optimalizáltabban elvégezhető db oldalon.
Az én eseteim pl. szinte minden esetben ilyenek. Mégse mondom azt, hogy az esetek többségében tárolt eljárást kell írni. Ehelyett maradjunk abban, hogy a helyzet dönti el, melyik megoldás a hatékonyabb a rendszer futása, terhelhetősége szempontjából.Én kérek elnézést!
-
martonx
veterán
2013-ban nem illik ilyen old school join-okat csinálni. Írd át modern sql szintaktikára:
from egytabla t1
join kettotabla t2 on t1.id = t2.id
join haromtabla t3 on t1.id = t3.idA hiba pedig elég egyértelmű. A három tábla descartes szorzata túl sok sort adna vissza, és (shared hosting környezetben jellemzően direkt) le van korlátozva a mysql memória használata, join-ok mérete.
Ezt elkerülni úgy tudod, hogy vagy megpróbálod átkonfigurálni a mysql-t, ha nem vagy hosting környezetben akkor ez menni fog.
Vagy alselecteket használsz, és megpróbálod csökkenteni a join-olt táblák visszaadott sorainak számát. Erre jó lehet akár egy szigorúbb feltételes join is. Az is lehet, hogy az id kapcsolat nem jó, és ez miatt többszörőződik meg indokolatlanul a join.
Vagy átmész egy rendes hosting-hoz, ahol nincs ilyen korlátozás.Én kérek elnézést!
-
martonx
veterán
bocsánat, nem fogalmaztam pontosan, természetesen a join-ban használt alselectre gondoltam, azt hittem ez a szövegből egyértelműen kiderül. De ezek szerint nem. Senkit nem szeretnék félrevezetni!
Szóval az egyértelműség kedvéért: A select-be ágyazott alselect a legrosszabb megoldás (még ha gyarkan az engine ki is tudja optimalizálni, de erre ne építsünk!). A join-ba ágyazott alselect viszont nagyon hasznos tud lenni.Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #1582 üzenetére
hehe, ezen tényleg csak nevetni lehet.
Mondjuk ezt többször is hangoztattam, hogy leginkább MS SQL, PostgreSQL vonalon mozgok, néha egy kis MySQL-el, Oracle-el fűszerezve. Azért megkérdezném azt az oktatót, hogy mire alapozza amit mond (évtizedes berögzülés nem számít, illetve az Oracle 9i-re hivatkozást sem fogadom el érvként), és ugyan mutasson már egy példát.Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #1584 üzenetére
MS SQL optimalizációit ismerve nagyon nem mindegy, hogy az sql motornak néhány soros (hangsúlyozom néhány), vagy ennél több, mondjuk pár százezer adattal kell dolgoznia. De hogy 100.000 vagy 100.000.000 az már édesmindegy. Klasszikus optimalizálási hiba tud lenni, hogy pár sornyi teszt adatokkal az sql-t beoptimalizálja a motor, majd amikor mindezt ráengeded 100.000-re akkor csodálkozol, hogy miért lassú.
De hogy jön ez a join-olás régi vagy új szintaktikájához? Nehogy már a használt join szintaktika határozza meg az sql motor optimalizálását.Én kérek elnézést!
-
martonx
veterán
válasz rum-cajsz #1586 üzenetére
Ezért is hangsúlyoztam mindenhol, hogy az Oracle-el felületesek (mondjuk azok nem túl pozitívak) az ismereteim, és egy szinte ismeretlen rendszerről nem volna etikus véleményt mondanom. Pláne, hogy történelmi okok miatt máig a legelterjedtebb db, annyira nem lehet rossz.
Őszintén én is bármit el tudok képzelni az Oracle db motor működéséről, de mivel az Oracle-höz bevallottan nem igazán értek, és db motor flame-be se akarok belemenni, maradjunk abban, hogy Oracle esetén akár igaz is lehet, hogy biztos ami biztos alapon érdemes a régi join szintaktikát használni.Én kérek elnézést!
-
martonx
veterán
válasz pittbaba #1606 üzenetére
Én is belebeszélhetek? Koncepcionálisan hibáztál.
Ne pöcsölj SQLite-al, egyszerűen nem erre való. Az egész DB-t told fel valahova a felhőbe, tegyél rá egy webszolgáltatást, vagy web api-t, és az android-os alkalmazásod meg hívogassa azon keresztül. Most komolyan te egy 600-1000 mhz-s kis fos telefon procitól várod el, hogy többszázezer soros, join-olt SQLite db-ből találjon meg bármit is pillanatok alatt? Indexelheted ezt akárhogy, akkor is megfőzöl egy kávét, amíg szegény kis proci végignyálazza akár csak az indexeket.Én kérek elnézést!
-
martonx
veterán
válasz trisztan94 #1605 üzenetére
De van. Egyrészt az nvarchar(max) enged bármennyit (na jó 2Gb vagy valami ilyesmi korlátja van).
Másrészt az indexlésükben van eltérés. A text-re tudsz tenni full-text search-öt, viszont text-ben nem tudsz olyan lazán like-al keresni mint varchar-ban.
Varchar-ban nem fog működni a full-text search viszont like-al kereshető.
Remélem jól írtam, nem kezdtem most el helyetted MSDN dokumentációt olvasni.Én kérek elnézést!
-
martonx
veterán
de te nem is egy 600Mhz-s arm-os szörnyetegen futtattad a lekérdezést. Néha ledöbbenek, amikor egy ilyen kis procinak még egy komolyabb html weboldal renderelés is nehézséget okoz, akkor mire számítasz egy 2,5 millió soros, SD kártyán lévő adatbázis futtatásakor?
Én kérek elnézést!
-
martonx
veterán
válasz Sk8erPeter #1640 üzenetére
hú bocs, igaziból kicsit elveszítettem a fonalat. Annyi volt a mellékes információ, hogy bevallom nyugodt szívvel kihagytam a kérdezőtől pár feleslegesnek vélt túl hosszú hszt.
Ez esetben teljesen jogos a felvetés, hogy pillanatok alatt mennie kellene a lekérdezésnek, ahogy ez másnál működik is. Valószínűleg már csak rendesen indexelni kell a db-t, és hasítani fog.Én kérek elnézést!
-
martonx
veterán
-
martonx
veterán
válasz bambano #1830 üzenetére
Lehet, hogy félreértettelek. Úgy értettem, hogy egy query eredményeként kigenerálsz egy rakás SQL query-t, és ezeket szeretnéd egymás után futtatni programozottan.
Hja, normálisabb SQL nyelvekben ehhez nem kell tárolt eljárás, PostgreSql-ben valóban kell (bár mintha 9.1 / 9.2 újdonsága lenne, hogy immár tárolt eljáráson kívül is lehet benne magasabb szintű nyelvi elemeket is használni)
Kettes kérdésedet nem tudom értelmezni, lehet azért mert még mindig nem értem, hogy mit is szeretnél?
Hármas kérdésedre sem tudok válaszolni. Ha van, akkor használd azt. Öröm - boldogság. Ha nincs, akkor örülök, hogy segíthettem a for-os ötletemmel.Azért végezetül megpróbálnád összefoglalni, hogy mit is szerettél volna, és végül mi lett a legegyszerűbb megoldás?
Én kérek elnézést!
-
martonx
veterán
"mindig egy query lesz az eredmény, azt kell futtatni.
Erre elvileg (postgrestől elvonatkoztatva) két módszer létezhet:
- van készen eval függvény
- tárolt eljárást kell rá írni."Akkor csak jól értettem. Postgrestől esetedben éppen hogy nem lehet elvonatkoztatni, mert pl. MySQL-lel, vagy MSSQL-el (de gondolom Oracle-lel is, bár azzal nincs sok tapasztalatom) simán futtathatnád tárolt eljárás nélkül is a kapott query-det.
Az eval-t javascriptből ismerem, tudtommal SQL-ekben ilyen nyelvi elem nincs (hacsak nem oracle-ben), az hogy egy programnyelvben mit hogy oldasz meg, teljesen irreleváns SQL-ben fejlesztéskor.A problémádat még mindig nem értem teljesen, de végiglépdelni egy query recordjain, amelyekben szintén query-k vannak legenerálva, és ezeket a queryket egymás után futtatni, továbbra is azt mondom, hogy a FOR egy megfelelő megoldás lehet.
Én kérek elnézést!
-
martonx
veterán
válasz Petya25 #1847 üzenetére
Írsz rá egy kis programocskát, aztán az pont ezt fogja tudni, legalábbis a táblázat részéig elég triviális.
Az más kérdés, hogy diagramm nehezen lesz benne, bár kerülő utakkal biztos tudsz diagrammot képként generáltatni valamilyen eszközzel, és a képet már bele tudod szúrni a html formátumú emailbe.Én kérek elnézést!
-
martonx
veterán
válasz dellfanboy #1900 üzenetére
Ez most akkor pontosan milyen SQL is? MSSQL, Oracle, MySQL, PostgreSQL?
És jól értem, hogy első körben egy linked servert szeretnél beállítani? Vagy az már adott?
[ Szerkesztve ]
Én kérek elnézést!
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs