Hirdetés
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Fejhallgató erősítő és DAC topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen TV-t vegyek?
- VR topik (Oculus Rift, stb.)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD Navi Radeon™ RX 9xxx sorozat
- Raspberry Pi
- Projektor topic
- Milyen billentyűzetet vegyek?
Új hozzászólás Aktív témák
-
#1521
Peter Kiss
őstag
TomyLeeBoy
#1520
Peter Kiss
őstag
válasz
TomyLeeBoy
#1520
üzenetére
Be kell rendesen állítani a MySQL szervert. Sőt, igazából először azt sem ártana tudni, milyen engine-nel megy most az adatbázis illetve a táblái. Ja, indexek át lettek költöztetve (voltak-e egyáltalán)?
Emellett gond lehet PHP oldalról, hogy másik verzió, amiben nem működik valami jól az alkalmazással.
-
#1417
Peter Kiss
őstag
Sk8erPeter
#1416
Peter Kiss
őstag
válasz
Sk8erPeter
#1416
üzenetére
A gond szerintem ott lesz, hogy gyakorlatilag a PH!-n is hirdet, és, ha valaki meglátja a megkérdőjelezést, akkor elbizonytalanodhat. Mi kérünk elnézést?
-
#1412
Peter Kiss
őstag
biker
#1410
Peter Kiss
őstag
Arra hivatkozni, hogy redundás lesz a termék ID-ja, az kicsit megmosolyogtató, egy SQL szervernek ez nem érdekes.
Termékek tábla:
id,
név,
rövid leírás,
hosszú leírás,
cikkszám,
vonalkód,
kat_id,
+ ki mikor módosította és még e mögé a tábla mögé még egy, ami minden sort ment triggerrel.Kellene egy szállítók, és a szállítókkal összerendelő:
szállítói kód,
szállítási idő,
termék_id
+ mettől meddig ki és mikor módosítottaCímkék nyilván nem kerülhetnek ide, szintén: címkék tábla + összerendelés + audit;
ÁFA osztály inkább tartozik a kategóriához, ha egy termék csak egy kategóriában lehet.
Egy termék árát szintén külön táblában vezetjük, hogy lássuk, mettől meddig mennyi volt, és ki módosította. (Nem beszélve arról, hogy már a jelenben beszélhetünk a jövőről.)
Az akciókat belekeverni talán a legdurvább, azt eleve ki kell vezetni, hogy milyen akcióink vannak, meddig tart és mi tartozik bele, nyilván a beállításai (melyik/minden termék hány százalékkal, stb) + az auditálási dolgok megint.
Csík így hirtelen pongyolán ezek jutottak eszembe. A gond az, hogy elég lenne csak egy "ki mit csinált" kérdést feltenni a te szerkezetedhez, fel kellene tenned a kezed, hogy izé, az úgy volt.
. -
#1408
Peter Kiss
őstag
biker
#1407
Peter Kiss
őstag
A woocommerce sem azért lassú, mert van benne +2-3 tábla, hanem azért, mert nincs benne semmi sem optimalizálva. Szar index-ek lehetnek benne, lehet, hogy még FKEY-ek is hiányoznak, nehogy értelmesen el tudjon rajta menni az optimizer. Emellett nyilván benne van, hogy egyszerűen rosszul futtatják a lekérdezéseket benne (teszem azt termékenként és jellemzőként 1-1 lekérdezés és hasonlók).
Tervezési hiba, mert sem egy SQL szerver sem pedig a programnyelvek, technikák nem úgy vannak kitalálva, hogy ekkora adathalmazt így kezeljenek, gyakorlatilag ez azt jelenti, hogy lenne egy pl. egy sima PHP osztályod 30+ property-vel, ami fed egy sort (2*30+, ha külön getter-setter), ez nem kezelhető. Plusz olyan rugalmas így a cucc, mint az öntött vas.
-
#1406
Peter Kiss
őstag
biker
#1405
Peter Kiss
őstag
"Sima select/where felallast meg latvanyosan nem is gyorsit az index, tapasztalat"
He?
Tehát, ha 3 DATETIME oszlopra szűrök, akkor végül is tök felesleges indexelni mondjuk egy 10 millió soros táblában, mert nem lesz látványos? Vagy az előző példa nem eléggé az? 
MATCH() ... AGAINST FULLTEXT index esetén van, ez egy elég speciális cucc CHAR, VARCHAR és TEXT típusú oszlopokhoz, arról nem is beszélve, hogy 5.6 alatt nem lehet használni InnoDB táblákkal.
Plusz megjegyezném, hogy, ha van egy táblánk, ami 30+ oszloppal rendelkezik, akkor igazából egy tervezési hibával állunk szemben.
-
#1403
Peter Kiss
őstag
Drótszamár
#1402
Peter Kiss
őstag
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.
-
#1400
Peter Kiss
őstag
Drótszamár
#1399
Peter Kiss
őstag
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.
-
#1398
Peter Kiss
őstag
Drótszamár
#1397
Peter Kiss
őstag
válasz
Drótszamár
#1397
üzenetére
Pontosan hogyan néz ki az index, és miért MYISAM?
-
#1310
Peter Kiss
őstag
Brown ügynök
#1306
Peter Kiss
őstag
válasz
Brown ügynök
#1306
üzenetére
Ha már optimalizálás, ma találkoztam egy problémával, egy drop down list-et, amiben 2000 elem volt kb. 8000 SQL lekérdezéssel (mindegyikhez volt 4) töltött fel egy hülyegyerek. Újraírtam, hogy lejöjjön egyben.
-
#1304
Peter Kiss
őstag
Brown ügynök
#1303
Peter Kiss
őstag
válasz
Brown ügynök
#1303
üzenetére
Elsőre szar lekérdezések (és indexek), illetve rosszul beállított szerver. Az a baj, hogy ezt már tényleg látni kellene.
-
#1283
Peter Kiss
őstag
spammer
#1282
Peter Kiss
őstag
válasz
spammer
#1282
üzenetére
Nem oké. Ha így számolod a sorokat mondjuk egy 5 millió soros táblában, akkor azt nagyon rosszul teszed.
SELECT COUNT(*) AS RowCount FROM posts
Aztán lekéred ennek az eredményhalmazát mint bármelyik más SELECT-nek, fetch-eled mondjuk objektumba (egy sorod lesz), az így kapott objektum RowCount field-jében lesz benne a COUNT(*) eredménye.
-
#1271
Peter Kiss
őstag
martonx
#1269
Peter Kiss
őstag
válasz
martonx
#1269
üzenetére
így igaz.
@Jester01
BIT(M) = approximately (M+7)/8 bytes
B-Tree esetén value-t és record pointer-t tárol (MyISAM - offset, INNODB - primary key) szóval számít itt is a méret. "Alap b-tree index" kapcsán nem tudom, mire gondolsz, de, ha a primary key-re INNODB-ben (clustered index), akkor abban valóban foglal helyet egy BIT(N), hacsak nem az a primary key, de ilyen index, ha hatalmas a tábla, kb. nem való semmire, csak a JOIN-ok gyorsítására PKEY mentén. -
#1264
Peter Kiss
őstag
spammer
#1263
-
#1208
Peter Kiss
őstag
Phvhun
#1207
Peter Kiss
őstag
ValidFrom, CreatedBy, ValidTo, ClosedBy oszlopokkal ki kell egészítened azt a tábládat, amiben ilyen adatok vannak, de nem kell feltétlenül mindennek ebben lennie, készíthetsz egy plusz táblát, ami ...History, és abban van benne minden (ezzel a megoldással egyszerűbb ORM framework-höz illeszteni a cuccot).
-
#1189
Peter Kiss
őstag
SureStudio
#1188
Peter Kiss
őstag
válasz
SureStudio
#1188
üzenetére
szelekt csillag from regisztrációk
-
#1103
Peter Kiss
őstag
DanielK
#1102
Peter Kiss
őstag
-
#1063
Peter Kiss
őstag
laracroft
#1062
Peter Kiss
őstag
válasz
laracroft
#1062
üzenetére
A COUNT() mindig a paraméterként megadott expression-t vizsgálva NULL-ra. Ha nem NULL, akkor beleveszi az adott elemet a végső összegzésbe. A COUNT(1), COUNT(*) sosem NULL (Oracle alatt a COUNT(1)-ből COUNT(*) lesz elvileg), így azonos a kettő. Ha field nevet adsz át, akkor abban az esetben, ha az adott rekordot adott field-je alatt NULL value van, akkor azt nem fogja összeszámolni.
-
#1061
Peter Kiss
őstag
laracroft
#1060
Peter Kiss
őstag
válasz
laracroft
#1060
üzenetére
http://dev.mysql.com/doc/refman/5.6/en/counting-rows.html - a dokumentációs oldalak publikusak.
-
#968
Peter Kiss
őstag
Peter Kiss
őstag
http://www.sitepoint.com/dbninja-mysql-client/ - egy próbát talán megér.
-
#962
Peter Kiss
őstag
Speeedfire
#961
Peter Kiss
őstag
válasz
Speeedfire
#961
üzenetére
Első kép:
Kihagy 10-et;
Látszik: 11, 12, 13, 18, 19 és fölötte;Második:
Kihagy 15-öt;
Látszik: 20 vagy fölötte; (15-10 => 5 darab, ami:11, 12, 13, 18, 19) -
#959
Peter Kiss
őstag
Speeedfire
#958
Peter Kiss
őstag
válasz
Speeedfire
#958
üzenetére
Teljesen jól működik, amennyire látom.
-
#914
Peter Kiss
őstag
Sk8erPeter
#912
Peter Kiss
őstag
válasz
Sk8erPeter
#912
üzenetére
Igazából ezért hegesztek magamnak keret a .NET framework mentén (nyilván kisebbet, egyszerűbbet), építés közben szoktam néha ledöbbenni, hogy mennyire adják egymást a megoldások, pl. nem egyszer volt, hogy kigondoltam egy megoldást az adott problémára, és pont ugyanazzal a megközelítéssel találkoztam az MSDN-en is.
-
#909
Peter Kiss
őstag
Sk8erPeter
#907
Peter Kiss
őstag
válasz
Sk8erPeter
#907
üzenetére
Entity Framework meg az ASP.NET MVC (nem PHP-s, tudom, kapjam be).
Amelyek most mennek nagyobb frameworkok mindegyik bugzik, a Zend Framework 2-t szeretném majd jobban átvizsgálni, illetve a Symfony-t, Doctrine-t.
-
#906
Peter Kiss
őstag
Speeedfire
#904
Peter Kiss
őstag
válasz
Speeedfire
#904
üzenetére
Az active record-dal az a baj, hogy egy tervezési hiba.
$post=new Post;
$post->title='sample post';
$post->content='post body content';
$post->save();Ez a kód a Yii oldaláról való, látható, hogy van egy objektumunk, ami mindent megcsinál helyben, ilyet nem szabad csinálni. Egy ilyen rendszerben szépen szét kell szedni mindent: unit of work, identity map, meta data, entity, query object, miegymás. Nyilván könnyebb haszálni egy AR megoldást, de igazából ultragáz.
Belepillantottam a CActiveRecord osztályba, itt aztán minden van.
Ami még nagyon tud fájni, hogy nincs benne normális object tracking, de van valamiféle meta leírása, ám az, hogy előírnak egy static metódust a dokumentációban, hogy ezt márpadigimplementálodmánazonnal ahelyett, hogy normálisan felépítenék az egészet, mindent visz. Úgy kell elképzelni az AR-t, mintha egy relációs adatbázisban a táblák a sorok és minden leírást tartalmazó cucc egy valamiben lenne (talán még az adatbázismotor is).
-
#903
Peter Kiss
őstag
Speeedfire
#902
Peter Kiss
őstag
válasz
Speeedfire
#902
üzenetére
Az AR-t lehet ORM-nek nevezni, de nem az igazi.
-
#901
Peter Kiss
őstag
Speeedfire
#898
Peter Kiss
őstag
válasz
Speeedfire
#898
üzenetére
Azért, mert gyakorlatilag nem használt (nem feltétlenül szükséges lementeni) adat van az adatbázisban, egyszerűen felesleges.
-
#897
Peter Kiss
őstag
Speeedfire
#895
Peter Kiss
őstag
válasz
Speeedfire
#895
üzenetére
Nem az adatbázist kell lecserélni, hanem az azt kezelő PHP programhalmazt. Google: PHP ORM
Egyébként a salt tárolása ellent mond a relációs adatbázisok "működési elvének", hiszen kvázi redundánsan tárolsz adatot.
-
#893
Peter Kiss
őstag
Speeedfire
#892
Peter Kiss
őstag
válasz
Speeedfire
#892
üzenetére
Ha az AR active record akar lenni, akkor illene utána nézni valami normális ORM rendszernek.
-
#891
Peter Kiss
őstag
Speeedfire
#890
Peter Kiss
őstag
válasz
Speeedfire
#890
üzenetére
A salt-ot nem kell menteni, lehet olyat csinálni, hogy mindenkinek mindig random, működik a jelszóellenőrzés is, én is ilyet csináltam.
Azzal, hogy constansaid vannak, még nem vagy kisegítve SQL oldalon.
-
#887
Peter Kiss
őstag
Speeedfire
#885
Peter Kiss
őstag
válasz
Speeedfire
#885
üzenetére
A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.
Ha pakolsz a rendszerbe állapotokat mutató oszlopokat, akkor ki kellene vezetni a lehetséges értékeket külön táblába, pl. tbl_forum_status. Ezt sokan el szokták felejteni, pedig integritást lehet vele növelni, plusz sem programkód, sem adatbázisoldalról nem kell keresgetni, hogy az "1"-es állapot mégis mit takar, plusz pl. tárolt eljárások írásánál minden kiegészítőinformáció jól jöhet.
A tbl_user táblában miért van benne a salt?
Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.
A tbl_ prefix nem rossz ötlet, hasznos tud lenni, mi pl. a táblákat pont nem látjuk el prefix-szel, de a view-ok v-vel, user defined function-ok uf/udf-fel kezdődnek, tárolt eljárások pedig usp-vel, így mindig lehet tudni, hogy miről is van szó, ami pl. több száz soros sp-k esetében nagy előny.
Ugye lesznek majd index-ek is?
.
Ami még nagyon tud fájni, hogy nincs benne normális object tracking, de van valamiféle meta leírása, ám az, hogy előírnak egy static metódust a dokumentációban, hogy ezt márpadigimplementálodmánazonnal ahelyett, hogy normálisan felépítenék az egészet, mindent visz. 
Új hozzászólás Aktív témák
- Luck Dragon: Asszociációs játék. :)
- EA Sports WRC '23
- BMW topik
- Linux kezdőknek
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Kerékpárosok, bringások ide!
- Elemlámpa, zseblámpa
- Fejhallgató erősítő és DAC topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Premier előzetesen a Cronos: The New Dawn
- További aktív témák...
- Újra Akcióban!!! Ducky One 2 Mini és SF billentyűzetek a bolti ár töredékéért! Számla+Gari
- LG 34GS95UE - 34" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Apple Pad 5.generácio / 32GB / Wi-fi / 12Hó garancia
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
- Samsung Galaxy Tab A8 32GB, Újszerű, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest