- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
ph A cég megoldása centralizált vezérelhetőséggel, masszív radiátorral és robusztus ventilátorokkal igyekszik vásárlásra csábítani.
Új hozzászólás Aktív témák
-
martonx
veterán
válasz Panhard #2017 üzenetére
Egyrészt ez így tipikusan sql injection problémás kód vagy inkább
Másrészt, ha YEAR(date) = 2018 helyett YEAR(date) IN (2018, 2017, 2016 ... ) szintaktikát használsz, akkor máris működik, amit szeretnél. Ehhez nyilván majd egy kis PHP kód módosítás is kelleni fog, hogy ilyen kinézetre hozd a GET-ben kapott paramétereket.
Én kérek elnézést!
-
-
instantwater
addikt
-
instantwater
addikt
válasz Panhard #2145 üzenetére
Kérlek használj parameter bindinget, mert így sérülékeny a rendszer SQL injectionnel szemben.
Bármi SQL beküldhető a paraméterben és némi okoskodás után csúnya dolgokat lehet művelni.Sima indexet állíts be, ne unique indexet.
Egy időbélyeget nincs értelme unique indexbe tenni, hiszen egy adott pillanatban történhetett több minden amit el akarsz tárolni, és ha unique az index akkor hibát fogsz kapni.Korábban írtad, hogy a dátum meződ a primary key.
Erre van valami ok?
Primary key általában egy auto increment mező, az user email címe, uuid vagy hasonló szokott lenni. -
martonx
veterán
válasz Panhard #2210 üzenetére
gyanítom a cast-olás lassít még rajta, bár nem hiszem, hogy ezen drasztikusan tudnál még gyorsítani. Ha ennyire kritikus a sebesség, akkor érdemes lenne eleve úgy tárolnod az adatokat, hogy ne kelljen castolni.
Vagy ha kell datetime-ként is és date-ként is, lehet kipróbálnám, hogy mindkét módon redundánsan letárolnám ugyanazt az adatot.
Másik lehetőség, hogy tárold le ezt az adatot napokra groupolva is, ez persze megint redundáns tárolást jelent, de biztos, hogy gyorsabb lesz az így előre groupolt adatokat lekérdezni, mint on-the-fly groupolni sok millió adatot.Én kérek elnézést!
-
nevemfel
senior tag
válasz Panhard #2212 üzenetére
Ha 5.7 vagy frissebb verziójú a mysql, próbáld ki generált mezővel, és arra rakott indexszel:
ALTER TABLE `teszt` ADD (
`gpsdate` DATE GENERATED ALWAYS AS (CAST(`gpsdatetime` as DATE)) STORED,
KEY `gpsdateindex` (`gpsdate`)
)[ Szerkesztve ]
Forget your troubles, c'mon get happy
Új hozzászólás Aktív témák
- Villanyszerelés
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Viccrovat
- Gaming notebook topik
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Elemlámpa, zseblámpa
- Azonnali VGA-s kérdések órája
- SSD kibeszélő
- OLED TV topic
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- További aktív témák...