Új hozzászólás Aktív témák
-
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
martonx
veterán
-
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.
Én kérek elnézést!
-
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
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.
Én kérek elnézést!
-
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?
Én kérek elnézést!
-
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.Én kérek elnézést!
-
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.
Én kérek elnézést!
-
martonx
veterán
MSSQL-es tapasztalat alapján az SSD brutálisan meg tudja dobni az összteljesítményt. Sőt, még annál is jobban. Igaziból nem is az a lényeg, hogy szekvenciálisan gyorsabb írás, olvasásban az SSD, hanem IOPS-ben egy szál SSD tud annyit, mint egy rack szekrénnyi HDD.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
martonx
veterán
-
martonx
veterán
-
martonx
veterán
válasz Apollo17hu #2207 üzenetére
Jobbnak nem jobb, csak leírva rövidebb, mint egy jó hosszú case when.
Én kérek elnézést!
-
martonx
veterán
válasz Apollo17hu #2211 üzenetére
Esetleg ha sqlfiddle-re tennél fel példát, akkor el is tudnánk mélyedni benne az ötletelés helyett.
Én kérek elnézést!
-
martonx
veterán
válasz PumpkinSeed #2239 üzenetére
Van két adathalmazod. Az egyik SQL táblában, a másik meg egy szöveg fileban mondjuk vesszővel elválasztva.
Mit teszel, ha a kettő közös metszetét kellene meghatároznod?
Persze elkezdheted mindkettőt lekérni, majd memóriában for-okkal összeforgatni, és ifekkel ellenőrizni.
Vagy fogod, feltöltöd a csv-det egy ilyen external táblába, és egy szimpla sql select-el megkapod a közös halmazt.
Kapisgálod, hogy mire jó ez?Én kérek elnézést!
-
martonx
veterán
válasz PumpkinSeed #2277 üzenetére
Sémákkal tudsz adatbázisokat / adatbázis részeklet elkülöníteni. Olyan ez, mint programozásban a namespace.
Sequence: már a nevében benne van, hogy mi ez, és mire jó. Nem fogod kitalálni, egy folyamatosan növekvő számláló. Hogy mire jó azt a képzeletedre bízom, pl. adatbázis sorokat azonosítani.
Én kérek elnézést!
-
martonx
veterán
válasz bambano #2385 üzenetére
A sorokat össze tudod húzni persze. Mondjuk minden sornak te adsz egy növekvő azonosítót (MSSQL-ben ez a RANK), és ez az azonosító alapján joinolod össze a táblát saját magával eggyel elcsúsztatva egymáshoz képest.
Ezután a dátumok kivonása már gyerekjáték, azt meg nem írtad, hogy hogy akarod súlyozni a végeredményt, de szerintem minden adott a feladatod megoldásához.Én kérek elnézést!
-
martonx
veterán
válasz Apollo17hu #2387 üzenetére
Ez egy fokkal szebb megoldás az általam javasoltnál
Én kérek elnézést!
-
martonx
veterán
válasz Agyasima #2406 üzenetére
Akkor a join-olásra vagy kíváncsi inkább? Vagy linkeljünk be egy SQL kezdőknek könyvet?
Egyáltalán kezdjük az elején, milyen SQL-ről beszélünk? MSSQL, MySql, PostgreSql, Oracle stb...Én kérek elnézést!
Új hozzászólás Aktív témák
- Eladó konfig! Ryzen 5 5600X 512GB M.2 SSD 16GB DDR4 RTX 3060Ti 8GB!
- MacBook Pro Retina 13" M1 Chip / 16GB RAM / 2TB SSD / Magyar / 60 nap garancia
- Apple Watch S9 41mm Pink Aluminum, bontatlan
- HP 27-cr0757nz - ÚJ 27"-os FullHD All-IN-ONE PC - i7-1355U, 32GB, 1TB SSD, W11, 300nit
- Eladó Fujifilm X100T fekete
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen