Új hozzászólás Aktív témák
-
L3zl13
nagyúr
válasz Drótszamár #218 üzenetére
A esetben mitől lenne 101db query a listázás?
sql-ben összejoinolod a két táblát, és egy lekérdezésből megvagy...
Másrészt meg a felhasználók adatai gondolom regisztrációból jönnek.
Na most hyogyan oldod meg, hogy ezek az adatok mindig visszaíródjanak a táblába minden egyes új hozzászólásnál?
És ha módosulnak az adatok? Az összes rekordban módosítod őket?
MySQL asszem nem tud view-t, de szvsz az lenne az ideális a listázásra. A tárolás pedig mindenképp több táblára szétbontva.Aki hülye, haljon meg!
-
L3zl13
nagyúr
válasz Drótszamár #220 üzenetére
Szvsz view-nál (ha 5.x-es MySQL-t használsz) nem ilyen rossz a helyzet. Szvsz még sima SQL joinnál is van optimalizáció, amitől nem olyan vészes.
Aki hülye, haljon meg!
-
lao ce
aktív tag
válasz Drótszamár #220 üzenetére
nem vagyok mysql specialista, de talan segithetek egy kicsit.
te azt kerdezted, hogy 100 hozzaszolas lekerdezese (gondolom egymas utani), egy ilyen szituacioban gyorsabb-e ha denormalizalt adatbazisod van. igen, lehet hogy gyorsabb, bar talan nem sokkal, hiszen valoszinuleg hdd-hez kell nyulni az adatmennyiseg miatt. ha pontosan ez a feladat es semmi mas, akkor ez eleg is.
de sosem csak ennyi a feladat, es akkor bizony jo ha van valami normalizalas is, ne kelljen mar varni harom percet mire kiadja a gep mondjuk, hogy kik az aktiv forumtagok, nem?
a view csak egy eltarolt query, szoval csodat ne varj tole. sebesseg szempontbol azt hiszem tok mindegy, hogy view-t vagy query-t hasznalsz, ha azt mondod kered a csillagot a view-bol akkor siman lefut a view query-je.
masik dolog: feltetelezhetoen a 'hozzaszolasok' sokszorannyi helyet foglalnak mint az az 'aprosagok' (mint nick, email stb), szoval ezek hozzafuzese a tablahoz nem jelentene merheto lassulast egy keresesnel vagy valogatasnal.
vagyis en amit csinalnek, az az, hogy lenne egy normalizalt tabla strukturam ahogy annak rendje es modja, de ettol fuggetlenul benne lenne a nagy uzenet tablaban minden felhasznaloi adat ami kell az altalad irt lekerdezeshez. ez nagyon kicsi tuladminisztralasa a dolgoknak, a hdd space meg igen olcso.nicht kompot
-
válasz Drótszamár #1397 üzenetére
Pontosan hogyan néz ki az index, és miért MYISAM?
-
válasz Drótszamár #1399 üzenetére
InnoDB jobban bírja az INSERT-et.
---
Ez a két index haszontalan, 1-1 oszlop nagyon ritkán jó külön indexelve, készíts olyat, amiben az első oszlop a muszer_id és a második a datum. És azon túl, hogy haszontalan, feleslegesen rontja az insert-teljesítményt is.
Az ellenőrzésed nem tudom, hogyan néz ki pontosan, de a fenti query-t alapul véve inkább egy kellene:
SELECT dátum FROM tábla WHERE (műszer_id="xxx") and (dátum="2013.08.18 18:00:00" or dátum="...") LIMIT 1;
Vagy lehetne még EXISTS-et is használni.
Emellett nem tudom, hogyan futtatod ezeket? 1 INSERT előtt 1 SELECT? Lehet, hogy érdemes lenne előbb lemarni az összes kizáró tényezőt alkalmazás szinten, ha lehet, majd csak a ténylegesen beszúrandókat elküldeni, és így 2 hívásból megvan az egész.
---
Utolsó dolog, amire figyelni kellene, az a szerver beállítása, helyből a MySQL egy 10+ éves gépre van optimalizálva 5 MB memóriával.
-
válasz Drótszamár #1402 üzenetére
Az indexelés sokszor nem triviális, mert pl. ha a WHERE-ben 2 oszlopot fet az index, és pl. a SELECT-ben benne van az a 2 és még egy, akkor akár azt az egyet még mellé lehet tenni, és akkor tisztán indexből dolgozhat a cucc.
Új hozzászólás Aktív témák
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Autós kamerák
- Android alkalmazások - szoftver kibeszélő topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Ukrajnai háború
- Videó stream letöltése
- Gaming notebook topik
- Motorola Moto G24 Power - hol van az erő?
- Milyen videókártyát?
- Helldivers 2 (PC, PS5)
- További aktív témák...