Új hozzászólás Aktív témák
-
-
Ispy
veterán
válasz bambano #1735 üzenetére
közben rájöttem, dupla aposztrófra gondolhattál, nem idézőjelre.
Igen, mert akkor az SQL motor nem karakterlánc kezdete / vége jelként kezeli, hanem sima aposztrófként a stringen belül.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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?
Én kérek elnézést!
-
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.[ Szerkesztve ]
-
csabyka666
addikt
válasz bambano #2050 üzenetére
Beírtam a Google-ba, és beleolvastam. Szégyen ide, szégyen oda, én ezt így nem fogom megérteni. Az ilyen elméletektől mindig a falat kapartam.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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.
[ Szerkesztve ]
-
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/
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
Ispy
veterán
válasz bambano #2101 üzenetére
MySQL-lel még nem kellett dolgoznom én MS SQL-lel nyomom, remélem ez így is marad, szerencsére hálózati környezetben az SQL expressz változata is jól fut, ami ingyért van és nincs is nagyon alternatívája.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
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.Én kérek elnézést!
-
amargo
addikt
válasz bambano #2110 üzenetére
Azért az oracle ad rengeteg kedvezményt, amennyire mesélték, bár elfelezve az árat is még az MS jött ki olcsóbbnak, ugyanakkor az MS is kezd felzárkózni árazás szempontjából..
mysql lassú volt?“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
amargo
addikt
válasz bambano #2112 üzenetére
Alkuval próbálkoztál?
Ha már volt itt szó sokszor hdd-ról. Valaki rakott már SSD SQL alá?
[link]martonx: Én se értek hozzá csak eddig jókat olvastam róla, aztán lehet csak fizetett hirdetések voltak.. Igen az MS is ad.
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
amargo
addikt
-
csabyka666
addikt
-
csabyka666
addikt
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.Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
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?
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
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?
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
-
csabyka666
addikt
válasz bambano #2266 üzenetére
Ezt is el tudom fogadni, de esetemben például egy áruház nevét kell felvinni, és pl. a G'Roby nevében van aposztróf, és bár anélkül is meglennénk, nehogy ezen akadjon fenn az user, hát valahogy bele kellett vennem...
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
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...
[ Szerkesztve ]
Sk8erPeter
-
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.Sk8erPeter
-
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.Sk8erPeter
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen