Új hozzászólás Aktív témák
-
martonx
veterán
válasz PumpkinSeed #2477 üzenetére
Most komolyan erre mit mondjunk? Vagy a kódódban van valami hiba, vagy a mysql-ed valami elavult verzió, ami ráadásul egy roncs instbil gépen fut. Vagy mindkettő. Nyilván normális esetben ez lehetetlen lenne.
Én egyébként ismerve a hszeidet, biztosra veszem, hogy a kódodban lesz a hiba, és nem a mysql-ben. De egy Pentium 3-ason futó MySql-től is kitelhet bármi.Én kérek elnézést!
-
martonx
veterán
válasz PumpkinSeed #2483 üzenetére
Hehe, így legyen 5-ösöm a lottón. Mondtam én, hogy a kódoddal lesz a hiba.
Én kérek elnézést!
-
martonx
veterán
válasz DNReNTi #2540 üzenetére
beleokoskodhatok én is?
Amellett, hogy abszolút egytértek veled, ha már nevezéktanról beszélünk, akkor nem kellene rövidítéseket használni pl. _nm
Még most is gondolkozok rajta, hogy mit jelenthet az az nm? Ráadásul abból, hogy size_and_price bőven látszik, hogy miről is szól az a tábla.
Aztán szerintem az alulvonósdi elég idétlen az SQL nevezéktanokban (html-ben persze tökéletes az alulvonás, de ez most SQL). Miért nem lehet simán SizeAndPrice-nak hívni a táblát? Ez totál szubjektív, de szerintem sokkal szebb felesleges alulvonások nélkül.Én kérek elnézést!
-
martonx
veterán
válasz jocomen #2567 üzenetére
A join-ok szvsz átláthatóbbak, és talán (ez persze nagyban függ az sql motortól) jobban lehet őket optimalizálni, mint egy rakás where paraméterbe rejtett subquery-t.
Elméletileg az sql motor ugyanazt a végrehajtási tervet kellene, hogy készítse mindkét esetben, gyakorlatilag pici apróságokon is tud múlni, egy - egy sokkal optimálisabb terv felbukkanása.Én kérek elnézést!
-
martonx
veterán
válasz fordfairlane #2648 üzenetére
Én meg lokálisan nem futtatok DB-t, csak felhőből. Így a 4 fejlesztői gépem között a DB-t legalább nem kell szinkronizálgatni.
Én kérek elnézést!
-
martonx
veterán
Tűrhető. Maga az sql az tök gyors, csak van egy pár másodperces késleltetése. Ami egyébként kb. észrevehetetlen egészen addig, míg a lokális gépedről be nem akarsz insertelni pár száz sort egyenként Ugye ilyenkor mindegyik inserthez ha számolunk 1-2 mp késleltetést, akkor az 100 insertnél már 100-200mp. Átlag selecteknél, amik az sql-en 0,1mp-ig futnak, felhőből meg mondjuk 1,1mp szerintem ez simán vállalható. Ha meg komolyabb selectet futtatsz, az az 1-2mp tényleg elenyésző - mondjuk 30mp helyett 31.
Szóval vannak olyan speciális esetek, amikor tud fájni, de lássuk be, nem túl gyakori, hogy saját gépről egyenként toljuk be az adat sorokat több száz, több ezer számra.
Az észak-európai központ úgy saccra legalább 1000km-el közelebb van, mint a nyugat-európai (hollandia vs írórszág), így a késleltetése is jobb.Én kérek elnézést!
-
martonx
veterán
válasz DNReNTi #2697 üzenetére
Igaziból 100K-nyi adat annyira kevés, hogy édesmindegy, hogy melyik verziót választjátok. Ez csak magán vélemény, de az sql adattárolás nem olyan mint egy programkód, azaz ami össze tartozik, és 1 - 1 kapcsolat van közöttük mint esetedben a user neve, jelszava és a user lakcíme, azt semmi értelme csak azért szétbontani, és a másik táblában is elkezdeni egy userID-t vezetgetni, indexelni, meg view-t írni föléjük, hogy mégis egynek látszódjanak stb... mert szeparáljuk minél több, minél kisebb részre az adatokat. Ez SQL adattárolás nem pedig OOP programozás.
És ez nem azt jelenti, hogy ne legyen legalább első normálformára hozva a DB struktúra, csak éppen minek csináljunk felesleges roundtripeket, ha ezek az adatok úgyis összetartoznak.
Persze, hogy ez mennyire eset függő, mert simán tudok magam ellen is érvelni, mikor valakinek több száz Gb-os táblái vannak, és minél jobban partícionálni akarja őket, akkor meg pont az lehet a jó, ha több felé van osztva az adattartalom, mert akkor a cluster több része nagyobb párhuzamossággal tud dolgozni a táblán (mondjuk pár száz millió rekordnál egy rosszul elsült update is ki tudja lockolni az egész táblát), de mondjuk egy szál nagy tábla particionálására is megvannak a módszerek.
Száz szónak is egy a vége, ilyen kevés adatnál teljesen mindegy melyik verziót választjátok, én személy szerint nem kezdeném bonyolítani az egyszerűt.
Én kérek elnézést!
-
-
martonx
veterán
-
martonx
veterán
válasz pityaa23 #2782 üzenetére
Első ránézésre már nem vészes.
Pár észrevétel:
1. a táblád nevei nagyon bénák. Alapanyag, meg alapanyagok? Eleve mindent angolul nevezünk el, a kapcsolat táblákat pedig valahogy úgy illik elnevezni, hogy a nevéből is látszódjon, hogy mit kapcsol össze mivel.
2. Az étkezést tovább bontanám ételekre, mert egy ebéd pl. jó eséllyel áll levesből és főételből.
3. hiányolom a mennyiségi egységet az alapanyagokból. Nem mindegy, hogy 1 liter, vagy 1 kg.Én kérek elnézést!
-
martonx
veterán
Sziasztok!
Keresnék szabadúszó MS SQL fejlesztőt. Néhány órás munkáról lenne csak szó (egy szakértőnek, ennek megfelelő díjazásért). Én is meg tudnám csinálni, de nem akarom magam tovább aprózni
Priviben várom a jelentkezőket!
Én kérek elnézést!
-
martonx
veterán
válasz TomyLeeBoy #2854 üzenetére
szerintem az üres karakterrel ezt fogod elérni, de azért joker karakternek nem nevezném.
Én kérek elnézést!
-
martonx
veterán
válasz TomyLeeBoy #2856 üzenetére
Belegondoltál-e már abba, hogy amit szeretnél, azt nem így kellene megoldani? Gondolom PHP-ban ügyködsz, és van egy összekonkatenált sql query-d, aminek a végén mindig ott van ez a where.
De miért van ott, amikor bizonyos esetekben egyszerűen nem kellene, hogy ott legyen? Alakítsd át a kódodat, és ha már átalakítod, akkor a konkatenálást is csináld meg normálisra.Én kérek elnézést!
-
martonx
veterán
válasz BigBlackDog #2865 üzenetére
Nem az a kérdés, hogy mennyi adatot kellene tárolni NoSql-ben (jelzem havi 100 millió adat nudli, bármelyik TSQL-nek is, már ha nem egy Pentium 4-esen futtatod, 1Gb ram mellett), hanem az a kérdés, hogy milyen komplex lekérdezéseitek, riportjaitok lesznek.
Addig aranyos dolog a NoSql, amíg csak tolja bele az ember az adatokat, de amikor azokat ki is kellene szedni, netán bizonyos relációkat megvalósítani, akkor elég gyorsan ki fog derülni, hogy csodák nincsenek.
Ettől még igenis van létjogosultsága a NoSql-nek bizonyos területeken, csak jelezni akartam, hogy amikor döntötök, akkor több szempontot is vegyetek szemügyre, ne csak a havi 100 millió rekordot, ami egyébként abszolút nem sok, még ha nektek soknak is tűnik elsőre.
Ha meg a hype miatt szeretnétek NoSql-t, akkor érdemes megnézni a NewSql-eket is, mert ez a legújabb hype: [link]Én kérek elnézést!
-
martonx
veterán
válasz half333 #2871 üzenetére
Ja várjál már, ne viccelődjünk. Nem írtad, hogy te eddig SQL 2000-rel szórakoztál, fel se tételeztem, hogy SQL 2005-nél régebbit bárki is használ manapság pár nagybankon kívül (vagy talán már ők sem).
Hát ez zseniálisMiért nem akarsz rögtön clipper-es adatbázist - vagy mi is volt annak idején a dos-os förmedvények alatt - futtatni a 2015 augusztusában kijött win10 alatt?
De hogy konstruktív is legyek, én a helyedben tennék fel egy virtuális gépben windows XP-t, arra simán fel kell tudnia menni az SQL 2000-nek. Más kérdés, hogy jó sok erőforrásba fog kerülni a gépeden csak azért virtuális gépet futtatni, hogy végül azon fusson az SQL 2000, és még jóval lassabb is lesz, mint eddig.
[ Szerkesztve ]
Én kérek elnézést!
-
martonx
veterán
válasz harylmu #2895 üzenetére
1. ne viccelődjünk már, MS SQL-t rohadtul nem generate scripttel kell backupolni, hanem a backupolás funkcióval, ami meglepő módon pont erre van kitalálva. Akár még tömöríti is neked közben az adatot. Tudom durván el van rejtve, a te képernyőmentéseden pl. a totál váratlan Back Up menü pont néven szerepel 5-tel a Generate Script felett.
2. a select count nem erre való, noha rossz gyakorlatként gyakran használják erre. Nálunk pl. a legnagyobb táblában lévő pár milliárd sornál, ha kiadsz egy select count-ot, akkor simán leáll a 64 magos, 256Gb-s szerver is. Ellenben van egy rakás analitikai beépített függvény, simán le tudod kérni az összes tábla adatait. Mondjuk így: [link]
Én kérek elnézést!
-
martonx
veterán
válasz harylmu #2897 üzenetére
Ja vár, elsiklottam a felett, hogy te csak egy darab táblát akarsz backupolni. A backup az a komplett DB backupra jó, bár lehet, hogy meg lehet neki mondani, hogy csak egy táblát akarsz backupolni, még sose próbáltam csak egy táblát backupolni vele.
Másrészt ha ugyanazon DB-n belül akarsz backupolni, akkor miért nem:
insert into backuptabla
select *
from eredetitablavagy select * into backuptabla from eredetitabla
hirtelenjében nem tudom melyik a nyerő szintaxis.
Én kérek elnézést!
-
martonx
veterán
válasz Agostino #2913 üzenetére
Jelzem az Excel direktben le tud kérdezni adatbázisokból is, szóval ezt a lekérdezem majd átforgatom excelbe lépést illik tudni megspórolni.
És ha már direktben lekérdez, akkor semmi se tarthat vissza, hogy a lekérdezéseidre beállíts automatikusan frissülő diagram-okat, pivotokat, amit csak akarsz, és voilá.Én kérek elnézést!
-
martonx
veterán
válasz Apollo17hu #2916 üzenetére
Ha nincs módja az excellel direktben lekérdezni az adatokat a DB-ből, akkor excel makróval se fogja azt tudni elérni. És ezen még a gugli se fog tudni segíteni neki
Én kérek elnézést!
-
martonx
veterán
válasz zolynet #2920 üzenetére
Vagy nekiállnak valamilyen BI rendszert használni. PL. a Microsoft Office-ban lévő Power BI mostanra egészen elképesztő tudású. És még sokba se kerül (relatíve persze), mert az Office árában benne foglaltatik a 2013-as verziótól kezdve. Persze egy ilyen önkiszolgáló BI használata előtt se árt egy pár százezres képzésen részt venni, hogy mégis eszik-e vagy isszák.
Én kérek elnézést!
-
martonx
veterán
-
martonx
veterán
válasz half333 #3006 üzenetére
SQL 2000 után SQL 2014? Elég erős váltás
Server name-nél alapból nem ír ki az SSMS semmit, mivel hehe, neked kell beírnod, hogy mégis melyik szerverhez szerenél kapcsolódni. Localban ez localhost, vagy csak simán '.'
Utána, amikhez már sikeresen kapcsolódtál, akkor azokat a server name-eket megjegyzi, és alapból be fogja írni neked.Én kérek elnézést!
-
martonx
veterán
válasz half333 #3008 üzenetére
Bevallom évek óta nem futtatok elvből SQL szervert lokálisan, csak felhőből (esetemben Azure SQL). SSMS-t is csak a melóhelyen használok, kezdek egyre inkább átszokni a Visual Studio Data Tools-ra. De a 2,5 évvel ezelőtti emlékeim szerint az SQL Server 2012 telepítése win8 alá next-next-finish módon ment, szóval nagyon nem értem a problémádat.
Egészen biztos vagyok benne, hogy win10 + SQL Server 2014 (lehet, hogy időközben kijött a 2016 is?) telepítése is next-next-finish bonyolultságú, de most csak a te kedvedért nem fogok magamhoz SQL szervert telepíteni, csak hogy bizonyítsam az igazam.Szóval nem értem milyen megoldást keresel, milyen problémára? Itt van egy mini tutorial, hogy hogy kell kapcsolódnod a szerverhez az SSMS-el: [link]
Szerk: mire megírtam a hosszú hsz-emet, látom sikerült is megoldanod.
[ Szerkesztve ]
Én kérek elnézést!
Új hozzászólás Aktív témák
- Asztalos klub
- PC-re tart a God of War Ragnarök?
- Már nem hisz a nagy európai EV-forradalomban a Ford
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Google Chromecast topic
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- PlayStation 5
- Konzolokról KULTURÁLT módon
- Fűnyíró topik
- PayPal
- További aktív témák...
- Tyű-ha Lenovo Thinkpad X1 Carbon Profi Érintős Laptop 14" -50% i7-10610U 4Mag 16GB/512GB FHD IPS
- 3D bérnyomtatás és egyedi megrendelések teljesítése PLA, PETG anyagokból 70+ színárnyalattal!
- Nikon D5300 + objektív, makulátlan vadonatúj állapotban
- Új LENOVO THINKBOOK 13s G3 "Kis Gamer" Ultrabook 13,3" -40% Ryzen 5 5600U 8/512 WUXGA IPS RADEON 2GB
- -100e Ft Dell Latitude 5440:i5 1345U,16GB,512GB,Iris Xe,vil.MAGYAR bill,Win11, 3 év Dell NBD gari
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Promenade Publishing House Kft.
Város: Budapest