Új hozzászólás Aktív témák
-
#2171
martonx
veterán
csabyka666
#2169
martonx
veterán
válasz
csabyka666
#2169
üzenetére
én csak a példa kedvéért írtam a like-ot, nem azon volt a hangsúly, hanem az egymásba ágyazott vagy-okon és-eken.
-
#2167
martonx
veterán
csabyka666
#2165
martonx
veterán
válasz
csabyka666
#2165
üzenetére
Valami ilyemi kellene, hogy legyen a keresési feltételed:
WHERE
(feltétel1 nem üres OR mező1 like feltétel1)
AND (feltétel2 nem üres OR mező2 like feltétel2)
AND (feltétel3 nem üres OR mező3 like feltétel3)
...Már ha jól értettelek.
-
#2149
martonx
veterán
kenesei1982
#2147
martonx
veterán
válasz
kenesei1982
#2147
üzenetére
Huh, én dolgoztam outsorcing céggel, akik outsourcingban linux, mysql szervereket tartottak karban.
Viszont nem volt jó tapasztalatom velük, bár a semminél jobbak voltak.Ha nagyon kell, megpróbálom feldúrni az emlékezetemben (emailjeimben) őket, ha drágán, lassan, akarsz nem túl jó minőségű munkát kapni, akkor mindenképpen jobbak mint a semmi.
-
martonx
veterán
Ez esetben ahogy írtam már, kell neked egy segéd tábla, valami ilyesmi felépítéssel:
Felhasználó azonosító, Iroda azonosító, Engedély dátum, Engedély (Igen / nem)
És ilyesmi adataid lennének benne:
1, 1, 2014-01-01, igen
1, 2, 2014-01-10, igen
1, 1, 2014-02-15, nemAzaz az 1-es felhasználó az 1-es irodához kapott engedélyt 2014-01-01-én. Ezt az engedélyt 2014-02-15-ével visszavonták. A 2-es irodához van élő engedélye 2014-01-10-e óta.
-
#2140
martonx
veterán
Peter Kiss
#2139
martonx
veterán
válasz
Peter Kiss
#2139
üzenetére
MS access-ben triggert nehezen fog csinálni.
Viszont ha egy kvázi log / history tábla kell, akkor tényleg csak egy plusz táblára lesz szükség, és a fő tábla update-elésekor, ebbe kell insertálni egy sort, ami mutatja a változást.
-
martonx
veterán
-
martonx
veterán
MySql-lel (pedig 5.6-os verziót használunk per pillanat) sebesség tekintetében nekem is rossz tapasztalataim vannak. De lehet, hogy csak én nem értek hozzá eléggé. Konfigoltam, hangoltam, de igaziból nem nagyon lett jobb.
MS is ad rengeteg kedvezményt, az hogy papíron mennyibe kerülnek csak egy dolog.
-
martonx
veterán
válasz
bambano
#2104
üzenetére
Pedig postgreSQL-lel is lehet clustert építeni. Sőt az ingyenes MySQL-el is.
Ettől függetlenül szerintem is Oracle és MS SQL a két komolyan vehető adatbázis szerver. Mondjuk az Oracle aranyárban van, bár talán nem is véletlenül adják annyiért.
Ami még nagyon jó alternatívája az ingyenes SQL-eknek, az a Microsoft féle Azure SQL, ami bérelhető MS SQL 2012 szerver, némi felhős butítással. Az enyém havi kemény 4 euróért, napi 9 millió rekordot fogad magába, hogy aztán 1 órán belül ezek nagy része törlődjön is, és még ehhez jönnek az egyéb queryzések. 4 euróért zseniális a teljesítménye. -
martonx
veterán
- az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
Ez evidens, de ha ez így lenne, akkor mindjárt eljutunk oda is, hogy minek relációs adatbázist használni. Ennyi erővel eltárolod egy text file-ban az egészet, és nincs is miről beszélnünk.- a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
Erre lennének valóak a view-k, tárolt eljárások.- ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)
Hogy jön ide az ORM? Olyan view-t, vagy selectet, vagy tárolt eljárást írsz, amilyet akarsz, és az lesz benne, amit akarsz. Végül az ORM-et arra húzod rá, amire jólesik (legalábbis NHibernate, Entity Framework-ös tapasztalataim alapján).Szerintem maga a kérdés feltevés értelmetlen volt, hiszen ha ilyen bagatell a dolog a részedről, ilyen pici a projekt, ilyen minimális adattal, meg különben is ennyire értesz hozzá, akkor minek kérdezted meg? Úgy kókányolsz vele, ahogy akarsz. Ha viszont igényes munkára törekszel, akkor meg miért nem fogadod meg a tanácsokat?
-
#2093
martonx
veterán
Sk8erPeter
#2090
martonx
veterán
válasz
Sk8erPeter
#2090
üzenetére
Az, hogy a táblák lényegében mekkorák, soha nem indok arra, hogy csak azért is szopassuk már meg jól az SQL szervert
![;]](//cdn.rios.hu/dl/s/v1.gif)
Azért mondtam akkora méreteket, mert ha azt mondom, hogy nem 10 ms lesz a query ideje, hanem 500 ms, az nem fog elég elrettentőnek hatni.
Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is? Különben is sokkal kényelmesebb visszanézni szemre az adatokat, meg a PHP-ban is egy select * from tabla, és mindenki happy.Nehogy már elkezdjünk erre bólogatni, hogy tényleg milyen igaz.
-
martonx
veterán
Mivel semmi konkrétumot nem írtál, nyilván én se tudtam mit írni azon kívül, hogy még a felvetés is hülyeség. No, de közben jött itt egy példa a településnevekkel.
Szerinted melyik megoldás a rövidebb? Egy 16 - 32 bit hosszú mezőben eltárolni egy numerikus adatot, vagy egy 50X16 bitnyi mezőben eltárolni egy szöveges adatot.
"- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?"
Jelzem, amikor erre a mezőre indexet húzol, az indexed is pont ilyen méret differenciákkal fog létrejönni.
Aztán nézzünk még egy érvet. A processzorok leggyorsabban számok feldolgozásával működnek. Persze-persze, minden mást is fel tudnak dolgozni, ami binárisan leírható, de akkor is minden CPU alapja a "számolás".
Számszerűsítve a dolgot, olyan több mint 50-szeres sebességkülönbség simán lehet a két megoldás között. Azt persze aláírom, hogy kis tábla méreteknél ez észrevehetetlen, de ha egy táblában van 2-3 ilyen szarul megoldott indexed, és a tábláid több százezer sorosak, netán valami gyenguc hoszting gépen vagy többtized magaddal ugyanazon az adatbázison, akkor ez máris másodperceket, akár perceket jelenthet.Egyébként amit felvetettél, abszolút nem eretnek gondolat. Tegyél fel egy MongoDb-t, vagy bármilyen NoSql-t, toljál a hoszting gépedbe pár 10 Gb memóriát, és máris bármilyen lehet az adatbázisod, és még csak lassú se lesz.
-
#2016
martonx
veterán
TaylorXIII
#2014
martonx
veterán
válasz
TaylorXIII
#2014
üzenetére
Segítek: Sqlfiddle
Rajta! -
#1974
martonx
veterán
dellfanboy
#1973
martonx
veterán
válasz
dellfanboy
#1973
üzenetére
ezzel nem leszel kisegítve, de az adattisztítás mindig az egyik legnagyobb szopás. Regexp-el esetleg ki lehetne szedni a fixen 4 jegyű számokat -> irányítószám.
-
martonx
veterán
"Viszont ez durvan 200x lassabb kodot general, mint ha megirnad SQLben, es feladnad rendes querykent, ahol viszont nem biztos, hogy minden esetre gondoltal, es kimaradhat valami..."
Újabb EF-eket (5-6) használva, ezzel azért vitatkoznék, bár nyilván ha valami szuperbrutál 30 soros LINQ kifejezést írtál, akkor azzal elszuttyog a LINQ, míg SQL-t csinál belőle. Egy Entity.Add eset viszont korántsem 200X lassabb, mint egy kézzel megírt, rendesen SqlParameter-ezett SqlCommand.
-
-
#1903
martonx
veterán
dellfanboy
#1900
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?
-
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. -
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.
-
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?
-
#1665
martonx
veterán
Sk8erPeter
#1664
martonx
veterán
válasz
Sk8erPeter
#1664
üzenetére
LOL
-
#1641
martonx
veterán
Sk8erPeter
#1640
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. -
martonx
veterán
-
#1632
martonx
veterán
trisztan94
#1605
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. -
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. -
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. -
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. -
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. -
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. -
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. -
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. -
#1557
martonx
veterán
Sk8erPeter
#1556
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.
-
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? -
#1546
martonx
veterán
DonThomasino
#1545
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.
-
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. -
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.
-
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).
-
-
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. -
#1530
martonx
veterán
DonThomasino
#1527
martonx
veterán
válasz
DonThomasino
#1527
üzenetére
Tényleg csak pár hsz-t kellett volna visszaolvasnod...
-
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. -
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.
-
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. -
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. -
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. -
#1457
martonx
veterán
Sk8erPeter
#1456
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.
-
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. -
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 -
martonx
veterán
Elmondom én, hogy mik hiányoznak az Azure-ból TSQL szinten:
Elosztott tranzakciók
Elosztott lekérdezések
FILESTREAM Data
Beépített Full-Text Search
CLR
Service Broker
Fizikai szerver és katalógus
Adatbázis Mirroring
Extended Stored Procedures
Tábla particionálásEzek egy része már mostanra is deprecated technológia, azaz nem kellene használni. Másik része pedig a felhőből fakadóan felesleges pl. Adatbázis Mirroring. És van ami tényleg hiányozhat ilyen pl. a Full-Text Search, vagy a CLR, ha ezeket használjátok.
-
martonx
veterán
1. mint mondtam az SQL szerverek általános szűk keresztmetszete az IO teljesítmény. Ezen vagy a meghajtók számának növelésével, vagy a meghajtók gyorsaságával (SSD-re cseréjével) lehet segíteni. Ha nem nagyok a DB-k, vagy a pénz nem számít, akkor mindenképpen az SSD-s megoldást javaslom. Ha éjszaka nem dolgoznak a DB szerveren, akkor mehet ezen a mentés, és elég azokat akár egy NAS-on tárolni. Ha éjjel-nappal pörög a DB szerver, akkor jobb, ha egy másik gép végzi a mentést.
2. a programozóid véleménye alapvetően butaság. Valóban nem 100%-os az átfedés az Azure és az SQL Server 2012 között, de ez csak ott jelentkezik, hogy nem tudod egy az egyben áttenni a DB-ket Azure-ra. Mostanra ez már elég szépen dokumentálva van, és ha valaki rászánja azt az 1-2 órát az életéből, és végre ott van a DB Azure-on, akkor már csak egy connection stringet kell kicserélni a programban, és az észre se veszi, hogy DB-t váltottak alatta.
-
martonx
veterán
Én a helyedben két dolgon gondolkoznék el nagyon erősen 300 fő kiszolgálása, kb. 100 egyidejű felhasználó esetén.
1. Venni egy szervert, amiben két processzoros alaplap van, de első körben csak 1 processzort használni benne. Ugyanígy a maximális vinyó számot se használnám ki, hanem mondjuk néhány (minimum 3 ugye) vinyóval egy RAID 5 vagy 10-es tömböt használnék (nem vagyok egy HW-s raid szakértő, hogy melyik a jobb, melyikhez minimum hány vinyó kell, szóval lehet most hülyeséget mondtam). Ekkor a RAID miatt megvan benne a hibatűrés, de a kevés vinyószám miatt az IO elérés lassú lesz. És mondjuk kezdetnek 8-16GB memóriát tennék bele. Ezzel neki lehetne vágni a műveletnek, fokozatosan átterhelni rá a mostani DB-ket, és monitorozni, hogy ez így kb. mit bír, a felhasználók mennyire panaszkodnak? Ha panaszkodnak, akkor lehet látni az adatokból, hogy IO, vagy CPU vonalon kell erősíteni (netán mindkettő). Erős IO használatnál kell a ramot is bővíteni, mert ugye a sok ram csökkenti az IO használatot. És ne felejtsük el, hogy kell egy kis teljesítményű szerver, ami backup-olja az adataidat, ettől helyileg teljesen elkülönítve.
2. Elfelejted az egész hardveres marháskodást és felhőbe viszed az egész cuccot. Ott aztán mindent úgy skálázol, ahogy jónak látod, meg ahogy a pénztárcád engedi. Az AWS-t, vagy az Azure-t javaslom, nekem az Azure-al vannak pozitív tapasztalataim. Mostanában jelent meg a T Systems, meg az Invitel is a saját felhő szolgáltatásaikkal, azokat nem ismerem. A felhő szvsz nem olcsó, de megspórolod a hardver árát, plusz a villanyszámlát havonta, a meghibásodásokat, hardveres kollega fizetését, db admin kollegát (na jó ezt nem teljesen) stb...
-
martonx
veterán
Hány egyidejű felhasználója lesz? A közepes, vagy annál nagyobb teljesítmény nagyon szubjektív. Egy 16 processzoros (processzoronként 6 mag) szerver a maga több TByte memóriájával vajon közepes, vagy komoly gépnek számít? És amikor két szekrénnyi storage van mögötte? És ha 10 ilyen kiépített gép van fürtözve?
Ez a téma iszonyú relatív. Véleményem szerint egy SQL szervernek a legtöbbet a storage számítja. Egy több tucat vinyós (SSD-ről nem is beszélve) storage már elég szép teljesítményre képes. Emellett fontos még a sok memória, mert minél több táblát tud memóriába tartani az SQL annál kevesebbszer kell a vinyókhoz nyúlnia.
Összességében már egy mezei 1 processzoros (ami azért legyen egy modern minimum 4-6 magos processzor) szerver, a bele préselhető maximális vinyószámmal (hasraütés szerűen 8-10, SSD sokszoros gyorsulást jelent a hagyományos vinyókhoz képest), és az alaplapba tehető maximális memória mennyiséggel (szintén hasraütés szerűen 32GB) simán kiszolgálhat egy 1-200 fős céget, feltéve ha az ügyviteli rendszer jól ki van optimalizálva, plusz van kismillió ismeretlen tényező, ami ezt befolyásolhatja.
A sávszélesség is szubjektív, hogy kinek mi a megfelelő. Nekünk pl. 40 mbites dedikált vonalaink vannak a vidéki városokhoz, ezeken keresztül zökkenőmentes az adatok (nem csak adatbázis adatok, hanem komplett internet forgalom) áramlása.
Mivel semmi konkrét infót nem adtál, ezért csak nagyon nagy általánosságokat tudtam leírni. -
-
martonx
veterán
válasz
zolynet
#1395
üzenetére
Egyébként bármilyen csúnya is SQL-ben ilyet használni, de egy While ciklus szerintem erre pont megfelel.
Második sortól kezdve végiglépdelsz rajta, mindig kiveszed az eggyel előző számot, és azt hozzáadod egy 0-ról induló változóhoz.
És továbbra sincs ebben semmi rekurzió. -
martonx
veterán
Szerintem erre nincsen igazán jó szakirodalom. Esetfüggő, hogy mikor mennyire érdemes normálformára hozni, milyen táblastruktúrát érdemes létrehozni, mennyire kell teletömni indexekkel egy-egy táblát stb...
Egy-két SQL optimalizálás problematika elég szokott lenni, hogy felnyissa az ember szemét a DB tervezés alapjaira.
Nagyon általánosságban beszélve: 1. - 2. normálforma elég szokott lenni. Láttam olyan DB-t, ahol még az Igen/Nem is normalizálva volt külön paraméter táblába. Nos, ez már a ló túlsó oldalára átesés.
Ugyanez a helyzet az indexelésekkel. Egy bizonyos szintig nagyon jó, hogy van mindenféle joinokban használt index-ed. Aztán mikor már mindenen index figyel és szegény db motor egy-egy insertnél nem győzi az indextáblákat frissíteni, akkor ez már kontraproduktív.
Nagyon nincs, és nem is lehet általános érvényű tanácsot adni SQL adatbázis tervezéshez. -
martonx
veterán
válasz
lakisoft
#1385
üzenetére
Úgy mondanám, hogy Expressnél biztosan kell instance a szerver névhez.
Enterprise verziónál, ha ugyanazon db szerveren nem fut több különböző instance, akkor elvileg nincs is külön instance jelölés. Kivéve, ha a DB admin direkt úgy állította be, hogy akkor is legyen.
De nem vagyok DB admin, így nem vagyok 100%-kig biztos ez utóbbiban.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Az SQL Job az sql job. A .bat meg egy sima shell kötegfile.
Új hozzászólás Aktív témák
- Viccrovat
- Akciófigyelő: Jelentős kedvezményekkel veheted meg a Xiaomi 17-eket
- Milyen billentyűzetet vegyek?
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- Genshin Impact (PC, PS4, Android, iOS)
- Jövedelem
- Eredeti játékok OFF topik
- Milyen egeret válasszak?
- Battlefield 6
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- További aktív témák...
- Lenovo ThinkPad T480s,14",FHD,i5-7300U,8GB DDR4,256GB SSD,WIN11,TOUCH
- GARANCIÁLIS ASUS TUF F16 // Intel Core 5 210H // 16GB RAM // 1TB SSD // RTX 4050
- 10genes kishibàs pc(i3-10105f/8gb/gt1030/win11/SSD/hdd)
- PANASONIC Toughbook CF-53,i5-3340M,4GB RAM,500GB HDD,DVD,WIN10
- Lenovo LOQ Gamer laptop , R7 7435HS , 24GB DDR5 , RTX 4050
- BESZÁMÍTÁS! Sapphire B650M R7 8700F 32GB DDR5 512GB SSD RX 9070 XT 16GB CM MasterBox 5 fehér 750W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- ÓRIÁSI AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24
- DELL Precision 5540 Workstation i7-9850H Nvidia Quadro T2000 32GB 512GB 15.6" 1év garancia
- iKing.Hu - Apple iPhone 15 Pro Max Black Titanium 100% Akku
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest