- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Megjelent a Poco F7, eurós ára is van már
- Samsung Galaxy Watch6 Classic - tekerd!
- Realme 9 Pro+ - szükséges plusz?
- iPhone topik
- Poco F6 5G - Turbó Rudi
- Honor Magic5 Pro - kamerák bűvöletében
- Hammer 6 LTE - ne butáskodj!
- Yettel topik
- Google Pixel topik
Új hozzászólás Aktív témák
-
martonx
veterán
Egyrészt szépen felépített adatbázis lehet, ahol ugyanazon témához érdemi információ keresés történhet 10 táblában 200 oszlopban
![;]](//cdn.rios.hu/dl/s/v1.gif)
Másrészt én csinálnék egy jó nagy kereső scriptet (vagy inkább használnék valami kész kereső engine-t, mint pl. Lucene), ami X másodpercenként szépen végignyalná azt a 10 táblát, azoknak mind a 200 oszlopát. És egy külön eredmény táblába betolná az eredményeket. Így végül, amikor a tényleges keresés történik az gyors tud lenni, igaz a megjelenített adatok nem lesznek másodpercre pontosak.
-
martonx
veterán
Ugyan nem mondtad, de az előzményekből sejtem, hogy admin vagy a mysql-edben, sőt a gépen is, ahol a mysql fut.
Így aztán eddig biztos elkerülte a figyelmed, hogy a mysql telepítésnél egy olyan is felkerült a gépre, hogy mysql console vagy valami ilyesmi a neve. Nos ez nem poénból került fel, hanem pont az ilyen esetekre. -
#1524
martonx
veterán
TomyLeeBoy
#1523
martonx
veterán
válasz
TomyLeeBoy
#1523
üzenetére
Jaja, bármilyen idétlen apróságon múlhat. Saját tapasztalat, hogy a PHP + MySql kombó windows-on IIS-el gyorsabb, mint Linux-on Apache-al.
-
#1522
martonx
veterán
TomyLeeBoy
#1520
martonx
veterán
válasz
TomyLeeBoy
#1520
üzenetére
Normálisan konfigolt windows és linux szerver között nulla sebességkülönbségnek kellene lennie (sőt pusztán webszerver oldalról nézve az IIS mintha egy fokkal hatékonyabban futtatna PHP-t, mint az Apache).
A mysql-t be kellene konfigolni rendesen, az 1,3 Gb-nyi foglalt memória beszédesen kevés lenne egy jól konfigolt MySql esetében. -
#1518
martonx
veterán
TomyLeeBoy
#1516
martonx
veterán
válasz
TomyLeeBoy
#1516
üzenetére
42
-
#1508
martonx
veterán
Ra's al Ghul
#1506
martonx
veterán
válasz
Ra's al Ghul
#1506
üzenetére
Szvsz nagyon szerencsétlen felállás, ha egynél több MySQL fut egy szerveren. Mivel a két verziónak osztoznia kell az erőforrásokon. Nem hiszem el, hogy 5.1-ről 5.5-re migrálni akkora feladat lenne.
-
-
#1468
martonx
veterán
Sk8erPeter
#1467
martonx
veterán
válasz
Sk8erPeter
#1467
üzenetére
Igazad van nem ildomos, de feladat függő, szóval ha jól értettelek, akkor ebben az esetben ez így jó lesz.
-
#1451
martonx
veterán
fordfairlane
#1449
martonx
veterán
válasz
fordfairlane
#1449
üzenetére
A kérdéses táblán 4 index is volt, csak éppen aki indexelt, béna volt.
Most kettő index van már csak rajta, de legalább azok jók. -
martonx
veterán
Múltkor szó volt itt arról, hogy a helyes indexelés mennyire jó, mennyire nem számít. Jelentem, az előbb egy egészen szimpla MySQL query-t találtam, ami 100%-on járatta a disk-et, és annak ellenére, hogy nem nagy tábláról volt szó (csak 1.5 millió sor, 240Mb-nyi a tábla), mégis egy egyszerű select 70 másodpercig futott rajta.
Javított indexeléssel ez lement 0,25 másodpercre. Tovább finomított indexeléssel lement 0,18-ra. Szóval végeredményben a 70 másodpercből lett 18 század másodperc. Még mindig lehetne rajta szépíteni, de innen már sokat úgyse lehetne nyerni. A disk pedig éppen csak megrebben 1-2%-on, amikor fut a select.
-
martonx
veterán
Ha ez úgyis tárolt eljárás (amire persze egyesek szerint úgy sincs semmi szükség), akkor tedd meg azt, hogy az alselect-et bedobod egy temp táblába, a temp tábla range_id-jére pedig teszel egy index-et (amivel egyesek szerint úgyse gyorsul számottevően semmi). Ezzel, ha minden igaz, drasztikusan le tudod redukálni a futásidőt.
-
#1382
martonx
veterán
Sk8erPeter
#1381
martonx
veterán
válasz
Sk8erPeter
#1381
üzenetére
Ez igaz, de tudod mikor jut eszedbe minden évente, vagy két évente utánhúzni?
Mi pont idén szívtunk ezzel, amikor 5 évvel ezelőtt 5 évre előre belőttük az adatokat, aztán valamikor májusban tűnt fel elöször, hogy év eleje óta szarul számol pár algoritmus. -
#1376
martonx
veterán
Sk8erPeter
#1373
martonx
veterán
válasz
Sk8erPeter
#1373
üzenetére
Nem is konkrét buktatókra gondoltam, hanem pl. az összes ünnepnapot, különös tekintettel a mozgó ünnepekre, mondjuk húsz évre előre meghatározni, elég babra munka tud lenni.
Azaz a végeredmény nem annyi, hogy egy szép nagy insert-tel feltöltesz minden napot, hanem utána az ünnepnapok, munkaszüneti napok, munkanap áthelyezések, hosszú hétvégék a macerásak. -
#1371
martonx
veterán
fordfairlane
#1370
martonx
veterán
válasz
fordfairlane
#1370
üzenetére
Az esetleges fellengzős hozzászólásomért veled ellentétben én bocsánatot kértem. Arról pedig nem vagyok hajlandó flame-et folytatni, hogy bizonyos esetekben (bizonyos szektorokban ezek a bizonyos esetek mindennapiak, más szektorokban meg szökő évente jönnek csak elő) miért nélkülözhetetlen egy jól megírt tárolt eljárás.
-
#1369
martonx
veterán
fordfairlane
#1368
martonx
veterán
válasz
fordfairlane
#1368
üzenetére
Nem én írtam butaságot, hanem te, szóval elég lett volna vagy csak simán csöndbe maradnod, vagy bocsánatot kérni szmegma-tól, ha a beírásod miatt ismét hetekig próbálkozik tovább tárolt eljárás nélkül.
Ha esetleg arcoskodóra sikerültek volna az előző hozzászólásaim, akkor elnézést kérek mindenkitől.
Az, hogy használjunk-e tárolt eljárásokat vagy sem, örök vitatéma, hetekig lehetne flamelni róla. Az esetek jó részében valóban el lehet lenni nélküle, viszont pont az szmegma-féle komplexebb lekérdezéseknél meg megkerülhetetlen a használata.
-
#1367
martonx
veterán
fordfairlane
#1366
martonx
veterán
válasz
fordfairlane
#1366
üzenetére
Hehe, ez vicces megjegyzés volt. Attól, hogy te még nem használtad, ugyan próbálj már meg komolyabb logikát összerakni SQL-ben tárolt eljárás nélkül. Elhiszem, hogy kismillió olyan projekt van, amikben a két táblás alkalmazásnál a select * from tábla a maximum, amit használni kell. Ettől még hidd el vannak akik főállásban tárolt eljárásokat írnak, és nem azért mert éppen olyanjuk van.
-
martonx
veterán
válasz
szmegma
#1360
üzenetére
Hirtelenjében két módszer jutott az eszembe.
1. While ciklussal - SQL-ben ez nem túl szép, de ez pont az az eset, amikor érdemes használni.
2. Csinálsz magadnak egy naptár táblát, amibe pár évre előre eltárolod a napokat, hétvégéket, munkaszüneti napokat.Ismerve, hogy ez mihez kell neked, én a második megoldást javaslom, noha nem kis munka egy tisztességes naptár táblát összerakni pár évre előre magadnak.
-
#1358
martonx
veterán
Sk8erPeter
#1357
martonx
veterán
válasz
Sk8erPeter
#1357
üzenetére
Ez igaz, csak engem zavar, hogy akármikor benézek, mindig látom, hogy MySQL topikban esemény volt, aztán ide kattintva látom, hogy már megint egy 800 soros hsz. érkezett.
Persze azon el lehet témázni, hogy mi illik ide, meg mi nem. Szvsz a hogyan kell mysql-t telepíteni, meg miért fut le hibásan a select * from table lekérdezésem nem illik ide, mert aki ilyet kérdez, az meg se próbálja az agyát / guglit használni.
Ugyanakkor van az a szakmai mélység is, ami szintén nem illik ide, egyszerűen nem hiszem, hogy egy olyan komplexitású feladat, aminek a normális megfogalmazása, példa adatostól, egy - két alap lekérdezéssel több A4-es lapot venne igénybe, annak a megoldását egy fórum keretein belül kellene kiszenvedni.
Ráadásul most borítékolom, hogy a megoldás sem egy húsz soros sql script lesz a végén, ergo a topik tényleg semmit nem fog profitálni belőle.
Apollo-nak valóban nagy riszpekt érte, hogy ingyen ennyit segít, nem is ellene szólt az észrevételem, csak jeleztem, hogy ha ennyire ráér, meg ennyire érdekli a probléma, akkor vegye fel a kapcsolatot direktben szmegma-val, aztán skypeozzanak, emailezzenek, oldják meg egymás között. -
martonx
veterán
válasz
szmegma
#1317
üzenetére
Ez a szokásos, hogy kell a select * from táblát lefuttatni php-ben kérdések szintjét meghaladja
Két lehetőséged van:
1. használod az sqlfiddle-t, és létrehozod a táblákat, példa adatokkal, aztán várod a jószerencsét, hogy hátha valaki megszán, és helyetted beleteszi azt a pár órányi sql szakértői munkát.
2. eleve pénzt jánlasz ezért, és akkor biztosan lesz aki beleteszi azt a pár órányi sql szakértői munkát. -
#1315
martonx
veterán
Brown ügynök
#1314
martonx
veterán
válasz
Brown ügynök
#1314
üzenetére
Ez sok mindentől függ. Mennyire komplex például az index, mennyi indexed van a táblán stb...? Ha komplex, és sok az index akkor az írást lassítja.
Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.
Az írás tűnik lassúnak vagy az olvasás? Mert ha az olvasás a lassú, akkor viszont mindenképpen kell az index, különben nélküle meg megállna az élet. Még ha ez miatt némileg lassul is az írás.
Szóval igazán jó válasz nem biztos, hogy van a kérdésedre.
Kérdés az is, hogy mit értesz azonos mennyiségű írás, olvasásnak? Naponta 100 sort beírsz, és 100 sort ki is olvasol? Vagy hogy naponta 100-szor olvas valamit a táblából, és 100-szor ír valamit a táblába a db motor? Ez esetben a valamit az érdekes, hogy 100-szor beír 1 sort, vagy 100-szor beír 2000 sort?
Ez esetben pl. az írási stratégiáján a programnak érdemes lehet változtatni. -
#1313
martonx
veterán
Brown ügynök
#1312
martonx
veterán
válasz
Brown ügynök
#1312
üzenetére
Azt azért tartsd észben, hogy a MySQL optimalizációnál erősen meglőnek, ha eleve nem jól beállítva telepítik fel.
Úgyhogy vagy neked kell egyben a rendszergazdának, DBA-nak is lenned, vagy utólag simán előfordulhat az az eset, hogy marhára nem fogsz tudni mit optimalizálni, mert a telepítéskor elcseszett setup miatt egyszerűen mindeféle diagnosztizáló funkció le van tiltva rajta.
És ezeken utólag nagyon nem szeretnek a rendszergazdák változtatni. -
martonx
veterán
Híjnye, jól látom, hogy a MySQL-lel hivatalosan nem lehet %-ot megadni a Limitnek? Pedig ez PostgreSQL-ben, MS SQL-ben (gondolom Oracle-ben is) támogatott.
Mindegy itt egy kerülő megoldás:SELECT*
FROM (
SELECT list.*, @counter := @counter +1 AS counter
FROM (select @counter:=0) AS initvar, list
ORDER BY value DESC
) AS X
where counter <= (10/100 * @counter);
ORDER BY value DESC -
#1307
martonx
veterán
Brown ügynök
#1306
martonx
veterán
válasz
Brown ügynök
#1306
üzenetére
Mondjuk jobban utána gondolva az e pont azért okozhat némi teljesítmény problémát (MySQL sosem volt sebesség bajnok, pláne nem a korai verziói), illetve bizonyos esetekben a d pont is bezavarhat, bár ezt nem tartom túl valószínűnek.
-
#1305
martonx
veterán
Peter Kiss
#1304
martonx
veterán
válasz
Peter Kiss
#1304
üzenetére
Az f pont biztos nem, a g-t, h-t nem részletezted.
-
#1299
martonx
veterán
kornyiktamas
#1298
martonx
veterán
válasz
kornyiktamas
#1298
üzenetére
A klasszikus publikus hosztingok nem engednek távolról hozzáférni a Db-hez.
Ami neked kell az egy virtuális szerver. Erre azt telepítesz, amit csak akarsz, és onnan férsz hozzá ahonnan akarsz. Azure, AmazonWs, Google Engine, vannak magyar virtuális szerver hosztingok is, válassz közülük. -
#1297
martonx
veterán
kornyiktamas
#1296
martonx
veterán
válasz
kornyiktamas
#1296
üzenetére
Ingyenes MySql kell? Telepíts egyet a gépedre lokálisan
-
martonx
veterán
válasz
spammer
#1285
üzenetére
"és írjak nyugodtan csillagot" - nos ezt éppen el kellene kerülni. Írhatsz a count-on belül bármit, én pl. count(1)-et szoktam, de a * használatát kerülni kellene, mert minden esetben plusz munkát jelent az SQL motornak a * feldolgozása (countnál talán éppen nem, de nem kellene rossz szokásokat felvenni).
-
martonx
veterán
válasz
Jester01
#1270
üzenetére
"Azt kétlem, hogy egyetlen BIT mező tárolásához ne foglalna le legalább egy byteot. Esetleg ha több ilyen mező van egy rekordban akkor összepakolhatja őket." - ez igaz, ez annyival árnyalja a képet, hogy a helymegtakarítás nem feltétlenül jön elő.
Viszont kettő plusz szempontot még mondok a bit mellett. 1. amikor lehetséges méretcsökkenésről beszélünk ott ne csak a tábla által elfoglalt helyet vegyük figyelembe, hanem könnyebben, több mindent tarthat a memória pufferében az SQL motor, illetve az adatok átadásakor is megjelenik a kisebb méretből fakadó előny. Nem mindegy, hogy egy SQL lekérésre 100.000 byte-ot, vagy 100.000 bit-et kapunk vissza.
-
#1269
martonx
veterán
Peter Kiss
#1267
martonx
veterán
válasz
Peter Kiss
#1267
üzenetére
Plusz milliós nagyságrendű soroknál már jelentős helyet tudsz megtakarítani. Ha az a meződ index, akkor a hely megtakarítás máris duplázódik.
-
#1214
martonx
veterán
Brown ügynök
#1213
martonx
veterán
válasz
Brown ügynök
#1213
üzenetére
A kivétel táblát subquery-ként kellene hozzácsapnod, mert így descartes szorzat keletkezik a product_id-k alapján.
-
-
-
-
#1129
martonx
veterán
Apollo17hu
#1127
martonx
veterán
válasz
Apollo17hu
#1127
üzenetére
No látom megelőztél, ráadásul komplett megoldással. Akkor emberünk copy-paste-val megoldja a háziját, és megint nem tanul semmit
-
martonx
veterán
válasz
DanielK
#1126
üzenetére
select product_id, max(date) date from prices group by product_id megadja neked az egyes product price-ok közül a legutolsó dátumát.
Ezet felhasználva már meg fogod tudni oldani a lekérdezést 1-2 join-nal. Mivel házi, direkt nem adok teljes megoldást, hagy gondolkozz rajta kicsit te is. -
-
#1101
martonx
veterán
Sk8erPeter
#1100
martonx
veterán
válasz
Sk8erPeter
#1100
üzenetére
ööö ez igaz
-
#1099
martonx
veterán
Sk8erPeter
#1098
martonx
veterán
válasz
Sk8erPeter
#1098
üzenetére
php-s méretkorlát problémába biztosan nem futsz vele
-
#1097
martonx
veterán
Sk8erPeter
#1096
martonx
veterán
válasz
Sk8erPeter
#1096
üzenetére
hehe, no ilyenkor tud jó lenni a Toad for MySQL
-
martonx
veterán
válasz
lakisoft
#1074
üzenetére
Mondom alapból 90 napos trial jár.
De ha előtte webspark-on regisztrálsz (linket nem adok, írd be gugliba: webspark), akkor időlimit nélküli ingyen 1GB database, meg 30Gb storage, meg hasonló jóságok járnak a webspark tagsághoz. Én is így használom.
Ha meg jogosult vagy bizspark-ra, akkor évi több száz dollárnyi Azure cuccot kapsz ingyen, az ingyenes full MS ökoszisztéma mellé. Persze a bizspark szvsz úgy lett kitalálva, hogy kb. senki ne legyen rá jogosult, viszont minél nagyobb legyen a hírértéke, hogy elméletileg mennyi mindent adna ingyen az MS. -
-
martonx
veterán
válasz
laracroft
#1034
üzenetére
Az alap SQL kérdéseket már el se szoktam olvasni, de látom egy ideje nem kapsz választ. Tessék:
SELECT ugyfel.account AS account,
ugyfel.line AS line,
COUNT(1) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
GROUP BY account,line
ORDER BY darab DESC -
martonx
veterán
Mert a böngészőből meghívott webszerver ugyanazon a gépen futhat, amin a MySQL. Így e kettő lokálisan tud kommunkálni egymással. Amit pedig te akarsz az egy másik gépen futó perl alkalmazás, ami érthető módon nem tud lokálisan kommunikálni, hanem csak távolról.
Nos ezt a távoli elérést kell engedélyezned a MySQL-es gépen, MySQL konfigban, tűzfalon stb... -
#1032
martonx
veterán
Sk8erPeter
#1020
martonx
veterán
válasz
Sk8erPeter
#1020
üzenetére
CMS-nél tényleg hasznos lehet bizonyos esetekben egy ilyen feature. Én mondjuk olyan mélységben sose használtam CMS-t, mint te. Ellenben én meg minden táblámat ismerek, azaz fel sem merül, hogy vajon hol melyikben kezdjek keresni egy-egy értéket.
-
#1019
martonx
veterán
Sk8erPeter
#1018
martonx
veterán
válasz
Sk8erPeter
#1018
üzenetére
bocs, félreértettelek. Fel se merült bennem, hogy valaki ilyet akarna tenni, hogy egy DB összes táblájában keresni akar valamit. Miért teszel ilyet? Ha van jópár több millió soros DB-d, akkor azok mennyire szeretik vajon ezeket a fajta kereséseket? És miért jó az, ha két óra múlva kapsz mondjuk egy választ, de cserébe megölted a komplett SQL szervert az ártatlan kereséseddel?
Az, hogy egy GUI ilyen kényelmi funkciót biztosít, szvsz inkább hátrány, mint előny. -
#1017
martonx
veterán
Sk8erPeter
#1016
martonx
veterán
válasz
Sk8erPeter
#1016
üzenetére
ööö lehet én vagyok kocka, de ezekere a keresésekre vannak beépített SQL táblák, amik megmutatják a DB szerkezetét. Erre való az information_schema.
-
martonx
veterán
válasz
laracroft
#998
üzenetére
Ötlet látatlanban:
1. csinálsz egy alselectet:
select account, line, leiras, min(ido) as minido, max(ido) as maxido
from naplo
where LEIRAS like '%Helyszínen%' or LEIRAS like '%Leellenõrizve%'
group by account, line2. majd ezt az alselectet felhasználva
select account, line case when timestampdiff(minute, maxido, minido) > 15 then 2 else 1 end as eredmeny
from fenti_alselect -
#952
martonx
veterán
Peter Kiss
#951
martonx
veterán
válasz
Peter Kiss
#951
üzenetére
megelőztél, tökéletesen egyetértek.
A több select használata, és az azokból szerver oldalon eredmény összeidétlenkedése tipikus SQL-ezni nem tudó programozói attitűd. Ezek nem hogy gyorsítanak, de brutálisan lassíthatják az adatfeldolgozást. -
#932
martonx
veterán
Sk8erPeter
#931
martonx
veterán
válasz
Sk8erPeter
#931
üzenetére
Továbbra sem a wampp-al van a gondom. Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges).
Azon nevettem, hogy mindezt mysql-ezéshez, mert az első hsz-ből más nem derült ki. És igen, tudom bunkó vagyok
Ahogy visszaolvastam az egészet, ismét végig nevettem az első hozzászólás mysql - wampp - könyv javaslatán a data könyvtár átirányításáról. Legközelebb megpróbálom magamban tartani az érzelmeimet.
-
#929
martonx
veterán
Sk8erPeter
#927
martonx
veterán
válasz
Sk8erPeter
#927
üzenetére
Életem első használt adatbázisa a MySQL volt. Anno letöltötem a mysql.com-ról, meg leszedtem mellé a Toad-ot (gugli dobta ki), és next-next telepítettem őket. Akkoriban még fórumok se nagyon voltak, mégis boldogultunk. A Toad varázslóit használtam, közben buzgón elemzve a generált SQL scripteket. Bevallom soha nem olvastam egy SQL-es könyvet sem.
A wampp, xampp dolgokban nem maga a wampp, xampp a gáz, hanem az a röhejes, hogy valaki mysql-t akar tanulni, és ehhez nem az az első logikus lépése, hogy felteszi a mysql-t, meg hozzá egy rendes gui-t, hanem felrak egy komplett keretrendszert, minden felesleges szarral együtt.
Olyan ez mintha autót akarna megtanulni vezetni, és ehhez előbb vesz egy komplett autószalont, miközben csak egy autó kellene.Mondjuk később kiderült, hogy webfejleszt emberünk a gépén, szóval ha értelmesebben fogalmazott volna, és nem azt mondja, hogy a mysql miatt raktam fel wampp-ot, hanem a wampp adott volt, akkor nem is kezdem el fikázni, hanem csak a PHPmyadmin helyett javasoltam volna valami rendes GUI-t.
-
martonx
veterán
A Mysql meg az INFORMATION_SCHEMA részeket még jó, hogy nem lehet törölni, mert ezek a Mysql saját belső működéséhez kellenek. Ezt még DB adminként se lehet törölni, még csak az kellene.
A phpmyadmin lassú és keveset tud és PHP-s webszerver kell hozzá. SQL-t tanulni bármi más jobb a phpmyadmin-nál (na jó az sql konzol ablakban még a PHPmyadmin-nál is reménytelenebb). Én a toad for Mysql-t ajánlom, de van kismillió normális MySQL GUI. -
#882
martonx
veterán
Speeedfire
#881
martonx
veterán
válasz
Speeedfire
#881
üzenetére
Javaslom a célra a Wordpress-t.
-
#856
martonx
veterán
Sk8erPeter
#854
martonx
veterán
válasz
Sk8erPeter
#854
üzenetére
Lehet nem voltam elég érthető? Én arra a módszerre értettem a szabályosat, hogy van egy paraméter táblája, és ebből csak az ID-ket tárolja le ténylegesen. Ezért is írtam a normalizálásról, meg a Paraméter tábláról.
-
#855
martonx
veterán
Speeedfire
#853
martonx
veterán
válasz
Speeedfire
#853
üzenetére
Modellből visszafejtés nagyon nem szép megoldás. Ráadásul simán el tudok olyan helyzetet képzelni, mikor hátulról akarsz adatokat lekérni a DB-dből, és akkor hol van a PHP-s modelled? Szvsz gányolás.
-
#852
martonx
veterán
Speeedfire
#851
martonx
veterán
válasz
Speeedfire
#851
üzenetére
Sok mindent írtál. Az biztos, hogy ebben az esetben lesz egy select-ed, aminek lesz annyi join-ja, ahány mezőben használod a paraméter Id-jait.
Ez így csúnyának fog látszódni, pláne eg egy soros select * from tábla-hoz képest, de hidd el a TSQL-t nem fogja zavarni. Picit teljesítményben persze rosszabb egy select 40 join-nal, de ha abból a 40-ből mind a 40 ugyanannak a táblának ugyanaz a mezője, akkor nem vészes a dolog. Az SQL-ed viszont kevesebb memóriát, tárhelyet fog használni a normalizálásnak hála, ami hoszting cégek esetében előny.
Egy jótanács. Azért ne akarj mindent normalizálni. Pl. kezesség bal - jobb. Ezt egy sima bit mezővel elég megoldani, nem kell, hogy ehhez legyen két paramétered, mint 1 - bal, 2 - jobb.
Még egy jótanács, ha már normalizálunk, és táblát tervezünk. Ne int-ként, hanem tinyint, smallint ilyesmikként kezeld a mezőket. Ezzel további sok byte-ot lehet nyerni mezőnként. És úgy sincs több százezer választható opció egy adott mezőhöz. -
#850
martonx
veterán
Speeedfire
#841
martonx
veterán
válasz
Speeedfire
#841
üzenetére
Amit leírtál az a szabályos menet, és normalizálásnak hívják. Reméléem nem törtelek le, hogy nem találtad fel a spanyolviaszt.
Igen így szokták használni a klasszikus SQL-t, pont ezért is hívják Tranzakciós SQL-nek, nem pedig NoSQL-nek. -
#824
martonx
veterán
Apollo17hu
#822
martonx
veterán
válasz
Apollo17hu
#822
üzenetére
Látod nem is volt nagy cucc beüzemelni. Ezért igazán kár volt a fórumban idétlenkedni. Ráadásul mint annyiszor, most is egy minimális guglizás megoldotta a dolgot.
Egyébként igen azt jelenti, hogy minden win induláskor a MySQL szerver is elindul a háttérben. Ez valamennyi erőforrást lefoglal. Egy régi P4-es celeron kb. használhatatlanná válik tőle, egy core i7-es 8Gb rammal meg észre sem veszi.
-
#820
martonx
veterán
Apollo17hu
#819
martonx
veterán
válasz
Apollo17hu
#819
üzenetére
amikor telepítetted a mysql-t, és nyomkodtad a next-et, volt egy olyan rész, hogy user, meg jelszó. Ez ha jól rémlik defaultban root és nincs hozzá jelszó. Illetve volt egy olyan rész is, hogy fusson-e szolgáltatásként a rendszerrel együtt a mysql, vagy mindig kézzel akarod indítgatni. Azt hiszem itt is a default, hogy fut a rendszerrel együtt.
A server meglepő módon gondolom localhost. -
martonx
veterán
hijnye ember te halmozottan hátrányos helyzetű vagy.
1. Ez itt egy MySQL topik
2. A dokumentációban végig MSSQL-ről van szó
3. Ennél betegebb helyre nem tudtad feltölteni a megosztando dokumentumot??? Manapság a felhők világában, egy ilyen elcseszett - döbbenet hogy még létező - fájl megosztó oldalt hogy lehet egyáltalán megtalálni?Mondjuk ez a harmadik pont elég szubjektív, de nekem azért is fizetned kellene, hogy egy ilyen helyről letöltsek egyáltalán bármit. Ennek ellenére letöltöttem, és az 1-2-es pontok ellentmondásánál gurultak el a gyógyszereim. Ha a fenti véleményem ellenére is kell segítség tőlem
, akkor keress meg nyugodtan privátban
Bár erős a gyanúm, hogy távolról amúgy sem fogok tudni segíteni, mert akinek ez a leírás kínai, annak a windows távoli elérésének bekonfigurálása is elérhetetlen messzeségben van, ami viszont az érdemi segítség nyújtáshoz elengedhetetlen.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
azért hátha a PHP-s szakik tudnak jobb megoldást is, mint soronként kiolvasni, majd újraírni az 50 megás file-okat.
Új hozzászólás Aktív témák
Hirdetés
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Milyen billentyűzetet vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Megjelent a Poco F7, eurós ára is van már
- Linux kezdőknek
- Milyen széket vegyek?
- Azonnali fáradt gőzös kérdések órája
- exHWSW - Értünk mindenhez IS
- One otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- Easun iSolar SMW 11kW Twin Hibrid inverter // Dupla MPPT // BMS // WiFi
- GAMER PC : RYZEN 7 5700G/// 32 GB DDR4 /// RX 6700 XT 12 GB /// 512 GB NVME
- GAMER MSI LAPTOP : 15,6" 144 HZ /// i5 12450H /// 16GB DDR4/// RTX 4050 6GB/// 1TB NVME
- Manfrotto 055 magnézium fotó-videófej Q5 gyorskioldóval
- Sony ECM-W2BT
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Samsung Galaxy S22 Ultra 512GB, Kártyafüggetlen, 1 Év Garanciával
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- LG 42C3 - 42" OLED EVO - 4K 120Hz 0.1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest