Hirdetés
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: A RAM-válság és annak lehetséges hatásai
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- gban: Ingyen kellene, de tegnapra
- GoodSpeed: Márkaváltás sok-sok év után
- D@reeo: Pi-hole és a Telekom Sagemcom F@st 5670 DNS beállítása
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
bambano
#2385
üzenetére
A sorokat össze tudod húzni persze. Mondjuk minden sornak te adsz egy növekvő azonosítót (MSSQL-ben ez a RANK), és ez az azonosító alapján joinolod össze a táblát saját magával eggyel elcsúsztatva egymáshoz képest.
Ezután a dátumok kivonása már gyerekjáték, azt meg nem írtad, hogy hogy akarod súlyozni a végeredményt, de szerintem minden adott a feladatod megoldásához. -
#2377
dellfanboy
őstag
bambano
#2376
-
#2364
dellfanboy
őstag
bambano
#2362
-
#2279
Sk8erPeter
nagyúr
bambano
#2278
Sk8erPeter
nagyúr
válasz
bambano
#2278
üzenetére
Hinnnye, de fárasztó vagy.
Ezeket az agymenéseket miért nem rakod inkább OFF-ba?
Jójó, legyen igazad, rohadjon meg a júzer, és ne akarjon feltölteni aposztrófot tartalmazó stringet, hát mégis mi az anyját képzel?? A cégneve tartalmaz aposztrófot? Kapja be, menjen szépen a Cégbíróságra, változtassa meg! HÁNEHOGYMÁHE!"az elképzelés, hogy nem foglalkozom az inputtal, mert a prepared statement elvileg véd az sql injection ellen, hamis biztonságérzetet ad. pláne egy olyan korszakban, amikor crontabból küldik a heti snowden dokumentet"
Mi van, emba'? Valóban sok az összefüggés az NSA és az aposztrófok között, olyannyira, hogy csak a "biztonságérzet" szó használata miatt nyilván tök indokolt volt ilyen moslékot idekeverni. 
Mondjuk most pont tök szórakoztató ilyeneket olvasgatni, amikor valaki túlheveskedi a kommentjeit, de valószínűleg kicsit más hangulatban írjuk épp a hsz.-einket. 
-
#2276
Sk8erPeter
nagyúr
bambano
#2275
Sk8erPeter
nagyúr
válasz
bambano
#2275
üzenetére
Köszönöm, nem szükséges helyettem megfogalmazgatni bármit is, magamtól is megy, meg úgy látom, így is sikerült pár perccel később felfognod.
Szerintem meg nem, nem természetes, hogy tiltod az aposztrófot egy cégnévben, ahogy az sem, hogy miért merül fel egyáltalán a para, hogy ez SQL Injectiont okozhatna, ha normálisan prepared statementeket használsz, de nekem mindegy. -
#2273
Sk8erPeter
nagyúr
bambano
#2272
Sk8erPeter
nagyúr
válasz
bambano
#2272
üzenetére
Azt írtad, "Én egyáltalán nem hagyom, hogy sql injectionra alkalmas karaktert bevigyen az user.", ebből arra lehetne következtetni, hogy nálad a felhasználótól érkező aposztróf már alkalmas lehet SQL Injectionre, amitől tartani kell, tehát jobb, ha már az alkalmazásban kiszedjük, mielőtt feltöltenénk adatbázisba.
De én is csak szúrkálódom, nem kell ám mindent komolyan venni. Igaz, az összefüggést a két dolog közt még mindig nem értem, hogy AZÉRT tiltod az aposztróf bevitelét, mert alkalmas lehetne SQL Injectionre...
-
#2267
csabyka666
veterán
bambano
#2266
-
#2183
csabyka666
veterán
bambano
#2181
-
#2182
csabyka666
veterán
bambano
#2181
válasz
bambano
#2181
üzenetére
Akkor nem értem, nálam miért csak úgy fogadja el.
Pedig már közel állok az igazsághoz.Illetve probléma még az is, ha a mezőben, amiben keresek, több szó van, szóközzel elválasztva. Akkor azt nem találja meg. Pl. a mező tartalma: "találj meg", és ha beírom a keresőmezőbe, hogy "találj meg", akkor nem ad találatot.
Összefűztem a CONCAT()-tal SQL-ben, és | jelek vannak a keresőkifejezésben. Hát nem tudom, mi lehet a baj.
Nem akad össze a | jel? Mert a CONCAT()-ban is azokat használom.Hogy értetted, hogy VAGY-gyal csináljak egy végső logikai kifejezést?
-
#2180
csabyka666
veterán
bambano
#2178
válasz
bambano
#2178
üzenetére
Köszi a választ, félsiker már van.
Szűkíti a találati listát, viszont ahhoz, hogy eredményt kapjak, abban a sorrendben kell beírnom az adatokat, ahogy az összefűzésben szerepel.
Ezt írtam:
WHERE CONCAT(mezo1,'|',mezo2,'|',mezo3,'|',mezo4) LIKE \"%$keresokifejezes%\"A $keresokifejezes-ben így|szerepelnek|a|beírt|szavak.
Ezekből csináljak VAGY-gyal egy végső kifejezést, amiben az összes előforduló sorrend szerepel? Szóval lesz egy tekintélyes hosszúságú SQL lekérdezésem?
-
#2177
csabyka666
veterán
bambano
#2175
válasz
bambano
#2175
üzenetére
Próbáltam több módon is a LIKE-al, DISTINCT-el, de vagy az van, hogy én mondtam rosszul, amit el akarok érni, vagy valamit rosszul írtam a PHP-ban, vagy te értelmezted rosszul...a fene se tudja, a lényeg, hogy nem sikerült összehozni.
Nem értem azt sem, hogy miért nem kell lefutnia többször a query-nek? Van 4 mezőm, amiben keresni akarok, és mindezt úgy, hogy minden egyes beírt szóra megnézem, hogy illeszkedik-e bármelyik mezőre is.
Szóval beírom, hogy "ezt akarom megkeresni", és ebből - értelmezésem szerint - mindhárom szót meg kell néznem mind a 4 mezőn. (Tehát annyiszor futtatom a query-t, ahány szót megadok neki.)Azt már elértem, hogy csináltam egy tömböt, amibe beletettem mindegyik keresőszót, és ezen végigmentem, majd lefuttatom a query-t mindegyik szóra. Vissza is adja, hogy melyik indexeket találta meg (és ráadásul jót ad vissza), de ott akad meg a dolog, hogy ezeknek nem tudom a metszetüket venni. 99% hogy ez így működne, ha tömbökbe tudnám tenni a keresések eredményeit, mert azoknak tudom metszetüket venni.
Ha van ennél egyszerűbb módszer, akkor szívesen meghallgatom azt is, de így most tanácstalan vagyok.
A lényeg ugye az lenne, hogy csak azt a sort (esetleg sorokat) adja vissza a legvégén, amelyikre az összes beírt kifejezés passzol, vagyis a metszetüket.
Tehát:
...WHERE
mezo1 LIKE '%$keresokifejezes%' OR
mezo2 LIKE '%$keresokifejezes%' OR
mezo3 LIKE '%$keresokifejezes%' OR
mezo4 LIKE '%$keresokifejezes%'
...és persze minden mezőt minden kifejezésre meg kellene vizsgálnom. -
#2176
csabyka666
veterán
bambano
#2175
-
#2174
csabyka666
veterán
bambano
#2173
-
martonx
veterán
válasz
bambano
#2104
üzenetére
Pedig postgreSQL-lel is lehet clustert építeni. Sőt az ingyenes MySQL-el is.
Ettől függetlenül szerintem is Oracle és MS SQL a két komolyan vehető adatbázis szerver. Mondjuk az Oracle aranyárban van, bár talán nem is véletlenül adják annyiért.
Ami még nagyon jó alternatívája az ingyenes SQL-eknek, az a Microsoft féle Azure SQL, ami bérelhető MS SQL 2012 szerver, némi felhős butítással. Az enyém havi kemény 4 euróért, napi 9 millió rekordot fogad magába, hogy aztán 1 órán belül ezek nagy része törlődjön is, és még ehhez jönnek az egyéb queryzések. 4 euróért zseniális a teljesítménye. -
modder
aktív tag
válasz
bambano
#2081
üzenetére
Nem nagyon voltak meggyőző érvek a szöveges tárolás ellen. A település név tök jó példa.
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig? Egy településeket tartalmazó táblára mindig szükségünk van, mert valahol el kell tárolni a lehetséges értékeket.
bambano:
Sématervezési szempontból semmivel sem rosszabb, ha szövegként van tárolva a település neve a személy táblában. Ez nem növeli a redundanciát, se nem lesz denormalizált. Redundanciáról akkor beszélhetnénk, ha a lélekszámot is mindig eltárolnánk a település neve mellett a személyek táblában, mert a település neve meghatározná a lélekszámot, így ez utóbbi tárolása is (még mindig a személyek táblában) csak bonyodalmat okozna. Pontosan ez is a redundancia definíciója. Ha már a normálformákat hoztad fel, vegyél elő egy egyetemi jegyzetet, és olvass bele. Vagy pl. ez egész jól leírja: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.2Ha van egy település táblánk, a település neve - mint szöveg - ugyanúgy lehet idegen kulcs a személyek táblában. Nem kell ahhoz numerikus elsődleges kulcs, hogy kikényszerítsük a személyek táblában, hogy csak bizonyos település neveket lehessen felvinni.
"azok után pedig, hogy azt állítottam, az sql-ben a teljesítményt feláldozzuk más célok elérése érdekében, ez a link mennyiben releváns?"
Attól, hogy állítasz valamit, az még nem biztos, hogy igaz. Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el, pedig az SQL csak arra jó, hogy nem neked kell megírnod, hogy mikor melyik indexeket akarod használni. De az SQL végrehajtási tervbe fordítása mellett még száz másik szempont van, ami nagyban befolyásolja a lekérdezés sebességét, aminek semmi köze ahhoz, hogy milyen lekérdezőnyelvet használsz. És persze az sql-t is többféleképpen írhatod meg, hogy segíts az optimalizálónak a hatékonyabb végrehajtási terv elkészítésében.martonx: Köszönjük a hozzáértő, szakmailag megalapozott hozzászólást
Ami megfontolandó:
- karakterkódolási problémák: Ez általában olyan, hogy vagy fennáll az egész adatbázisra és az őt használó alkalmazásra, vagy nem, ami persze más szöveges mezőket is érint.
- "könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?
- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?
- tárolás: a szöveg több byte-ot használ felA hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni, amikor a tárolási kapacitás és pl. a beszúrási (index frissítési) sebesség sarkalatos pont, ami egy "egyszerű" webalkalmazásnál ritkán fordul elő.
pazsitZ: leginkább mysql cli, phpmyadmin vagy egyéb kliens programra gondoltam, amikor kotorászásról beszéltem.
-
modder
aktív tag
válasz
bambano
#2077
üzenetére
Normalizálás kérdés: Lehet, hogy félreértettél. Legyen egy státusz mező és a kérdés, hogy ha van egy aktív és passzív érték, akkor azt numerikusan (0 és 1-gyel) vagy charként ("active" és "passive") érdemes-e tárolni. Ez esetben miért lenne az első normalizált, a második pedig denormalizált abban az értelemben, amit te is említettél, azaz ha normálformákról beszélünk.
Az eredeti kérdésemre pedig kaptam egy linket, ami nagyjából le is fedi az én esetemet: http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
-
modder
aktív tag
válasz
bambano
#2073
üzenetére
attól, hogy stringként tárolom ugyanazt az információ tartalmú adatot, még nem lesz denormalizált.
A mezők kb max 10-féle értéket vehetnek fel, szóval numerikus számozással 1..10-ig. Csak a kérdés az, hogy mennyivel rosszabb/kevésbé hatékony az, ha én nem numerikus értékként akarom tárolni az információt (és kódban egy enumhoz kötöm), hanem egy max 20 hosszú karakterláncként.
-
#2051
csabyka666
veterán
bambano
#2050
-
Kommy
veterán
válasz
bambano
#2028
üzenetére
Hát igen ez lett úgy néz ki a megoldás, de akkor is zavar, hogy miért nem megy join-al
(#2029) fordfairlane: nem ír semmi hibát, amúgy ez egy visual studio-ban íródó program ami Microsoft Access adatbázisból dolgozik.
(#2031) martonx: Amúgy igen eltér egymástól mivel ebben már van egy csomó rekord (több 100), én örülnék a legjobban ha tiszta lenne és nem kénének a régi adatok.
De most simán bambano ajánlása szerint működik
Megpróbálom azért úgy is. -
martonx
veterán
válasz
bambano
#1830
üzenetére
Lehet, hogy félreértettelek. Úgy értettem, hogy egy query eredményeként kigenerálsz egy rakás SQL query-t, és ezeket szeretnéd egymás után futtatni programozottan.
Hja, normálisabb SQL nyelvekben ehhez nem kell tárolt eljárás, PostgreSql-ben valóban kell (bár mintha 9.1 / 9.2 újdonsága lenne, hogy immár tárolt eljáráson kívül is lehet benne magasabb szintű nyelvi elemeket is használni)
Kettes kérdésedet nem tudom értelmezni, lehet azért mert még mindig nem értem, hogy mit is szeretnél?
Hármas kérdésedre sem tudok válaszolni. Ha van, akkor használd azt. Öröm - boldogság. Ha nincs, akkor örülök, hogy segíthettem a for-os ötletemmel.Azért végezetül megpróbálnád összefoglalni, hogy mit is szerettél volna, és végül mi lett a legegyszerűbb megoldás?
Ezeket az agymenéseket miért nem rakod inkább OFF-ba?
Mondjuk most pont tök szórakoztató ilyeneket olvasgatni, amikor valaki túlheveskedi a kommentjeit, de valószínűleg kicsit más hangulatban írjuk épp a hsz.-einket. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- KAÜ/Ügyfélkapu – már elérhető a kétfaktoros hitelesítés
- Mennyibe fog kerülni a Steam Machine?
- Sweet.tv - internetes TV
- Teljes verziós játékok letöltése ingyen
- Jövedelem
- sziku69: Szólánc.
- E-roller topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Autós topik
- További aktív témák...
- GYÖNYÖRŰ iPhone 14 Pro 256GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3959, 100% Akkumulátor
- Honor 90 /12/512GB / Kártyafüggetlen / 12Hó Garancia
- HIBÁTLAN iPhone 14 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3531, 93% Akkumulátor
- Samsung Galaxy A16 / 4/128GB / Kártyafüggetlen / 12Hó Garancia
- MacBook Pro 13, 14, 15, 16, MacBook Air M1, M2 M3 M4 bill magyarosítás lézerrel / sapkacserével
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest