- Huawei Watch Fit 5 Pro - jó forma
- Xiaomi 14 - párátlanul jó lehetne
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Milyen okostelefont vegyek?
- Samsung Galaxy S26 Ultra - fontossági sorrend
- Fotók, videók mobillal
- Szaporodik és sokasodik a One UI 8.5
- Robottal a nyomában üldözi a Honor a Huawei-t
- Samsung Galaxy A54 - türelemjáték
- Apple Watch
Új hozzászólás Aktív témák
-
-
-
-
SektorFlop
aktív tag
unique constraint a hónap oszlopára, és így nem szerepelhet kétszer ugyanaz az érték abban az oszlopban
feltöltésnél hibát fog dobni ha olyat akarsz feltölteni, ami már van, ezt kezelni kell
nagyon jól működik, most már csak annyit kell megoldanom hogy ne írja ki akkor is hogy sikeres feltöltés
Még egyszer köszönöm a segítséget!!
-
SektorFlop
aktív tag
-
bpx
őstag
SQLite-ba dolgozok még mindig, és van egy táblám amibe hónapok szerepelnek. Szeretném elkerül azt hogy egy hónap több rekordba is szerepeljen, szóval pl a Január csak egyszer szerepelhessen a táblámba, van erre valami SQL okosság, vagy vagy le kell kérdeznem előtte táblát és az alapján eldönteni hogy mehet e feltöltés vagy nem?
-
martonx
veterán
SQLite-ba dolgozok még mindig, és van egy táblám amibe hónapok szerepelnek. Szeretném elkerül azt hogy egy hónap több rekordba is szerepeljen, szóval pl a Január csak egyszer szerepelhessen a táblámba, van erre valami SQL okosság, vagy vagy le kell kérdeznem előtte táblát és az alapján eldönteni hogy mehet e feltöltés vagy nem?
-
SektorFlop
aktív tag
-
Nincs itt nagyon mit megbeszélni. Az 5.1-es MySQL verzióban volt a legtöbb innováció. Ez pedig 2008 November 27-én jelent meg. Ez lassan 4 év távlatot jelent. lakisoft által jelzett újdonságok is ekkor kerültek bele. Azóta csak csiszolgatják.
Az Oracle pedig 2010 január 27-én vette meg a Sun-t, ami birtokolta a MySQL-t.
De ez részemről nagyon off topik, és nem vagyok egy nagy MySQL szakértő.Egyetértek.
-
Sk8erPeter
nagyúr
Igazából szerintem így lenne értelme:
...
WHERE UPPER( stuff_name ) LIKE UPPER( '%lajos%' )...abban az esetben, ha az adatbázis case sensitive.
Pl. MySQL-nél alapból tök mindegy, hogy "lajos", "LAJOS" vagy "LaJoS" a tárolt név, simán az UPPER nélkül is kiadja mindegyik találatot, szóval ez case insensitive módon megtalálja az összeset - de collationnel arra is van mód, hogy ne így legyen: [link].Case sensitive esetben viszont mindkettőt jó, ha nagybetűssé teszed, és úgy veted össze, mert ellenkező esetben nem mindegy, hogy a fent felsorolt példák közül hogyan keresel rá.
Tehát ha nem mindkettőnek a nagybetűssé (vagy épp kisbetűssé) tett változatát veted össze, akkor lehet, hogy egyes találatokat kizársz az eredményekből, mert mondjuk valaki elgépelte a Lajost, és LajOst írt helyette (lásd nagy O).
A nagybetűssé tett "lajos"-ból "LAJOS" lesz, a nagybetűssé tett "LajOs"-ból is "LAJOS" lesz, tehát így már a két karaktersorozat egyezni fog ebben az 5 karakterben.
A Te fenti keresésed lehetővé teszi azt is, hogy a "LajOska" nevet is megtalálja.Remélem így valamennyire érthető.
-
Sk8erPeter
nagyúr
most ismerkedek a pl sql-el
van egy script
SELECT *
FROM táblanév
WHERE 1=1AND upper(g.NAME) LIKE '%lajos%';
segítsetek miért van az, hogy ha törlöm a where 1=1 feltételt errort kapok?
ill AND után miért kell az upper? miért nem jó ha simán ezt írom:
SELECT *
FROM táblanévAND (g.NAME) LIKE '%lajos%';
-
ArchElf
addikt
most ismerkedek a pl sql-el
van egy script
SELECT *
FROM táblanév
WHERE 1=1AND upper(g.NAME) LIKE '%lajos%';
segítsetek miért van az, hogy ha törlöm a where 1=1 feltételt errort kapok?
ill AND után miért kell az upper? miért nem jó ha simán ezt írom:
SELECT *
FROM táblanévAND (g.NAME) LIKE '%lajos%';
-
dellfanboy
őstag
-
Sk8erPeter
nagyúr
Nincs itt nagyon mit megbeszélni. Az 5.1-es MySQL verzióban volt a legtöbb innováció. Ez pedig 2008 November 27-én jelent meg. Ez lassan 4 év távlatot jelent. lakisoft által jelzett újdonságok is ekkor kerültek bele. Azóta csak csiszolgatják.
Az Oracle pedig 2010 január 27-én vette meg a Sun-t, ami birtokolta a MySQL-t.
De ez részemről nagyon off topik, és nem vagyok egy nagy MySQL szakértő.Szóval az említett "újdonságoknak" köze nincs az Oracle-höz, ahogy nyilvánvalóan az intnek és autoincrementnek sem...
(az utóbbiak mondjuk különösen durvák lennének, ha csak 2010-ben kerültek volna bele...) -
martonx
veterán
lakisoft, martonx: na, akkor most beszéljétek meg, hogy is van ez, mert egymásnak pont ellentmondó állításokat hoztatok fel.
-
Sk8erPeter
nagyúr
-
lakisoft
veterán
Hát int és autoincrement nem csak azóta van, mióta az Oracle tulajdonába került...
-
martonx
veterán
Hát int és autoincrement nem csak azóta van, mióta az Oracle tulajdonába került...
-
Sk8erPeter
nagyúr
-
bpx
őstag
Készítettem egy Silverlight alkalmazást, ami egy Microsoft SQL Server 2008 R2 Express Edition-ből olvassa ki az adatokat. Az adatokat a felhasználó szűrheti is (dátumtól - dátumig, összegtől - összegig). Ez ugye 4 paraméter és nem csak párban működnek, tehát lehet olyat is, hogy csak a bizonyos dátumtól újabb adatokat listázom ki. Ez működik is, csakhogy a favágó módszerrel. Tehát amennyi lehetőség annyi SQL lekérdezés amiből majd csak egy fut le. Nem lehet ezt valahogy elegánsabban megoldani?
egyrészt, ha bind változókat használsz, ez így is csak annyi SQL, ahány esetet a feltételek megadása/meg nem adása eredményez
de ha minden esetet egy SQL utasítással akarsz kezelni, ám legyenMSSQL-t nem ismerem, szóval ez amolyan pszeudokód lesz
SELECT oszlop1, oszlop2
FROM tabla
WHERE datum > NVL(:B1, MINDATE)
AND datum < NVL(:B2, MAXDATE)
AND osszeg > NVL(:B3, 0)
AND osszeg < NVL(:B4, INT.MAXVALUE);B1-B4 bind változók, ami user input
ha a user nem ad meg semmit, akkor NULL-t adsz be neki
az NVL arra való, hogy ha az első paramétere NULL, akkor kicseréli a másodikratehát ha a user nem ad meg felső határt a dátumra, akkor a NULL-t kicseréli az NVL a lehetséges legnagyobb dátumra
ha a user nem ad meg alsó határt az összegre, akkor kicseréli 0-ra
és így tovább...ha meg linq vagy ilyesmi, abban nem vagyok otthon (sajnos)
-
Speeedfire
félisten
-
PHP-t erre felejtsd el, adatok ilyen szintű manipulációját az adatbázis végezze, ne a hozzá kapcsoló alkalmazás
ez 1, azaz egy darab színtiszta SQL utasítás:
DELETE FROM tabla WHERE id IN(
SELECT id FROM(
SELECT id, RANK() OVER (PARTITION BY uid ORDER BY time DESC) r FROM tabla)
WHERE r > 500);magyarázat:
a legbelső select partíciókat képez a táblából az uid alapján, és a partíciókat idő szerint (time) csökkenő sorrendbe rendezi, és minden egyes id-hoz rendel egy sorszámot (rank), hogy adott partícióban a rendezés szempontja szerint hanyadik helyen áll
az eggyel kintebb levő select lekérdezi azokat az id-kat, ahol ez a "rang" 500-nál nagyobb, tehát kívül esik a kívánt limiten
a delete meg törli az ilyen id-val rendelkező sorokat
szerk: adatbáziskezelőt mondjuk nem írtál, ez Oracle-ben működik, én a tábládból úgy tippelem hogy MS SQL (auto increment PK, meg int típus), de ezek a funckiók mintha ott is meglennének
most látom, hogy mysql-ben is van int meg autoincrement, nagyon le vagyok maradva e téren
-
Speeedfire
félisten
PHP-t erre felejtsd el, adatok ilyen szintű manipulációját az adatbázis végezze, ne a hozzá kapcsoló alkalmazás
ez 1, azaz egy darab színtiszta SQL utasítás:
DELETE FROM tabla WHERE id IN(
SELECT id FROM(
SELECT id, RANK() OVER (PARTITION BY uid ORDER BY time DESC) r FROM tabla)
WHERE r > 500);magyarázat:
a legbelső select partíciókat képez a táblából az uid alapján, és a partíciókat idő szerint (time) csökkenő sorrendbe rendezi, és minden egyes id-hoz rendel egy sorszámot (rank), hogy adott partícióban a rendezés szempontja szerint hanyadik helyen áll
az eggyel kintebb levő select lekérdezi azokat az id-kat, ahol ez a "rang" 500-nál nagyobb, tehát kívül esik a kívánt limiten
a delete meg törli az ilyen id-val rendelkező sorokat
szerk: adatbáziskezelőt mondjuk nem írtál, ez Oracle-ben működik, én a tábládból úgy tippelem hogy MS SQL (auto increment PK, meg int típus), de ezek a funckiók mintha ott is meglennének
Hát ez jól hangzik, ennek utána nézek, remélem menni fog nálam is. Én meg itt 50 soros php sql kódon agyaltam már.
MySql alatt vannak az adatok, de meglesem, hogy ezek ott is vannak-e.
Köszi. -
bpx
őstag
Na, akkor kérdeznék én is.
Adott egy log tábla az adatbázisban, ahol a felhasználók ip címe van mentve. x időközönként a legutolsó y mennyiségű adatot törölni kellene.
Van erre valami gyors megoldás?
Csak, mert ami nekem eszembe jutott, hogy groupba kellene szedni őket. Majd megnézni, hogy melyiknél mennyi van, ahol több mint y ott elmenti egy tömbbe azoknak a usereknek az id-ját. Majd egyesével időrendben növekvőbe tenni, lementeni az id-kat és megint csak lenne egy iteráció amiben törölve lennének ezek. Php-val oldanám meg, de ez így szerintem elég sok időbe telik és sok erőforrást emészt fel. Van erre esetleg valami egyszerűbb megoldás?Adatbázis:
id | uid | ip | time
id: ai, elsődleges kulcs
uid: másodlagos kulcs
ip: varchar(20)
time: int(10) -
martonx
veterán
Készítettem egy Silverlight alkalmazást, ami egy Microsoft SQL Server 2008 R2 Express Edition-ből olvassa ki az adatokat. Az adatokat a felhasználó szűrheti is (dátumtól - dátumig, összegtől - összegig). Ez ugye 4 paraméter és nem csak párban működnek, tehát lehet olyat is, hogy csak a bizonyos dátumtól újabb adatokat listázom ki. Ez működik is, csakhogy a favágó módszerrel. Tehát amennyi lehetőség annyi SQL lekérdezés amiből majd csak egy fut le. Nem lehet ezt valahogy elegánsabban megoldani?
-
lakisoft
veterán
Hát én komplexebb feladatokra tárolt eljárást használok, mióta belekóstoltam.
De a te feladatodat igazából nem értem, hogy miért akarod tömbökbe szedni a userek id-ját... Adott userekhez tartozó bejegyzéseknél X időközönként csak Y mennyiséget akarsz törölni, tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Szóval nem csak törölni kell a táblából azt az Y sort, azt' kész?
Fejtsd ki, MOST!===
(#1166) lakisoft :
"Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya
."
Miért, a tárolt eljárás önmagában még nem ocsmány, de el lehet rondítani. -
kisbandima
tag
Én is a tárolt eljárásra szavaznék, de nem ártana látni a "favágó" módszert, meg az alap query-t, vagy valami példaszerűséget, hogy meg tudjuk mondani, hogyan tudnád azt szebben elkészíteni.
Pl. a WHERE-ben is lehetne CASE-ek.(#1164) lakisoft :
Most már érdekelne, hogy ez a dynamic SQL miért jó? Ahogy nézegettem, ez igazából egy query feltételektől függő konkatenálgatása, aztán a query "elkészítése" során annak végrehajtása, ami szerintem elég randa.
Akkor már a WHERE-be elhelyezett, kicsit komplex CASE-ek is szebbnek tűnnek.
Persze aztán lehet, hogy csak nem találkoztam durva esetekkel, ahol nincs jobb, ezért kérdezem. -
Speeedfire
félisten
Hát én komplexebb feladatokra tárolt eljárást használok, mióta belekóstoltam.
De a te feladatodat igazából nem értem, hogy miért akarod tömbökbe szedni a userek id-ját... Adott userekhez tartozó bejegyzéseknél X időközönként csak Y mennyiséget akarsz törölni, tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Szóval nem csak törölni kell a táblából azt az Y sort, azt' kész?
Fejtsd ki, MOST!===
(#1166) lakisoft :
"Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya."
Miért, a tárolt eljárás önmagában még nem ocsmány, de el lehet rondítani.Azért akarom (illetve akarja a fene, de nem látom rá mást...), hogy utána ki tudjam törölni a régi bejegyzéseket.
tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Így van, y mennyiség bejegyzés megmaradni minden usernek.
Nem tudom mit értetlenkedsz ha tudod mire gondolok.
Adott pl 1m rekord és 1k felhasználó és pl 500 bejegyzésnek kellene lennie csak felhasználónként maximum. Ergo akinek több mint 500 ilyen bejegyzése van, azoknak a legrégebbieket törölni kellene.
-
Sk8erPeter
nagyúr
Na, akkor kérdeznék én is.
Adott egy log tábla az adatbázisban, ahol a felhasználók ip címe van mentve. x időközönként a legutolsó y mennyiségű adatot törölni kellene.
Van erre valami gyors megoldás?
Csak, mert ami nekem eszembe jutott, hogy groupba kellene szedni őket. Majd megnézni, hogy melyiknél mennyi van, ahol több mint y ott elmenti egy tömbbe azoknak a usereknek az id-ját. Majd egyesével időrendben növekvőbe tenni, lementeni az id-kat és megint csak lenne egy iteráció amiben törölve lennének ezek. Php-val oldanám meg, de ez így szerintem elég sok időbe telik és sok erőforrást emészt fel. Van erre esetleg valami egyszerűbb megoldás?Adatbázis:
id | uid | ip | time
id: ai, elsődleges kulcs
uid: másodlagos kulcs
ip: varchar(20)
time: int(10)Hát én komplexebb feladatokra tárolt eljárást használok, mióta belekóstoltam.
De a te feladatodat igazából nem értem, hogy miért akarod tömbökbe szedni a userek id-ját... Adott userekhez tartozó bejegyzéseknél X időközönként csak Y mennyiséget akarsz törölni, tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Szóval nem csak törölni kell a táblából azt az Y sort, azt' kész?
Fejtsd ki, MOST!===
(#1166) lakisoft :
"Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya."
Miért, a tárolt eljárás önmagában még nem ocsmány, de el lehet rondítani. -
Speeedfire
félisten
Na, akkor kérdeznék én is.
Adott egy log tábla az adatbázisban, ahol a felhasználók ip címe van mentve. x időközönként a legutolsó y mennyiségű adatot törölni kellene.
Van erre valami gyors megoldás?
Csak, mert ami nekem eszembe jutott, hogy groupba kellene szedni őket. Majd megnézni, hogy melyiknél mennyi van, ahol több mint y ott elmenti egy tömbbe azoknak a usereknek az id-ját. Majd egyesével időrendben növekvőbe tenni, lementeni az id-kat és megint csak lenne egy iteráció amiben törölve lennének ezek. Php-val oldanám meg, de ez így szerintem elég sok időbe telik és sok erőforrást emészt fel. Van erre esetleg valami egyszerűbb megoldás?Adatbázis:
id | uid | ip | time
id: ai, elsődleges kulcs
uid: másodlagos kulcs
ip: varchar(20)
time: int(10) -
lakisoft
veterán
Én is a tárolt eljárásra szavaznék, de nem ártana látni a "favágó" módszert, meg az alap query-t, vagy valami példaszerűséget, hogy meg tudjuk mondani, hogyan tudnád azt szebben elkészíteni.
Pl. a WHERE-ben is lehetne CASE-ek.(#1164) lakisoft :
Most már érdekelne, hogy ez a dynamic SQL miért jó? Ahogy nézegettem, ez igazából egy query feltételektől függő konkatenálgatása, aztán a query "elkészítése" során annak végrehajtása, ami szerintem elég randa.
Akkor már a WHERE-be elhelyezett, kicsit komplex CASE-ek is szebbnek tűnnek.
Persze aztán lehet, hogy csak nem találkoztam durva esetekkel, ahol nincs jobb, ezért kérdezem.Hááát figy. Valóban csúnya de az agyam ráállt teljesen. Így jól és gyorsan tudom használni. A teljesítménybeli vonatkozásait nem ismerem de igazából jelenleg nincs is rá szükségem.
Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya
. -
Sk8erPeter
nagyúr
Készítettem egy Silverlight alkalmazást, ami egy Microsoft SQL Server 2008 R2 Express Edition-ből olvassa ki az adatokat. Az adatokat a felhasználó szűrheti is (dátumtól - dátumig, összegtől - összegig). Ez ugye 4 paraméter és nem csak párban működnek, tehát lehet olyat is, hogy csak a bizonyos dátumtól újabb adatokat listázom ki. Ez működik is, csakhogy a favágó módszerrel. Tehát amennyi lehetőség annyi SQL lekérdezés amiből majd csak egy fut le. Nem lehet ezt valahogy elegánsabban megoldani?
-
lakisoft
veterán
Készítettem egy Silverlight alkalmazást, ami egy Microsoft SQL Server 2008 R2 Express Edition-ből olvassa ki az adatokat. Az adatokat a felhasználó szűrheti is (dátumtól - dátumig, összegtől - összegig). Ez ugye 4 paraméter és nem csak párban működnek, tehát lehet olyat is, hogy csak a bizonyos dátumtól újabb adatokat listázom ki. Ez működik is, csakhogy a favágó módszerrel. Tehát amennyi lehetőség annyi SQL lekérdezés amiből majd csak egy fut le. Nem lehet ezt valahogy elegánsabban megoldani?
-
kisbandima
tag
-
Sk8erPeter
nagyúr
nem feltétlenül kell view... sima select is elég kell hogy legyen igaz?
-
SektorFlop
aktív tag
Te most minden alkalommal egy view-t akarsz létrehozni? Hát az úgy nem lesz jó.
Akkor inkább a view-t selecteld, vagy hagyd a view-t. -
Sk8erPeter
nagyúr
Valaki esetleg tud erre válaszolni? Tudom csak félig tartozik ide, de hátha!
-
SektorFlop
aktív tag
-
Speeedfire
félisten
Megjelenített sorok: 0 - 29 ( 1 001 összesen, a lekérdezés 0.0038 másodpercig tartott)
Megjelenített sorok: 0 - 29 ( ~1 001 összesen , a lekérdezés 0.0026 másodpercig tartott)Gyorsabb, amit te írtál meg.
Query cache ürítés volt az 1. teszt után.
2x is megcsináltam ezeket a teszteket, mind a 2 esetben gyorsabb volt a case szerkezet. -
bpx
őstag
Meglett a megoldás, ennyire nem volt drasztikus szerencsére.
ORDER BY FIELD(
TYPE , '1', '3', '2' )
PazsitZ: Ez is jónak tűnik, megnézem melyik a gyorsabb lekérdezésben.Szerk.:
Amit írtam: a lekérdezés 0.0178 másodpercig tartott
Az általad írt: a lekérdezés 0.0005 másodpercig tartottA tied kicsit gyorsabb, még így 20db adattal is.
Szerk.: Na, most az enyémre is annyit írt mint a tiedre.
-
Speeedfire
félisten
Meglett a megoldás, ennyire nem volt drasztikus szerencsére.
ORDER BY FIELD(
TYPE , '1', '3', '2' )
PazsitZ: Ez is jónak tűnik, megnézem melyik a gyorsabb lekérdezésben.Szerk.:
Amit írtam: a lekérdezés 0.0178 másodpercig tartott
Az általad írt: a lekérdezés 0.0005 másodpercig tartottA tied kicsit gyorsabb, még így 20db adattal is.
Szerk.: Na, most az enyémre is annyit írt mint a tiedre.
-
PazsitZ
addikt
Egy táblában ilyen mezők vannak.
id + name + typeA type most lehet 1,2,3
Lehet olyan lekérdezést csinálni, hogy a type szerint rendezze, de ebben a sorrendben? 3,1,2? -
rum-cajsz
őstag
Egy táblában ilyen mezők vannak.
id + name + typeA type most lehet 1,2,3
Lehet olyan lekérdezést csinálni, hogy a type szerint rendezze, de ebben a sorrendben? 3,1,2? -
Speeedfire
félisten
-
martonx
veterán
Köszi az infókat.
Ezek szerint egy projektben, olykor célszerű lehet inkább keverni ezeket? Vagy nem ajánlott? Vagy esetleg jóval nagyobb többletmunka lenne, hogy megérje azt? -
Speeedfire
félisten
Pont a múltkor kezdtem el noSQL-ezni, pont a mongoDB-vel. Én is még csak kostólgatom. Viszont ahhoz, hogy dönteni tudjak közülük (mármint RDBMS - noSQL közül, és ha noSQL, akkor melyik), bele kellett mélyednem az előny-hátrányaikba.
Még annyit tennék hozzá a fentebbi irományomhoz, hogy amit írtam, az a dokumentum alapú NoSQL-ekre vonatkozik. A kulcs-érték, gráf stb... típusú NoSQL-eknek értelemszerűen teljesen más előnyei lehetnek. RDBMS kiváltásához nyilván a dokumentum alapú NoSQL-eket szokták használni. -
A feldolgozások egymás után történnének. Tehát lesz egy admin aki a bejövő adatokat kezeli és az adatbázisba dolgozza be. Nem egyszerre hanem egyik, majd másik. Lesz kb. 3-4 felhasználó akik ezekről leválogatásokat csinálnak, pl. egy hirdetőre. Nagyon ritka. Mondjuk naponta 1 és 95%-ban különböző időben. De ők pl. a "fő adatbázisban" írni nem fognak, csak onnan adatokat kinyerni ha kell...
Kb. ennyi. Szóval nem lenne erős felhasználás. A fő munka inkább az adatok bevitelénél és az azok után feldolgozásnál lenne sok írás pl. Utána már szinte semmi...
-
MySQL 5.1-től fölfelé 64Tb-os 1-1 adatbázis méretkorlátja. Szerintem ennek a közelében sem lesztek.
Vasat nehéz javasolni, pláne, hogy eddig csak a havi bejövő adatmennyiségről volt szó. Tudni kellene, hogy a bejövő adatok írása mennyire oszlik szét időben, a lekérdezések mennyire történnek időben szétszórtan, illetve hány konkurens felhasználóra számítotok.
Általános tapasztalat, hogy legtöbbször a lemezműveletek viszik el a sok időt, még akkor is ha az adott DB szervernek sok memória áll a rendelkezésére. Manapság a sokmagos processzorok korában a processzor egyre kevésbé a szűk keresztmetszet. -
Nekem foleg oracle-vel vannam tapasztalataim, de ugy sejtem a mysql sem lehet nagyon mas.
El kell dontened, hogy mi a feladatok prioritasa es az alapjan kell dontened.
Akkor eri meg a sok tabla, ha nagyom sok adat (tobb szaz millio) kerul bele adott idoitervallumon belul, es a regi adatokat folyamatosan ki akarod torolni.
Szinte barmelyik SQL adatbazis elboldogul a 100-500 millio sorokkal, ha jol van idexelve, van eleg memoriad, es eleg gyors vinyok vannak alatta.
A havi bontasokkal csak szivatod magad szerintem.
Egyreszt gondoskodni kell arrol, hogy letrejojjon az uj tabla. masreszt folyamatosan karban kell tartanod a viewt, harmadreszt az union miatt sokkal lassab lesz a lekerdezesed, mintha egy tablaben lenne az adat.
VISZONT.
Ha egy tablaban van az adat, es torolni akarsz belole idonkent sok adatot (havonta partizmillio sort), akkor a torles elegge megfoghatja a tabla elereset, es ilyenkor celszeru a tabla bontasa.Remelem tudtam segiteni. kerdezz batran.
Köszi!
File méret korlát van? Mert pl. Foxproban sincs rekord korlát, de file méret ott max 2GB-t volt.
Itt mi a helyzet?
-
1 táblába raknám az adatokat. Aztán ha mégis lassú a dolog, akkor lehet indexekkel játszani, táblát particionálni stb...
Illetve ha évenkénti lekérdezéseitek vannak, egy év múlva megnézve az SQL teljesítményt, elgondolkodnék azon, hogy érdemes-e az adatokat évenként archiválni.
Nagyon fontos lenne mindehhez tudni, hogy milyen a vas a MySQL szerveretek alatt. Mivel totál kezdő vagy, erős a gyanúm, hogy ti egy szimpla hoszting cég amúgy is gyengécske MySQL szerverén fogtok osztozni sokadmagatokkal. Ebben az esetben, bármit is javasolnánk elégtelen lesz az SQL teljesítmény, sőt az első adatbetöltés után maga a hoszting cég fog nyakon vágni titeket, amiért fél órára legyilkoltátok a szerverüket. -
martonx
veterán
Látom te jobban otthon vagy azért ebben.
Nem próbáltam még egyik ilyen nosql-t sem, csak a mongoDB annyira dicsért lett már, hogy...egy ideje én is nagyon agyalgatok rajta, hogy nekiesek és megnézem mit tud.Az nginx-et csak azért írtam, mert azzal is lehet nyerni valamennyi szerver időt. Még ha csak mp-enként +1 lekérdezést is.
-
Havi lekérdezés extrém ritka. Inkább teljes év vagy up2date lekérdezések vannak. Viszont az input adatok havi szinten jönnek. Ha view-sal nézzük, akkor könnyebb kezelni, mert nem kell havin szinten nyitogatni. Akkor lehet érdemes egy táblába tenni egy teljes évet, ha view-sal lassabb....
-
Havi lekérdezés extrém ritka. Inkább teljes év vagy up2date lekérdezések vannak. Viszont az input adatok havi szinten jönnek. Ha view-sal nézzük, akkor könnyebb kezelni, mert nem kell havin szinten nyitogatni. Akkor lehet érdemes egy táblába tenni egy teljes évet, ha view-sal lassabb....
-
PazsitZ
addikt
Látom te jobban otthon vagy azért ebben.
Nem próbáltam még egyik ilyen nosql-t sem, csak a mongoDB annyira dicsért lett már, hogy...egy ideje én is nagyon agyalgatok rajta, hogy nekiesek és megnézem mit tud.Az nginx-et csak azért írtam, mert azzal is lehet nyerni valamennyi szerver időt. Még ha csak mp-enként +1 lekérdezést is.
-
Sk8erPeter
nagyúr
Havi lekérdezés extrém ritka. Inkább teljes év vagy up2date lekérdezések vannak. Viszont az input adatok havi szinten jönnek. Ha view-sal nézzük, akkor könnyebb kezelni, mert nem kell havin szinten nyitogatni. Akkor lehet érdemes egy táblába tenni egy teljes évet, ha view-sal lassabb....
-
WolfLenny
senior tag
Olvasd el még egyszer, amiket írt neked martonx. Pl. ezt, elég érthetően írja le.
Szerk.:
azt írja, hogy "egy SQL tábla kb. bármennyi adatot elbír", ergo tárolhatsz bármennyi adatot így, de lehet, hogy hosszú lekérdezési időkkel kell számolnod.
Gyorsaság szempontjából - ha azonos hónapon belül lekérendő adatokról beszélünk - lehet, hogy gyorsabb külön táblákban tárolni, de aztán kérdés, hogy milyen lekérések gyakoribbak, havi szintű vagy hosszabb időtartamú, aztán lehet, hogy a UNION-nal való lekérdezések, VIEWS-ba rakás ront a teljesítményen, meg "logikailag" nem biztos, hogy szerencsés a különbontás.
Na jó, a hsz. végére már magamat is belekavartam, szóval nem tudom, mi lenne az optimális megoldás. -
Speeedfire
félisten
A noSQL sem csodaszer. Select-ek futtatásában pláne nem.
Bonyolult adatstruktúrák írásakor sokszorosa, akár százszorosa a sebessége a hagyományos RDBMS-ekhez képest.
Bonyolult adatstruktúrák olvasásakor van olyan eset, amikor jóval gyorsabb (néhány szoros) a sebessége a hagyományos RDBMS-ekhez képest.
Full-text search-ben sokkal rugalmasabbak, gyorsabbak a noSQL-ek, különösen azok, amelyek magukba intergálják a Lucene-t is, ilyen pl. a ravenDB
Viszont ha van egy komolyabb adatstruktúrád, de annak csak bizonyos elemeit akarod lekérdezni (mintha több táblád lenne hagyományos sql-ben, de éppen csak egyet akarsz lekérdezni, vagy csak 1-2-t), nos egy ilyen triviális feladat noSQL-ben már korántsem triviális.Ebben az esetben a webszerver, hogy Apache, vagy nginx, vagy IIS, vagy Tomcat vagy bármi totál lényegtelen. Nem az lesz a szük keresztmetszet.
Látom te jobban otthon vagy azért ebben.
Nem próbáltam még egyik ilyen nosql-t sem, csak a mongoDB annyira dicsért lett már, hogy...egy ideje én is nagyon agyalgatok rajta, hogy nekiesek és megnézem mit tud.Az nginx-et csak azért írtam, mert azzal is lehet nyerni valamennyi szerver időt. Még ha csak mp-enként +1 lekérdezést is.
-
Sk8erPeter
nagyúr
Na várjunk. Fogalom zavar van..
Szóval mint kezdőként álljatok hozzám...
File-ban úgy értettem, hogy táblában. Szóval melyik a gyorsabb, ha a 12 hónap 12 táblában van vagy ha 1 táblában van?Olvasd el még egyszer, amiket írt neked martonx. Pl. ezt, elég érthetően írja le.
Szerk.:
azt írja, hogy "egy SQL tábla kb. bármennyi adatot elbír", ergo tárolhatsz bármennyi adatot így, de lehet, hogy hosszú lekérdezési időkkel kell számolnod.
Gyorsaság szempontjából - ha azonos hónapon belül lekérendő adatokról beszélünk - lehet, hogy gyorsabb külön táblákban tárolni, de aztán kérdés, hogy milyen lekérések gyakoribbak, havi szintű vagy hosszabb időtartamú, aztán lehet, hogy a UNION-nal való lekérdezések, VIEWS-ba rakás ront a teljesítményen, meg "logikailag" nem biztos, hogy szerencsés a különbontás.
Na jó, a hsz. végére már magamat is belekavartam, szóval nem tudom, mi lenne az optimális megoldás. -
-
martonx
veterán
"De file-ában letárolni az adatokat, és abban keresni, az még rosszabb."
Pont azt írja, hogy nem.
Esetleg egy mongodb és nginx sokat dobhat a sebességen. -
Speeedfire
félisten
-
Egy SQL tábla kb. bármennyi adatot elbír. Távközlésben DB admin ismerős mesélte, hogy van olyan táblájuk, amibe napi 130 millió sor kerül bele.
Nálunk is vannak szép nagy táblák.
Másrészt úgy látom, hogy ti PHP + MySQL-t akartok használni, ahol gondolom a MySQL ingyenes, nem Enterprise verzió, és nincsenek fürtözött SQL szervereitek a MySQL mögött. Ilyenkor szép hosszú keresési időkkel számolhattok, egy - egy lekérdezésnél. De file-ában letárolni az adatokat, és abban keresni, az még rosszabb.A jogosultságos kérdésben kevered a szezont a fazonnal. Az SQL szintű user jogosultságok általában köszönő viszonyban sincsenek az alkalmazás szintű user jogosultságokkal. Általában 1-2 SQL usert szoktak létrehozni, 1-et a DB adminnak full jogkörrel, és 1-et az alkalmazásnak csak a szükséges jogkörrel. Utána minden más jogisultságot az alkalmazáson belül szoktak intézni.
-
Speeedfire
félisten
-
martonx
veterán
130M az nem kevés.
Ott akkor jó nagy adathalmaz lehet a gépeken.
-
Speeedfire
félisten
Egy SQL tábla kb. bármennyi adatot elbír. Távközlésben DB admin ismerős mesélte, hogy van olyan táblájuk, amibe napi 130 millió sor kerül bele.
Nálunk is vannak szép nagy táblák.
Másrészt úgy látom, hogy ti PHP + MySQL-t akartok használni, ahol gondolom a MySQL ingyenes, nem Enterprise verzió, és nincsenek fürtözött SQL szervereitek a MySQL mögött. Ilyenkor szép hosszú keresési időkkel számolhattok, egy - egy lekérdezésnél. De file-ában letárolni az adatokat, és abban keresni, az még rosszabb.A jogosultságos kérdésben kevered a szezont a fazonnal. Az SQL szintű user jogosultságok általában köszönő viszonyban sincsenek az alkalmazás szintű user jogosultságokkal. Általában 1-2 SQL usert szoktak létrehozni, 1-et a DB adminnak full jogkörrel, és 1-et az alkalmazásnak csak a szükséges jogkörrel. Utána minden más jogisultságot az alkalmazáson belül szoktak intézni.
130M az nem kevés.
Ott akkor jó nagy adathalmaz lehet a gépeken. -
Újabb kérdések:
A dilemma a következő:
Mi a gyakorlati korlát egy táblában. Az adatok havi szinten jönnek és kb.1-1.3 millió rekord nagyságúak és kb. 50 mezőt tartalmaznak. Melyik megoldás lenne a gyorsabb. Ha külön file-ban tároljuk havi szinten, vagy ennyit még bepakolhatunk egy táblába.Jogosultsággal kapcsolatos kérdések:
1. PHP+MySQL páros. Ha belép valaki a weboldalon keresztül, akkor a jelszót az MySQL-nek kódolva kell továbbítani? Vagy elfogadja TEXT-ként is az adatbázis szerver?
2. 3 szintű jogosultságot szeretnénk létrehozni.
a. Full jog.
b. Korlátozott jog. Bizonyos táblákat módosíthat csak. Viszont mikor új táblák készülnek,akkor azok a FULL joggal rendelkező user-rel készülnek. Tehát külön kellene az elkészülés után adni jogot minden egyes ilyen táblához?
c. Csak olvasás a fő adatbázisra és egy másik külön adatbázisba (pl output database) lenne írási joga. -
Speeedfire
félisten
Uhh, balga hiba volt.
Ugye anno mikor elkezdtem csinálni az oldalt, csináltam pár teszt adatot.
De ennél az egynél nem töltöttem ki egy mezőt, pedig kötelező kitölteni és a validator miatt nem lett sohasem elmentve.
Kitöltöttem a mezőt, most már megy. -
Speeedfire
félisten
Az adott felhasználónak, akivel kapcsolódsz a Yii-n keresztül, van joga a feltöltéshez is?
Igen van. A többi sornál működik is a módosítás.
PazsitZ: Na, ezt megnézem majd. -
PazsitZ
addikt
Ja, nem a legjobb. De szerencsére csak localhost szóval, annyira nem nagy para.
Más: Adott egy admin panel php alatt, ahol ajax-al tudom módosítani egy mező értékét sql alatt. Érdekes mód, egy db ilyen sorban nem tudom módosítani. A yii nem dobott semmilyen hibát sem. Egyszerűen a mentésre azt írja, hogy nem sikerült neki.
De minden más adatnál sikerült. A fura, hogy phpmyadmin alatt viszont tudom ezt a sort szerkeszteni.
Se az sql, se a php, se az apache nem dob nekem erre hibát. -
Sk8erPeter
nagyúr
Ja, nem a legjobb. De szerencsére csak localhost szóval, annyira nem nagy para.
Más: Adott egy admin panel php alatt, ahol ajax-al tudom módosítani egy mező értékét sql alatt. Érdekes mód, egy db ilyen sorban nem tudom módosítani. A yii nem dobott semmilyen hibát sem. Egyszerűen a mentésre azt írja, hogy nem sikerült neki.
De minden más adatnál sikerült. A fura, hogy phpmyadmin alatt viszont tudom ezt a sort szerkeszteni.
Se az sql, se a php, se az apache nem dob nekem erre hibát. -
Speeedfire
félisten
Hát akkor lehet, hogy az adott táblára globális jogok vonatkoznak, hogy minden felhasználó hozzáférhessen, szóval akkor az adott adatbázisnál a "Jogok ellenőrzése" résznél meg kellene kukkantani, milyen jogosultságok vannak beállítva; vagy az adott júzereknek túl sok a joga. Az tényleg nem jóféle, ha mindenki hozzáfér.
=====================
WolfLenny : nincs mit!Ja, nem a legjobb. De szerencsére csak localhost szóval, annyira nem nagy para.
Más: Adott egy admin panel php alatt, ahol ajax-al tudom módosítani egy mező értékét sql alatt. Érdekes mód, egy db ilyen sorban nem tudom módosítani. A yii nem dobott semmilyen hibát sem. Egyszerűen a mentésre azt írja, hogy nem sikerült neki.
De minden más adatnál sikerült. A fura, hogy phpmyadmin alatt viszont tudom ezt a sort szerkeszteni.
Se az sql, se a php, se az apache nem dob nekem erre hibát. -
Sk8erPeter
nagyúr
A 3-ason kívül minden megvolt. Ezek szerint anélkül nincs engedélyezve. Bár érdekes mód, így is tudok kapcsolódni custom felhasználóval.
Lehet sz*rul van az sql-em beállítva.
Hát akkor lehet, hogy az adott táblára globális jogok vonatkoznak, hogy minden felhasználó hozzáférhessen, szóval akkor az adott adatbázisnál a "Jogok ellenőrzése" résznél meg kellene kukkantani, milyen jogosultságok vannak beállítva; vagy az adott júzereknek túl sok a joga. Az tényleg nem jóféle, ha mindenki hozzáfér.
=====================
WolfLenny : nincs mit! -
WolfLenny
senior tag
Többek közt a táblák megfelelő indexelésével... Query cache használatával...
EXPLAIN segít, hogy hol kellene többek közt az indexelésen javítani...
Itt van pár tipp.
Aztán még számtalan más oka lehet.Túl általánosan írtad le a problémádat ahhoz, hogy konkrétan tudjunk segíteni. De a fentiek közül valamelyik segíthet.
===
Szerk.: egyébként -Zeratul- írt neked egy elég jó választ itt korábban, de arra nem reagáltál... ez végül is megoldotta az előző problémádat? Nem árt - illik - válaszolni az illetőnek, ha segítséget kaptál...Köszi!
Átolvassuk.
=======
Igen, mert még nem beszéltem azóta az illetővel. (Nem én programozom, csak segítek neki..
)Ma elvileg tudunk foglalkozni a dologgal...
-
Speeedfire
félisten
"Hogy lehetne engedélyezni ezt a felhasználót az adatbázisban?"
Screenshot
1.) "Jogok" fül
2.) itt hozzá tudod adni az új felhasználót; de nálad ez már megtörtént, úgyhogy "Jogok szerkesztése" az adott felhasználónál
3.) "Adatbázis-specifikus jogok" résznél "Jogok hozzáadása a következő adatbázison:", kiválasztod a megfelelő adatbázist,
4.) itt a "Jogok szerkesztése" ablakban kiválasztod, milyen jogokat akarsz adni az adott felhasználónak (kattints a "Mind kijelölése" linkre, ha minden jogot meg akarsz adni az adott felhasználónak ezen az adatbázison belül
5.) Indítás, és kész vagy.A 3-ason kívül minden megvolt. Ezek szerint anélkül nincs engedélyezve. Bár érdekes mód, így is tudok kapcsolódni custom felhasználóval.
Lehet sz*rul van az sql-em beállítva. -
Sk8erPeter
nagyúr
Üdv.!
Van tippetek vagy linketek, hogyan lehetne a MySQl sebességét optimalizálni?
100.000 rekordos lekérdezésénél is perceket dolgozott....
Ütlet, link?Előre is köszi
Többek közt a táblák megfelelő indexelésével... Query cache használatával...
EXPLAIN segít, hogy hol kellene többek közt az indexelésen javítani...
Itt van pár tipp.
Aztán még számtalan más oka lehet.Túl általánosan írtad le a problémádat ahhoz, hogy konkrétan tudjunk segíteni. De a fentiek közül valamelyik segíthet.
===
Szerk.: egyébként -Zeratul- írt neked egy elég jó választ itt korábban, de arra nem reagáltál... ez végül is megoldotta az előző problémádat? Nem árt - illik - válaszolni az illetőnek, ha segítséget kaptál... -
Sk8erPeter
nagyúr
Phpmyadmin-ban létrehoztam egy felhasználót, de azt írja, az engedélyezve oszlopba, hogy nem. Hogy lehetne engedélyezni ezt a felhasználót az adatbázisban?
Vagy ez mire vonatkozik? -
Speeedfire
félisten
-
Bocs, nem akartalak összezavarni..
Szóval van 12 db tábla, ami havi adatokat tartalmaz. Szükségünk van az adatokra úgy mintha a 12 db tábla egy nagyba lenne. De nem akarjuk a 12 db táblát egybe összefűzni fizikailag. Mert már túl nagy lenne így és méret korlátba ütközhetünk, illetve jobb kezelni külön. Amikor lekérdezéseket csinálunk, akkor az UNION-nal 12x kell leírni. Ezt szeretnénk egyszerűsíteni, ha lehet..
Így már tiszta?
-
WolfLenny
senior tag
Lehet, hogy ilyenre gondolsz: [link]. Nem?
Szerk.: bár most már akkor kevésbé értem a feladatot. Először azt írtad: "Van két (vagy több) tábla ami azonos struktúrával rendelkezik." - és ezekből "egyesítve" (union) kellene lekérni adatot.
Akkor lehet, hogy a kettő kombinációja kellene. Összefűzni a fájlokat, majd union, de már kicsit összezavartál.
Igazából most nem vágom, az a sok különálló file egy-egy adatbázis dump file? Tehát nincsenek eleve felküldve az adatbázisba? Pontosíts plíz.Bocs, nem akartalak összezavarni..
Szóval van 12 db tábla, ami havi adatokat tartalmaz. Szükségünk van az adatokra úgy mintha a 12 db tábla egy nagyba lenne. De nem akarjuk a 12 db táblát egybe összefűzni fizikailag. Mert már túl nagy lenne így és méret korlátba ütközhetünk, illetve jobb kezelni külön. Amikor lekérdezéseket csinálunk, akkor az UNION-nal 12x kell leírni. Ezt szeretnénk egyszerűsíteni, ha lehet..
Így már tiszta?
-
WolfLenny
senior tag
Lehet, hogy ilyenre gondolsz: [link]. Nem?
Szerk.: bár most már akkor kevésbé értem a feladatot. Először azt írtad: "Van két (vagy több) tábla ami azonos struktúrával rendelkezik." - és ezekből "egyesítve" (union) kellene lekérni adatot.
Akkor lehet, hogy a kettő kombinációja kellene. Összefűzni a fájlokat, majd union, de már kicsit összezavartál.
Igazából most nem vágom, az a sok különálló file egy-egy adatbázis dump file? Tehát nincsenek eleve felküldve az adatbázisba? Pontosíts plíz.Ez már jó lehet, csak a kérdés (amit elfelejtettem) hogy ez PHP-ban van....
Valakinek van ötlete erre?
-
Sk8erPeter
nagyúr
Lehet pontatlan voltam.
Szóval ami a lényeg van 12 db file-om (havi bontású adatok) De amikor megnyitom a 12 db file-t (vagy táblás), akkor logikailag mintha egy file-t (vagy táblát) kezelnék.
Ezt az Union-nal is meg lehet csinálni? Ő állítólag valami create table utasításra emlékszik.. de nem biztos benne....Lehet, hogy ilyenre gondolsz: [link]. Nem?
Szerk.: bár most már akkor kevésbé értem a feladatot. Először azt írtad: "Van két (vagy több) tábla ami azonos struktúrával rendelkezik." - és ezekből "egyesítve" (union) kellene lekérni adatot.
Akkor lehet, hogy a kettő kombinációja kellene. Összefűzni a fájlokat, majd union, de már kicsit összezavartál.
Igazából most nem vágom, az a sok különálló file egy-egy adatbázis dump file? Tehát nincsenek eleve felküldve az adatbázisba? Pontosíts plíz. -
WolfLenny
senior tag
Pont ilyen kérdést tettek fel Stack Overflow-n: [MySQL - Selecting data from multiple tables all with same structure but different data]
Ott javasolt megoldás:
(SELECT * from us_music where `genre` = 'punk')
UNION
(SELECT * from de_music where `genre` = 'punk') -
A baj csak az, hogy nem jó helyen kérdezted meg.
Ez itt egy SQL szakmai topic. Te pedig egy E-learning CMS-t akarsz beüzemelni, aminek nulla köze van az SQL szakmaisághoz. Na jó SQL-en fut a DB része, de ezzel az erővel mindennek köze van az SQL-hez![;]](//cdn.rios.hu/dl/s/v1.gif)
Pl. a facebook is SQL-en fut, mégsem itt kell megkérdezni, hogy hogyan kell ismerősnek jelölni rajta valakit.
Privátban továbbra is segítek szívesen. -
Tényleg nem néztem utána hogy ingyenes-e, de itt miért ne lehetne megkérdezni? Egy csomó topikba ott vagyok pl "Milyen notebookot vegyek?" és oda is beírják minden nap 20x szinte ugyan azt a kérdést amire a választ a keresőből is megtudnák, de mégis mind a 20x meg is válaszoljuk ugyan azt. Ha ez téged idegesít hogy itt kérdeztem meg hogy ingyenes-e, akkor egyszerűen nem kell válaszolnod rá...Plusz igen mástól várom a segítséget, de nem azt hogy segítsen megcsinálni az egészet, hanem elindulni egy vonalon. Időm lesz rá megcsinálni, de ha látom teljesen reménytelen vagyok hozzá akkor átadom másnak ezt az egészet. Plusz szerintem direkt úgy kértem segítséget idézek magamtól: "ha valaki nagyon ráér" szóval isten ments hogy valaki velem foglalkozzon ha nincs rá ideje illetve nem is akar...
A baj csak az, hogy nem jó helyen kérdezted meg.
Ez itt egy SQL szakmai topic. Te pedig egy E-learning CMS-t akarsz beüzemelni, aminek nulla köze van az SQL szakmaisághoz. Na jó SQL-en fut a DB része, de ezzel az erővel mindennek köze van az SQL-hez Pl. a facebook is SQL-en fut, mégsem itt kell megkérdezni, hogy hogyan kell ismerősnek jelölni rajta valakit.
Privátban továbbra is segítek szívesen. -
Sk8erPeter
nagyúr
Tényleg nem néztem utána hogy ingyenes-e, de itt miért ne lehetne megkérdezni? Egy csomó topikba ott vagyok pl "Milyen notebookot vegyek?" és oda is beírják minden nap 20x szinte ugyan azt a kérdést amire a választ a keresőből is megtudnák, de mégis mind a 20x meg is válaszoljuk ugyan azt. Ha ez téged idegesít hogy itt kérdeztem meg hogy ingyenes-e, akkor egyszerűen nem kell válaszolnod rá...Plusz igen mástól várom a segítséget, de nem azt hogy segítsen megcsinálni az egészet, hanem elindulni egy vonalon. Időm lesz rá megcsinálni, de ha látom teljesen reménytelen vagyok hozzá akkor átadom másnak ezt az egészet. Plusz szerintem direkt úgy kértem segítséget idézek magamtól: "ha valaki nagyon ráér" szóval isten ments hogy valaki velem foglalkozzon ha nincs rá ideje illetve nem is akar...
"oda is beírják minden nap 20x szinte ugyan azt a kérdést amire a választ a keresőből is megtudná, de mégis mind a 20x meg is válaszoljuk ugyan azt"
És úgy gondolod, ez követendő példa?
Sajnos ez a "divat" a Prohardver fórumain tényleg nagyon elharapózott manapság, pont ez a probléma. Ez nem csak az én szélsőséges véleményem, épp a napokban beszélgettem erről egy modival, sajnos ő is hasonlóan látja a helyzetet.Félreértesz, nem az a baj, ha felteszel kérdéseket, amik másnak alapvetőek lehetnek (valakinek az is alapvető lehet, hogyan kell csatlakozni egy adatbázishoz PHP-kódból), hanem az a "baj", ha olyan kérdést teszel fel, ami tényleg kideríthető kevesebb, mint 1 percnyi utánanézéssel - kb. annyi idő alatt, amennyi idő alatt megírtad a kérdésedet. Igazából csak nem értem az okát, hogy miért jó ez. Ha megkérdezed, hogyan kell telepíteni a PHP-t, még az is jobb, mint azt megkérdezni, egyáltalán letölthető-e valahonnan legálisan. Az oka, hogy ez zavaró, az az, hogy ezekkel a hozzászólásokkal csak hígul a topic szakmaisága, ráadásul ennek már köze nincs az SQL-hez. Írod is, hogy "Tényleg nem néztem utána" - felmerül a kérdés, hogy vajon miért nem? Egy fórum nem arra való, hogy helyetted gondolkozzanak az emberek, hanem hogy segítsenek, ha valahol elakadtál, és nem sikerült megtalálnod a kellő információt.
Szerk.: most utálhatsz azért, hogy ezeket leírtam, de ha mindenki csendben marad, és soha senki nem szól semmiért annak érdekében, hogy a Prohardver szakmai színvonala azért ne süllyedjen a békának ama bizonyos testrésze alá, akkor csak egyre rosszabb irányba fogunk haladni.
-
B-L-A-C-K
titán
Nem, nem rázom kisujjból ezeket a dolgokat, nem vagyok rendszergazda. Bár csináltam már szerverállítgatós mókákat bőven melóhelyen is, de ez csak megerősítette bennem, hogy tuti soha nem akarnék rendszergazda lenni, ha nem muszáj.
Annyira macerás és szerteágazó témakör, plusz rengeteg hibalehetőség van - ezért is javasoltam, hogy inkább bízz meg valakit a feladattal, nem azért, mert feltételezem, hogy bekapcsolni sem tudod a gépet. De azért vannak dolgok, amikbe az embernek nem ártana legalább minimális erőfeszítést belefektetnie, ha már ezzel akar foglalkozni komolyabban is (pl. egy szerver megfelelő beállítása már elég komoly dolog) - pl. azt kideríteni, hogy honnan tudod letölteni a PHP-t, és egyáltalán ingyenes-e, pont ilyen dolog...ezekkel a kérdésekkel csak azt bizonyítod be, hogy kicsit sem néztél utána a témának, de azért mástól várod a segítséget, hogy majd neki kerüljön energiájába, hogy szinte megfogja a kezedet, és idegenvezetés jelleggel elkalauzoljon téged az internetes nagyvilágban. -
Sk8erPeter
nagyúr
5.2.5 kerestem ezt nem találtam, és mivel ugye fogalmam sincs hogy jó e másik verzió ezért nem szedtem le az 5.x.x-es verziót megkérdezés előtt. De ezek szerint úgy látom teljesen min1 mit szedek le. Viszont ha te már így állsz hozzám ahogy leírtad, kb hogy be sem tudom kapcsolni a gépet, akkor nem is kéne válaszolnod. Gondolom te már kisujjból kirázod az ezzel kapcsolatos dolgokat, de mivel én most találkozok először ilyennel így szerintem nem olyan meglepő hogy nem tudom pontosan mit is kéne letölteni hozza...
Nem, nem rázom kisujjból ezeket a dolgokat, nem vagyok rendszergazda. Bár csináltam már szerverállítgatós mókákat bőven melóhelyen is, de ez csak megerősítette bennem, hogy tuti soha nem akarnék rendszergazda lenni, ha nem muszáj.
Annyira macerás és szerteágazó témakör, plusz rengeteg hibalehetőség van - ezért is javasoltam, hogy inkább bízz meg valakit a feladattal, nem azért, mert feltételezem, hogy bekapcsolni sem tudod a gépet. De azért vannak dolgok, amikbe az embernek nem ártana legalább minimális erőfeszítést belefektetnie, ha már ezzel akar foglalkozni komolyabban is (pl. egy szerver megfelelő beállítása már elég komoly dolog) - pl. azt kideríteni, hogy honnan tudod letölteni a PHP-t, és egyáltalán ingyenes-e, pont ilyen dolog...ezekkel a kérdésekkel csak azt bizonyítod be, hogy kicsit sem néztél utána a témának, de azért mástól várod a segítséget, hogy majd neki kerüljön energiájába, hogy szinte megfogja a kezedet, és idegenvezetés jelleggel elkalauzoljon téged az internetes nagyvilágban.
(az utóbbiak mondjuk különösen durvák lennének, ha csak 2010-ben kerültek volna bele...)
."
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Pl. a facebook is SQL-en fut, mégsem itt kell megkérdezni, hogy hogyan kell ismerősnek jelölni rajta valakit.
Új hozzászólás Aktív témák
- Macbook Pro 14" A2442 2021 M1 MAX 32/1TB Astro
- Lemezes PlayStation 5 Slim CFI-2016 // 2 kontrollerrel // töltőállomás // távirányító
- HP ZBOOK FURY 15 G7 Tervező Vágó Laptop -70% 15,6" i7-10850H 32/512 Quadro T2000 4GB LTE
- RYZEN 7 5700X3D +hűtött VRM-es A520M/B550/X570 lap +16GB hűtőbordás DDR4 kit! GAR/SZÁMLA (nevedre)!
- Macbook Pro 16" A2485 2021 M1 MAX 32/1TB 32 GPU Astro (Dobozos, 16 ciklus 100% akku)
- INTEL Core i7-13700F 3.40GHz LGA-1700 (30M Cache, up to 5.20 GHz) OEM CPU!
- ÚJ! ÉJFEKETE / midnight MacBook Air M4 13" 16GB 256GB - 1év Garancia! TÖLTŐ, +AJÁNDÉK!!!
- Lenovo ThinkPad T14S Gen1 Ryzen5 4650U Refurbished - Akció! Garancia
- Lenovo IdeaPad Slim 3 Ryzen 7 8840HS 15" FHD+ 16GB 1000GB Teljeskörű garancia
- Új és újszerű 13-14 Gamer, üzleti, 2in1, X360 Touch készülékek nagyon kedvező áron! Garancia Számla!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest