- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- urandom0: Kicsit most elfáradtam...
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- bambano: Bambanő háza tája
- Brogyi: CTEK akkumulátor töltő és másolatai
- eBay-es kütyük kis pénzért
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
WolfLenny
#1199
üzenetére
Egyrészt a PHP mint interpreter nyelv az ilyen műveletekre alapvetően kb. 100X lassabb (lehet, hogy cak 10-szer, erről ne nyissunk vitát), mint egy compiled (pl. java, .net) nyelv.
Másrészt ha ezen a szerencsétlen P4-esen még emellett egy MySQL-t is futtatsz, és mindehhez egy ősrégi lassú vinyú kerreg alatta, akkor nem csoda ez a futásidő. -
WolfLenny
senior tag
Üdv.!
Egy olyan kérdésem lenne, hogy adott egy kb. 4-500 MB méretű csv. Kb. 1-1.5 millió rekord kb. 40 mezővel.
A teszt felszedése 140.000 rekordot tartalmazott és több mint 1 órán keresztül szedte fel.
Ezt lehetne valahogy gyorsítani?Előre is köszi a választ...
-
#1192
bpx
őstag
SektorFlop
#1190
bpx
őstag
válasz
SektorFlop
#1190
üzenetére
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
-
#1191
martonx
veterán
SektorFlop
#1190
martonx
veterán
válasz
SektorFlop
#1190
üzenetére
le kell kérdezni. Csodák nincsenek.
-
#1190
SektorFlop
aktív tag
SektorFlop
aktív tag
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?
-
#1188
Sk8erPeter
nagyúr
Sk8erPeter
#1187
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#1187
üzenetére
Pontos egyezés vizsgálatához át lehet alakítani így is:
SELECT * FROM `test_names`
WHERE
BINARY(stuff_name) LIKE "%lajos%"Így csak azt találja meg, ahol "lajos" vagy "lajoska" van, a "Lajos" vagy "LaJos", stb. neveket már nem.
-
#1187
Sk8erPeter
nagyúr
dellfanboy
#1185
Sk8erPeter
nagyúr
válasz
dellfanboy
#1185
üzenetére
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ő.
-
#1186
ArchElf
addikt
dellfanboy
#1185
ArchElf
addikt
válasz
dellfanboy
#1185
üzenetére
Nem a where 1=1 -et kell törölni, hanem az 1=1 AND-et
SELECT *
FROM táblanév
WHERE upper(g.NAME) LIKE '%lajos%';AE
-
#1185
dellfanboy
őstag
dellfanboy
őstag
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%';
-
#1183
martonx
veterán
Sk8erPeter
#1182
martonx
veterán
válasz
Sk8erPeter
#1182
üzenetére
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ő. -
#1181
lakisoft
veterán
Sk8erPeter
#1179
lakisoft
veterán
válasz
Sk8erPeter
#1179
üzenetére
Itt nem ezekre gondoltam. A tárolt eljárásokra pl. vagy MySQL Partitioning vagy Storage Engine: NDB kibővítették az elérhető adattipusokat.
-
#1180
martonx
veterán
Sk8erPeter
#1179
martonx
veterán
válasz
Sk8erPeter
#1179
üzenetére
Én inkább úgy mondanám, hogy mióta az Oracle kezében van, nem olyan a fejlődési üteme, mint régen. Az Oracle bolond lenne saját magának konkurenciát állítani.
-
#1177
bpx
őstag
kisbandima
#1163
bpx
őstag
válasz
kisbandima
#1163
üzenetére
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)
-
#1173
bpx
őstag
Speeedfire
#1167
bpx
őstag
válasz
Speeedfire
#1167
üzenetére
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
-
#1172
martonx
veterán
kisbandima
#1163
martonx
veterán
válasz
kisbandima
#1163
üzenetére
Ha már Silverlight, akkor gondolnám, hogy WCF RIA Services-el adod az adatokat, ez esetben LINQ-val simán meg lehet oldani az egészet.
Ha meg nem több millió adatsorról van szó, C#-al, XAML-lel elég szépen lehet memóriában szűrni az adathalmazt. -
#1171
lakisoft
veterán
Sk8erPeter
#1168
lakisoft
veterán
válasz
Sk8erPeter
#1168
üzenetére
Persze hogy el lehet rondítani, de próbálok áttekinthető kódot kiadni a kezemből.
-
kisbandima
tag
válasz
Sk8erPeter
#1165
üzenetére
Favágó módszer 2 paraméterre:
if ((a != 0) && (b == 0))
{
return ... Where Osszeg >= a;
}
if ((a == 0) && (b != 0))
{
return ... Where Osszeg <= b;
}
return ... Where Osszeg >= a & Osszeg <= b;Remélem így már érthető. A probléma, hogy nekem 4 paraméterem van és ezzel a módszerrel elég amatőr megoldásnak látszik. Igaz legalább működik.
-
#1169
Speeedfire
félisten
Sk8erPeter
#1168
Speeedfire
félisten
válasz
Sk8erPeter
#1168
üzenetére
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.
-
#1168
Sk8erPeter
nagyúr
Speeedfire
#1167
Sk8erPeter
nagyúr
válasz
Speeedfire
#1167
üzenetére
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. -
#1167
Speeedfire
félisten
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) -
#1166
lakisoft
veterán
Sk8erPeter
#1165
lakisoft
veterán
válasz
Sk8erPeter
#1165
üzenetére
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
. -
#1165
Sk8erPeter
nagyúr
kisbandima
#1163
Sk8erPeter
nagyúr
válasz
kisbandima
#1163
üzenetére
É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. -
#1164
lakisoft
veterán
kisbandima
#1163
lakisoft
veterán
válasz
kisbandima
#1163
üzenetére
Dynamic SQL? vagy Dynamic SQL és tárolt eljárás?
-
#1163
kisbandima
tag
kisbandima
tag
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?
-
#1162
Sk8erPeter
nagyúr
SektorFlop
#1161
Sk8erPeter
nagyúr
válasz
SektorFlop
#1161
üzenetére
Elvileg ja.
-
#1161
SektorFlop
aktív tag
Sk8erPeter
#1160
SektorFlop
aktív tag
válasz
Sk8erPeter
#1160
üzenetére
nem feltétlenül kell view... sima select is elég kell hogy legyen igaz?
-
#1160
Sk8erPeter
nagyúr
SektorFlop
#1159
Sk8erPeter
nagyúr
válasz
SektorFlop
#1159
üzenetére
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. -
#1159
SektorFlop
aktív tag
SektorFlop
aktív tag
Valaki esetleg tud erre válaszolni? Tudom csak félig tartozik ide, de hátha!
-
#1158
Speeedfire
félisten
PazsitZ
#1157
Speeedfire
félisten
válasz
PazsitZ
#1157
üzenetére
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. -
PazsitZ
addikt
Igen, mérés esetén vagy a benchmark-al futtasd le mondjuk 10000 ismétléssel így mindegyik esetén azonosan használ cache-t a későbbi requestek esetén és hamarabb kibukik.
Vagy mindkettő futtatása elé szúrd be a: RESET QUERY CACHE; parancsot.
Feltéelezve, hogy mysql-t használsz.
-
#1156
bpx
őstag
Speeedfire
#1155
bpx
őstag
válasz
Speeedfire
#1155
üzenetére
persze mert első futás után már cache-ből megy
-
#1155
Speeedfire
félisten
rum-cajsz
#1153
Speeedfire
félisten
válasz
rum-cajsz
#1153
üzenetére
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.
-
#1154
PazsitZ
addikt
Speeedfire
#1152
PazsitZ
addikt
válasz
Speeedfire
#1152
üzenetére
SELECT id, name, type FROM table
WHERE type IN (1,2,3)
ORDER BY
CASE type
WHEN 3 THEN 1
WHEN 1 THEN 2
WHEN 2 THEN 3
END; -
#1153
rum-cajsz
őstag
Speeedfire
#1152
rum-cajsz
őstag
válasz
Speeedfire
#1152
üzenetére
vagy írsz egy függvényt, vagy egy másik táblában definiálod a kívánt sorrendet.
-
#1152
Speeedfire
félisten
Speeedfire
félisten
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? -
#1151
martonx
veterán
Speeedfire
#1150
martonx
veterán
válasz
Speeedfire
#1150
üzenetére
Szvsz nem ajánlott keverni, legalábbis vagy RDBMS-t, vagy dokumentum alapú NoSQL-t érdemes használni. És e mellé persze könnyen lehet gráf tárolót, vagy kulcs-érték tárolót használni (lásd pl. Facebook, ami MySQL alapú, de a kapcsolatokat gráf tároló NoSQL-ben tartja).
-
martonx
veterán
válasz
WolfLenny
#1148
üzenetére
ez esetben abszolút nem kell erős hardver a mysql alá. Egy mai bármilyen alap szerver megteszi (kettő mag, pár guriga memória, egy kis raid tömb mondjuk 3 vinyóból, ha fontos a redundancia). Azért ha nem egy 10 éves egy magos xeon-on futtatnátok, az nem lenne hátrány.
-
WolfLenny
senior tag
válasz
martonx
#1147
üzenetére
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...
-
martonx
veterán
válasz
WolfLenny
#1146
üzenetére
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. -
WolfLenny
senior tag
válasz
martonx
#1143
üzenetére
Egyelőre a vas még kérdéses. A szerver helyben lesz és kizárólag mi fogjuk használni.
Még nincs alatta konkrét vas, ehhez is szeretnék tőletek javaslatot.Bővebben, hogy mi is lesz rajta. Kb. 9 ország adatai dolgozzuk fel. Az egyes országokat külön adatbázisba tervezem. Átlag 1 hónap kb. 100.000 rekord/ország. Azonban van 1-2 nagyobb ország, ahol akár 1-1.5 millió rekord/hó is lehet majd (egyelőre kb. 1 milla a legnagyobb). Az input adatok bekerülnek a táblába, majd utána lekérdezések, szegmentálások (bizonyos mezők kitöltése) fog történni. Amikor eltelik 1 év, akkor "lezárjuk" azaz, nem módosítunk rajta már semmit, azonban bizonyos kimutatásokhoz szükség lesz lekérdezésekre.
Szóval egyelőre kb. 9 adatbázis lenne azokban pedig 3 tábla egyenként max 12-15 millió rekorddal.Ehhez milyen vas kellene? Mi az mi sokat dob a sebességen? HDD, CPU, RAM?
-
#1144
martonx
veterán
Speeedfire
#1137
martonx
veterán
válasz
Speeedfire
#1137
üzenetére
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. -
martonx
veterán
válasz
WolfLenny
#1138
üzenetére
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. -
rum-cajsz
őstag
válasz
WolfLenny
#1138
üzenetére
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.
-
#1140
PazsitZ
addikt
Speeedfire
#1137
PazsitZ
addikt
válasz
Speeedfire
#1137
üzenetére
NoSQL DB-knél, mindegyiknek megvan a maga rendeltetése célja, amire jól hasznosítható.
Nincs és nem is lesz ultimate winner.
[link] -
#1139
Sk8erPeter
nagyúr
WolfLenny
#1138
Sk8erPeter
nagyúr
válasz
WolfLenny
#1138
üzenetére
Nem azt mondom, hogy a view lassabb, hanem UNION-nal bohóckodni itt felesleges - ha a havi lekérdezés extrém ritka, akkor főleg biztos, hogy egy táblába tenném. Teljesen felesleges szétbontani. Szerintem jóval könnyebben optimalizálható a tábla, de majd remélem martonx megmondja a tutit, hogy mi a helyzet ezzel.
-
#1138
WolfLenny
senior tag
Sk8erPeter
#1136
WolfLenny
senior tag
válasz
Sk8erPeter
#1136
üzenetére
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....
-
#1137
Speeedfire
félisten
martonx
#1134
Speeedfire
félisten
válasz
martonx
#1134
üzenetére
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.
-
#1136
Sk8erPeter
nagyúr
WolfLenny
#1135
Sk8erPeter
nagyúr
válasz
WolfLenny
#1135
üzenetére
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. -
#1134
martonx
veterán
Speeedfire
#1132
martonx
veterán
válasz
Speeedfire
#1132
üzenetére
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.
-
#1129
martonx
veterán
Speeedfire
#1128
martonx
veterán
válasz
Speeedfire
#1128
üzenetére
Meg mondjuk ott egy DB szerver akkora, mint egy szoba.
-
martonx
veterán
válasz
WolfLenny
#1126
üzenetére
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.
-
WolfLenny
senior tag
Ú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. -
#1124
Speeedfire
félisten
PazsitZ
#1122
Speeedfire
félisten
-
#1123
Speeedfire
félisten
Sk8erPeter
#1121
Speeedfire
félisten
válasz
Sk8erPeter
#1121
üzenetére
Igen van. A többi sornál működik is a módosítás.
PazsitZ: Na, ezt megnézem majd. -
#1122
PazsitZ
addikt
Speeedfire
#1120
PazsitZ
addikt
válasz
Speeedfire
#1120
üzenetére
Ha attributumon keresztul mentesz nezd meg a safe attributumokat
-
#1121
Sk8erPeter
nagyúr
Speeedfire
#1120
Sk8erPeter
nagyúr
válasz
Speeedfire
#1120
üzenetére
Az adott felhasználónak, akivel kapcsolódsz a Yii-n keresztül, van joga a feltöltéshez is?
-
#1120
Speeedfire
félisten
Sk8erPeter
#1119
Speeedfire
félisten
válasz
Sk8erPeter
#1119
üzenetére
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. -
#1119
Sk8erPeter
nagyúr
Speeedfire
#1115
Sk8erPeter
nagyúr
válasz
Speeedfire
#1115
üzenetére
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! -
#1118
WolfLenny
senior tag
Sk8erPeter
#1114
WolfLenny
senior tag
válasz
Sk8erPeter
#1114
üzenetére
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...
-
#1115
Speeedfire
félisten
Sk8erPeter
#1113
Speeedfire
félisten
válasz
Sk8erPeter
#1113
üzenetére
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.
-
#1114
Sk8erPeter
nagyúr
WolfLenny
#1112
Sk8erPeter
nagyúr
válasz
WolfLenny
#1112
üzenetére
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... -
#1113
Sk8erPeter
nagyúr
Speeedfire
#1111
Sk8erPeter
nagyúr
válasz
Speeedfire
#1111
üzenetére
"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. -
#1111
Speeedfire
félisten
Speeedfire
félisten
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? -
#1109
WolfLenny
senior tag
Sk8erPeter
#1107
WolfLenny
senior tag
válasz
Sk8erPeter
#1107
üzenetére
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?
-
#1108
WolfLenny
senior tag
Sk8erPeter
#1107
WolfLenny
senior tag
válasz
Sk8erPeter
#1107
üzenetére
Ez már jó lehet, csak a kérdés (amit elfelejtettem) hogy ez PHP-ban van....
Valakinek van ötlete erre?
-
#1107
Sk8erPeter
nagyúr
WolfLenny
#1106
Sk8erPeter
nagyúr
válasz
WolfLenny
#1106
üzenetére
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. -
#1106
WolfLenny
senior tag
Sk8erPeter
#1094
WolfLenny
senior tag
válasz
Sk8erPeter
#1094
üzenetére
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.... -
martonx
veterán
válasz
B-L-A-C-K
#1102
üzenetére
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. -
#1103
Sk8erPeter
nagyúr
B-L-A-C-K
#1102
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1102
üzenetére
"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.
-
#1102
B-L-A-C-K
titán
Sk8erPeter
#1101
B-L-A-C-K
titán
válasz
Sk8erPeter
#1101
üzenetére
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...
-
#1101
Sk8erPeter
nagyúr
B-L-A-C-K
#1100
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1100
üzenetére
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
- Új Dell 5330 Latitude 13.3 FHD IPS Touch i5-1235U 4.4Ghz 16GB 512GB Intel Iris XE Win11 Pro Garancia
- Vállalom Xiaomi Okoskamerák szoftveres javíttását
- Gamer PC-Számítógép! Csere-Beszámítás! R7 2700X / GTX 1080Ti / 16GB DDR4 / 512 SSD!
- iKing.Hu - Google Pixel 10 Tensor G5, 120 Hz OLED, tripla kamera-128 GB Használt, karcmentes Gari
- BESZÁMÍTÁS! Apple Studio Display 27 5K Nanotexturált üveg monitor garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest