- Samsung Galaxy S23 Ultra - non plus ultra
- Google Pixel topik
- Sokat fejlődött a Tecno belépő ajánlata
- Minden készen áll a Galaxy Unpackedre
- Honor 200 - kétszázért pont jó lenne
- Apple iPhone 16 Pro - rutinvizsga
- Honor 200 Pro - mobilportré
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Hammer 6 LTE - ne butáskodj!
Új hozzászólás Aktív témák
-
#2754
bambano
titán
Sk8erPeter
#2751
bambano
titán
válasz
Sk8erPeter
#2751
üzenetére
Az alapján, amit írtál, ezt faragtam, ez közelíti meg legjobban a korrekt rendezést szerintem:
select street_id,number, substring(trim(leading ' ' from number), '^[0-9]+')::integer,
trim(leading '/-' from trim(leading '0123456789' from trim(leading ' ' from lower(number))))
from locations order by 1,3,4;kösz az ötleteket.
-
#2750
bambano
titán
Sk8erPeter
#2749
bambano
titán
válasz
Sk8erPeter
#2749
üzenetére
úgy látom, pgsqlnek nem jó:
ERROR: invalid input syntax for integer: " 51/g" -
#2735
Khelben
nagyúr
Sk8erPeter
#2734
Khelben
nagyúr
válasz
Sk8erPeter
#2734
üzenetére
Kérdés, hogy a törölt kulcsot vissza lehet-e valahogy állítani
-
#2697
DNReNTi
őstag
Sk8erPeter
#2696
DNReNTi
őstag
válasz
Sk8erPeter
#2696
üzenetére
Igen az pont 1:n.
Kapkodtam.Lényeg a lényeg, így összesítve az információkat, nem lesz kevésbé hatékony, ha meg vannak osztva az adatok, így aki ezzel érvel, azt el tudom hajtani.
-
#2675
#68216320
törölt tag
Sk8erPeter
#2667
#68216320
törölt tag
válasz
Sk8erPeter
#2667
üzenetére
Nos, csináltam egy ilyesmit csak próbából az egyik már nem működő, régi weboldalam belépéséhez. Több lépésből csináltam végül, nem egy query lett. IP alapján blokkol x próba után és egy e-mail címre kiküldött linkben lehet feloldani a blokkolást és újra próbálkozni.
-
#2671
fordfairlane
veterán
Sk8erPeter
#2670
fordfairlane
veterán
válasz
Sk8erPeter
#2670
üzenetére
Az biztos, hogy belépési próbálkozásokat én nem user táblában tárolnám el, elvégre a user azonosítót is el lehet gépelni.
-
#2535
PumpkinSeed
addikt
Sk8erPeter
#2534
PumpkinSeed
addikt
válasz
Sk8erPeter
#2534
üzenetére
Kb 1 éve, de 2010-es kiadás.
-
#2533
DNReNTi
őstag
Sk8erPeter
#2531
DNReNTi
őstag
válasz
Sk8erPeter
#2531
üzenetére
Gondolom arra gondol, hogy akkor már nem a procedurális hanem az oop módon használná a prepared statements-t meg az egész adatbázis kezelést.
-
#2532
PumpkinSeed
addikt
Sk8erPeter
#2531
PumpkinSeed
addikt
válasz
Sk8erPeter
#2531
üzenetére
Az a baj, hogy amikor ezt a könyvet vettem ez volt a legfrissebb, ezenkívül még pár foglalkozott 5.x-el, de a többi 4 meg az alatt. De egy jó alapot adott, a többiről meg tájékozódom.
Az úgy jött ki, hogy nem tudom.
-
#2530
PumpkinSeed
addikt
Sk8erPeter
#2529
PumpkinSeed
addikt
válasz
Sk8erPeter
#2529
üzenetére
Nézegettem, de előbb az OOP-ra kellene erősebben ráfeküdjek, mert az az alapszint elég kevés hozzá, azután egyszerűbben fog menni. A PHP és MySQL webfejlesztőknek c. könyvvel most végeztem, csak az OOP-t hagytam ki, azt későbbre terveztem, de a könyv nem a legfrissebb PHP-t adja elő amúgy, ugyanis a prepared statementekről szó sincs bennük.
-
#2506
PumpkinSeed
addikt
Sk8erPeter
#2505
PumpkinSeed
addikt
válasz
Sk8erPeter
#2505
üzenetére
"Valahogy nehéz elhinni, hogy csak..."
Igen, mert kipróbáltam több ilyen formát is pl még a $result = $database_connect->query($second_query); megoldást is.
"Pont most írtam a másik topicban..."
A Sublime Text is IDE-nek számít? Mert azt úgy tudtam valami olyasmi mint a notepad++. Azt régen használtam, csak valamiért már notepad++-ra szoktam rá, és automatikusan azt nyitom meg.
"Ennek nem sok értelme van..."
Most működik 100 bevitt sorra, majd ha jelentkezik újra akkor részletesebben belenézek.
-
#2504
PumpkinSeed
addikt
Sk8erPeter
#2485
PumpkinSeed
addikt
válasz
Sk8erPeter
#2485
üzenetére
Tudom tudom, csak már nagyon el vagyok havazva, természetesen csak azért nézz ez így ki, mert már szét tákoltam minden kipróbáltam annak érdekében, hogy működjön. Amúgy ez nem a teljes kód, hanem csak az ahogyan megkapom az adatot és ahogy használni szeretném, kb 130. sor és 200. sor.
Igen notepad++-t használok, mert nekem ez a kézre eső megoldás, több képernyős módban egyszerre 4 felületet látok egyszerre, másra nincs szükségem.
(#2484) jocomen
bigint-ként van az adatbázisban, mivel 13 karakter hosszú.
(#2486) martonx
Az aposztrófok zavartak be, mert utána nem jelentkezett a jelenség.
-
#2502
fordfairlane
veterán
Sk8erPeter
#2499
fordfairlane
veterán
válasz
Sk8erPeter
#2499
üzenetére
Ismerni kéne a rendszert, hogy a vonalkód milyen értékeket vehet fel. Ha például betű csak valami hiba folytán kerülhet be, akkor decimal + validálás a megfelelő eljárás. Ha előfordulhatnak betűk és számok is, akkor a varcharral nincs semmi gond.
-
#2500
sztanozs
veterán
Sk8erPeter
#2499
sztanozs
veterán
válasz
Sk8erPeter
#2499
üzenetére
Pl, mert az olvasó beolvasott egy betűt (véletlenül vagy konfigurálási/olvasási hibából) a számsorba és a ezt 0-ra konvertálta az RDBMS.
-
#2498
fordfairlane
veterán
Sk8erPeter
#2496
fordfairlane
veterán
válasz
Sk8erPeter
#2496
üzenetére
Egyébként egyszerű a probléma: nem írta le, hogy a vonalkód milyen értékkészletű, és azt sem, hogy a DB séma milyen. Utólag megtudtuk, hogy double volt, de ezzel sem megyünk sokra, mert a varchar mindent elbír, tehát inkább csak elfedi a hibát, mint sem megoldja.
-
#2497
bambano
titán
Sk8erPeter
#2496
bambano
titán
válasz
Sk8erPeter
#2496
üzenetére
nem én hozakodtam elő. lásd: "Észre se vettem eddig de most, hogy átraktam double-ről varchar-ra nincsenek random kinullázások."
az iróniadetektorod elemcserére szorul.
-
#2495
bambano
titán
Sk8erPeter
#2493
bambano
titán
válasz
Sk8erPeter
#2493
üzenetére
hol is kértem tőled segítséget?
-
#2494
fordfairlane
veterán
Sk8erPeter
#2491
fordfairlane
veterán
válasz
Sk8erPeter
#2491
üzenetére
Ha biztosan csak számok vannak benne, akkor miért is ne, teljesítmény-szempontból még jobb is lehet.
Kivéve, ha nullával vagy nullákkal kezdődő számsorról van szó. Arra a decimal vagy numeric típus való, nem a különféle méretű integerek, és persze a lebegőpontos ábrázolásmódok sem.
-
#2492
bambano
titán
Sk8erPeter
#2489
bambano
titán
válasz
Sk8erPeter
#2489
üzenetére
vonalkódot lebegőpontos adattípusban tárolni?
-
#2490
jocomen
aktív tag
Sk8erPeter
#2489
jocomen
aktív tag
válasz
Sk8erPeter
#2489
üzenetére
Okozhat hibát, ha varchar-ként tárolja?
Nem tudom mi alapján számozzák, vagy h szoktak-e műveletet végezni vonalkódokkal, de pl számok összehasonlítása (gyártók, termék típusok keresése) okozhat-e hibát, vagy karakterként is ugyanaz lenne a sorrend <> összehasonlításnál, ... ?Mert ha később műveletet akar végeztetni vele (bár most eltűnt a hiba), okozhat még problémát az esetlegesen rosszul megválasztott adattípus, nem?
-
#2461
Joci93
senior tag
Sk8erPeter
#2456
Joci93
senior tag
válasz
Sk8erPeter
#2456
üzenetére
A * csak azért került bele, hogy az érintett oszlopokat ne lássátok
![;]](//cdn.rios.hu/dl/s/v1.gif)
PumpkinSeed: A 'key' az egy random számot tárolt volna el, ami a belépéshez szükséges. (Biztonsági kulcshoz hasonló)
-
#2459
PumpkinSeed
addikt
Sk8erPeter
#2458
PumpkinSeed
addikt
válasz
Sk8erPeter
#2458
üzenetére
Nálunk Oracle-n ujjlevágással járt key meg ilyen oszlopnevek megadása, meg a column oszlopnév. Valami tervezési hiba lehet belőle vagy mit magyaráztak, bár baromság is.
-
#2411
Agyasima
őstag
Sk8erPeter
#2410
Agyasima
őstag
válasz
Sk8erPeter
#2410
üzenetére
és persze martonx-nek is: Értem. Igyekszem holnapra összerakni egy adag kicsit pontosabb információt. És persze köszönöm az eddigi segítő szándékot.
-
#2360
jocomen
aktív tag
Sk8erPeter
#2359
jocomen
aktív tag
válasz
Sk8erPeter
#2359
üzenetére
Igen, ezt kerestem, köszi.
-
#2357
dellfanboy
őstag
Sk8erPeter
#2354
dellfanboy
őstag
válasz
Sk8erPeter
#2354
üzenetére
igen igazad van mostanság kicsit szétszórtvagoyk.... és ne haragudjatok, és köszi az infókat
-
#2355
FireFox1996
őstag
Sk8erPeter
#2353
FireFox1996
őstag
válasz
Sk8erPeter
#2353
üzenetére
Amikor írtam azt a példát, ott volt a példa elején, hogy "más példát mondok:" ami nekem annyit jelentett, hogy kicsit más témáról szól a példa...
"szerintem az felesleges... még 1 értékelést kell végezni az sql servernek...": valóban felesleges, és valóban még 1 értékelés kell neki, és valóban nem számít. De írjatok csak nyugodtan olyan kód sorokat, amiben felesleges sorok/részek vannak
Szerintem is zárjuk le a témát!
-
#2347
FireFox1996
őstag
Sk8erPeter
#2346
FireFox1996
őstag
válasz
Sk8erPeter
#2346
üzenetére
Abban az esetben hasznos, ha dinamikus where feltételekkel dolgozik a query.
Más esetben melőzni kell az ilyeneketmondok más példát: egy rekordban van egy blob típusú mező, de nem használják/nem töltik (ezt mondják neked a felhasználók)... És a kódod sem használja azt a mezőt, de még is lekéred a serverről a clientre (tipikus "select mezők1, mező2.. form" helyett "select * from" ...).
Téged nem zavar, mert azt mondták neked, hogy nem használják... Tehát bent hagyod a lekérdezésben...
Később egyszer vki kitöltötte a mezőt, és jó nagy lett a rekordod mérete, és ha a programod futásközben többször kéri le a rekordot, növeli az adatforgalmat, elfogy a serveren/clienten rendelkezésre álló memória... egyszer csak leáll az egész, mert nincs elég memória a gépen...Tehát ha vki tőlem kér tanácsot, akkor: ami felesleges kód, akkor ne írjuk oda!
-
#2345
FireFox1996
őstag
Sk8erPeter
#2344
FireFox1996
őstag
válasz
Sk8erPeter
#2344
üzenetére
sok kicsi sokra megy
Programozás szempontból a felesleges sort/értékelést ki kell hagyni... -
#2324
Jagerszki
csendes tag
Sk8erPeter
#2321
Jagerszki
csendes tag
válasz
Sk8erPeter
#2321
üzenetére
Üdv!
Oké, még csak most ismerkedek ezzel az egésszel.
( Én még dBase-t tanultam 25 éve )Szóval akkor az eredeti kérdés: te hogyan csinálnád?
( Nem kell gyorsnak lenni-e és nem kell ellenőrizni és csak egy alkalommal kell csinálni. ) -
#2298
Akcept
tag
Sk8erPeter
#2279
Akcept
tag
válasz
Sk8erPeter
#2279
üzenetére
Csak szép csendben kérdezem meg miért is nem lehet azt az aposztrófot másra cserélni, és akkor a kecske is jóllakik, meg a káposzta is megmarad. Azaz a cégnévben benne lesz az aposztróf, az adatbázisban meg nem:
$szoveg = str_replace("\'","'",$szoveg);
aztán jöhet egyéb védelem is. Persze lehet én értelek félre benneteket... -
#2278
bambano
titán
Sk8erPeter
#2276
bambano
titán
válasz
Sk8erPeter
#2276
üzenetére
"nem szükséges helyettem megfogalmazgatni bármit is": rendben, akkor maradjon a te megfogalmazásod, ami egyébként helytelen.
"miért merül fel egyáltalán a para, hogy ez SQL Injectiont okozhatna": nem értem. aposztróftól nem merül fel, hogy sql injection lehetne? de, felmerül. ettől egy teljesen független kérdés, hogy az adatbáziskapcsolatod kezelése védve van-e az sql injection ellen vagy sem. ha nem ellenőrzöd az inputot ilyen ellen, akkor lemondasz a védelem egy lehetséges szintjéről.
szerk: 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.
-
#2275
bambano
titán
Sk8erPeter
#2273
bambano
titán
válasz
Sk8erPeter
#2273
üzenetére
no, akkor megfogalmazom helyetted: azt gondolod, hogy azért félek az sql injectionra alkalmas karakterektől, mert a program többi része nincs ellene felkészítve.
"AZÉRT tiltod az aposztróf bevitelét, mert alkalmas lehetne SQL Injectionre...": igen, azért tiltom, de ez, szerintem, természetes.
-
#2274
bambano
titán
Sk8erPeter
#2273
bambano
titán
válasz
Sk8erPeter
#2273
üzenetére
attól, hogy a zseton páncélban van, még bezárom az ajtót
mondjuk az is igaz, hogy a program, amit írtam, nem széles körnek szól, de legalább kényes adatok vannak benne...
-
#2272
bambano
titán
Sk8erPeter
#2271
bambano
titán
válasz
Sk8erPeter
#2271
üzenetére
ezt a mondatodat nem teljesen értem. nem parázok az sql injectiontól, egyszerűen kitiltottam a lehetőségét is.
-
#2270
bambano
titán
Sk8erPeter
#2269
bambano
titán
válasz
Sk8erPeter
#2269
üzenetére
puhány vagy
-
#2093
martonx
veterán
Sk8erPeter
#2090
martonx
veterán
válasz
Sk8erPeter
#2090
üzenetére
Az, hogy a táblák lényegében mekkorák, soha nem indok arra, hogy csak azért is szopassuk már meg jól az SQL szervert
Azért mondtam akkora méreteket, mert ha azt mondom, hogy nem 10 ms lesz a query ideje, hanem 500 ms, az nem fog elég elrettentőnek hatni.
Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is? Különben is sokkal kényelmesebb visszanézni szemre az adatokat, meg a PHP-ban is egy select * from tabla, és mindenki happy.Nehogy már elkezdjünk erre bólogatni, hogy tényleg milyen igaz.
-
#2091
Ispy
nagyúr
Sk8erPeter
#2090
Ispy
nagyúr
válasz
Sk8erPeter
#2090
üzenetére
Az, hogy a táblák kicsik még nem indok arra, hogy ne a tankönyv szerint csináld. Ha csak 1 rekord lesz benne, akkor is jól kell megcsinálni. Attól lesz valaki szakember, nem pedig vérpistike.
-
#1669
pittbaba
aktív tag
Sk8erPeter
#1664
pittbaba
aktív tag
válasz
Sk8erPeter
#1664
üzenetére
Elég sokszor megtörténik
-
#1665
martonx
veterán
Sk8erPeter
#1664
martonx
veterán
válasz
Sk8erPeter
#1664
üzenetére
LOL
-
#1663
pittbaba
aktív tag
Sk8erPeter
#1662
pittbaba
aktív tag
válasz
Sk8erPeter
#1662
üzenetére
Sorry, úgy gondoltam, alapból feltételezitek, hogy nem kérdezek olyankor, ha legalább minimálisan nem néztem utána, de legközelebb jelzem ezt.
-
#1661
pittbaba
aktív tag
Sk8erPeter
#1660
pittbaba
aktív tag
válasz
Sk8erPeter
#1660
üzenetére
Lesz?
tizenx éve ezzel foglalkozok, és ebből élek, több szálon az rendben, nem egy valamihez értek nagyon, hanem a legtöbb igényelt munkát el tudom látni, és ennyi. Az hogy a msql legbelsőbb bugyraiban nem tudom, hogy a key, és a create index között van e időben vagy eljárásban különbség, nem okozott gondot még A legtöbb programozási nyelvet angolul tanultam én, az megvan, hogy mit kell nézni, meg bambulom a példákat, és ha átírok valamit mi változik szenvedések, viszont egy-egy komolyabban megfogalmazott mondat fölött átsiklik a tekintetem, ezért jobb, ha megkérdezem, de már kezdem megbánni -
#1659
pittbaba
aktív tag
Sk8erPeter
#1657
pittbaba
aktív tag
válasz
Sk8erPeter
#1657
üzenetére
Köszi! Az angolom még mindig nem perfect, ezért bizonytalan vagyok, hiába találom meg én is ezeket, de okay.
-
#1643
pittbaba
aktív tag
Sk8erPeter
#1642
pittbaba
aktív tag
válasz
Sk8erPeter
#1642
üzenetére
Hallgattam a tanácsokra, de szerintem az indexelés dolgot rosszul csinálom, kezd gyanús lenni.
Egyébként már felpakoltam idegnagy szerverre, szóval a vas része megoldódott, nem bosszantom tovább magam az arm procival,csak ha lesz egy céljaimnak megfelelő adatbázis. ( Bár android okosításba kezdtem, SQL feladat lett belőle ).Az indexeléssel kérdés:
Sajnos az id-k néhol betűt is tartalmaznak, így csak fulltext indexet enged a mysql. Fulltext indexet ráteszem a kellő mezőkre, ez is megvolt, de nem gyorsult érezhetően.
Újra kell indexeltetni valamilyen paranccsal a táblát? Vagy az adatokat is teljesen újra kellene tölteni a táblába?
Fórumon írnak sok mindent itt-ott, azt találtam REPAIR-el valahogy megoldható hogy a már táblában lévő tartalmat újraindexelje a mySQL.Indexelt táblákat dumpoltam ki a saját szerveremről a távoliba, de most ahogy nézem az export file-t nincs benne indexelés, nem hozta az export, így újra kell az egészet.
Végre Mysql-en tudok explain kimenetet adni:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE routes ALL NULL NULL NULL NULL 313
1 SIMPLE trips ALL NULL NULL NULL NULL 134307 Using where; Using join buffer
1 SIMPLE stop_times ALL NULL NULL NULL NULL 2555175 Using where; Using join buffer -
#1641
martonx
veterán
Sk8erPeter
#1640
martonx
veterán
válasz
Sk8erPeter
#1640
üzenetére
hú bocs, igaziból kicsit elveszítettem a fonalat. Annyi volt a mellékes információ, hogy bevallom nyugodt szívvel kihagytam a kérdezőtől pár feleslegesnek vélt túl hosszú hszt.
Ez esetben teljesen jogos a felvetés, hogy pillanatok alatt mennie kellene a lekérdezésnek, ahogy ez másnál működik is. Valószínűleg már csak rendesen indexelni kell a db-t, és hasítani fog. -
#1635
pittbaba
aktív tag
Sk8erPeter
#1633
pittbaba
aktív tag
válasz
Sk8erPeter
#1633
üzenetére
A "hatalmas SQL adatbázis importálása sql fájlból probléma" megoldódott teljesen! Köszönöm, ez volt a leghelyesebb megoldás!
-
#1630
pittbaba
aktív tag
Sk8erPeter
#1625
pittbaba
aktív tag
válasz
Sk8erPeter
#1625
üzenetére
Köszönöm, hogy rám szóltál, a link alatti kis php script nagyon szépen működik. Gyors, szép kód, jó megoldás!
-
#1627
pittbaba
aktív tag
Sk8erPeter
#1625
pittbaba
aktív tag
válasz
Sk8erPeter
#1625
üzenetére
Megnézem, remélem működni fog, köszönöm. Kerülni szerettem volna a plusz patkolásokat, azért írtam, hogy így is olyan messze vagyok az igazságtól, hogy nem szívesen veszek bele még még még plusz lépéseket, eszközöket, de remélem ez működni fog, majd reportolom
A megoldást ahogy írtam is, abban reméltem, hogy ha táblákra szétszedem a fájlokat, akkor már menni fog, mert kevesebb műveletet kell futtatnia egy kérés alatt. Egyel jobb is lett, viszont lett helyette másik korlát:
Got a packet bigger than 'max_allowed_packet' bytesEzért most jön a tipped kipróbálása.
-
#1622
pittbaba
aktív tag
Sk8erPeter
#1621
pittbaba
aktív tag
válasz
Sk8erPeter
#1621
üzenetére
Jah csak az a bajom h az eredeti feladattól már annyira eltértem, hogy ilyen még az életben nem volt, most már ott tartok h a 100. szálon most adatbázis darabolós fájlonként egyesével importálgatósat kell játszani, ez botrány, hogy nem tud az ember egy 150 megás adatbázist átmozgatni szerverről szerverre. Megérteném 100 gigánál, de így...
Épp keresem, de hátha gyorsabban érkezik a válasz: mysqldump-nál van olyan, hogy táblánként dumpolja fájlba, mert találtam egy megoldást, de a maximum memóriaméretet 3 megával túl lépem, úgyhogy elég az egyik táblát külön venni, és elvileg megoldható lesz ( aztán lehet hogy tévedek ).
-
#1603
pittbaba
aktív tag
Sk8erPeter
#1599
pittbaba
aktív tag
válasz
Sk8erPeter
#1599
üzenetére
Az explain kimenetéből mire vagy kíváncsi? Nem tudom copyzni a kezelőprogrammal sajnos, de ami fontos azt bepötyögöm.
-
#1602
pittbaba
aktív tag
Sk8erPeter
#1601
pittbaba
aktív tag
válasz
Sk8erPeter
#1601
üzenetére
Rendben
az Explain kimenetét majd mutatom, ha egyszer kikergeti. -
#1600
pittbaba
aktív tag
Sk8erPeter
#1599
pittbaba
aktív tag
válasz
Sk8erPeter
#1599
üzenetére
Látatlanban? Ott van minden már, épphogy az adatbázist nem csatoltam
Indexelni melyik táblákat érdemes? Egyelőre csak a stop_times.stop_id-t, és a stops.stop_name -t indexeltem. Explain-t nem vágom, guglizom, nézem, de jöhet tipp! -
#1559
Sk8erPeter
nagyúr
Sk8erPeter
#1556
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#1556
üzenetére
Hát ez is igaz, hogy ott nagyon OFF lenne.
Rájöttem, hogy a legtisztább az lenne, ha az illető jönne inkább ide témázni a dologról, talán végre konstruktív vita is kialakulhatna, "nem arról szólna végre a topic, hogy nááám múúúkodik az, hogy lekérjem a termékek táblából a 123-as id-jú termék nevét, mééé' neeem?" -
#1558
lakisoft
veterán
Sk8erPeter
#1556
lakisoft
veterán
válasz
Sk8erPeter
#1556
üzenetére
Ez nem kibeszélés, csak megvitatás. Egy rossz szót nem szóltam.
. -
#1557
martonx
veterán
Sk8erPeter
#1556
martonx
veterán
válasz
Sk8erPeter
#1556
üzenetére
mert az egy php-s topik, minek offolni benne SQL fejlesztő eszközökről. Annak meg nem látom értelmét, hogy egy szemmel láthatóan nem képben lévő, ám annál arrogánsabb embert, megpróbáljunk picit is képbe hozni.
-
#1518
lakisoft
veterán
Sk8erPeter
#1517
lakisoft
veterán
válasz
Sk8erPeter
#1517
üzenetére
Ez így van
. -
#1508
Inv1sus
addikt
Sk8erPeter
#1505
Inv1sus
addikt
válasz
Sk8erPeter
#1505
üzenetére
Sikerült, köszi. Tényleg sokkal egyszerűbb így.
-
#1471
Lacces
őstag
Sk8erPeter
#1470
Lacces
őstag
válasz
Sk8erPeter
#1470
üzenetére
Az sulitiltás.
Jó, akkor majd ha olyan hobbi projektnél tartok, akkor majd jövők kérdezek a tárolt eljárásokról, ha úgy érzem. Igen, igen, már el is felejtettem, hogy saját nevet adhatok neki, nem rondítom el stb.
A programozás "művészete" - már el is felejtettem.Köszönöm a választ mindenkinek!
-
#1457
martonx
veterán
Sk8erPeter
#1456
martonx
veterán
válasz
Sk8erPeter
#1456
üzenetére
Mert a motorháztető alatt, illetve skálázhatóság (gondolok itt elsősorban a fürtőzésekre, azaz horizontális skálázhatóságra) szempontjából a PostgreSQL sokkal többet tud, sokkal finomabbra hangolható.
És ahogy mondtam, az már más kérdés, hogy a userek 99%-a ezeket a MySQL-hez képest extrának számító feature-öket az életben soha nem is fogja kihasználni.
Ellenpéldának meg ott van a Facebook, de ők már rég agyonhack-elték mind a PHP-t, mind a MySQL-t, és jó példák arra, hogy szarból is lehet várat építeni, ha erre több milliárd dollárod van.Másrészt bevallom nem vagyok 100%-osan naprakész ez ügyben. Postgre-nal lemaradtam a 9-es főverziónál, MySQL-t érdemben utoljára 5.4-eset használtam. Szóval lehet, hogy közben MySQL lépett előre, bár magának az Oracle-nek sem érdeke, hogy igazi konkurenciát támasszon házon belül az Oracle DB-nek.
-
#1453
Lacces
őstag
Sk8erPeter
#1452
Lacces
őstag
válasz
Sk8erPeter
#1452
üzenetére
Óóóóó
kapcsoló tábla... hogy ez nem jutott eszembe itt... pedig még le is írtam, hogy 1...n kapcsolat... -
#1437
klambi
addikt
Sk8erPeter
#1435
klambi
addikt
válasz
Sk8erPeter
#1435
üzenetére
semmi, csak kérdeztem van-e valami más lehetőség...
-
#1425
Geryson
addikt
Sk8erPeter
#1424
Geryson
addikt
válasz
Sk8erPeter
#1424
üzenetére
Szia Brian!
Majdnem egy sorozatban játszunk... Akkor jól sejtettem, hogy Order by cikkszam, de valami miatt ezt nem hajtja végre...
Szerk.: Megvaaan! Bent maradt a pontosvessző a select * sor végén. Köszönöm!
-
#1374
martonx
veterán
Sk8erPeter
#1373
martonx
veterán
válasz
Sk8erPeter
#1373
üzenetére
Én 3 cégre látok rá, ezekből kettő az igazán nagyok között játszik (vagy legnagyobb? hm...) A harmadik is komoly tényező. Őszintén meglepődnék ha a többiek nagy részénél nem fordulna elő MS Access.
-
#1372
sztanozs
veterán
Sk8erPeter
#1371
sztanozs
veterán
válasz
Sk8erPeter
#1371
üzenetére
Én kettőről is (biztosan) tudok - mind a kettő benne van az első ötben a saját kategóriájában...
-
#1369
Dave-11
tag
Sk8erPeter
#1362
Dave-11
tag
válasz
Sk8erPeter
#1362
üzenetére
"Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják."
Ezt meg tudom érteni, de érettséginél Accest kellesz használni.
Igazából csak ezért kérdeztem rá, meg hogy ez mennyire elterjedt, mert korábban én még nem is hallottam róla. -
#1364
martonx
veterán
Sk8erPeter
#1362
martonx
veterán
válasz
Sk8erPeter
#1362
üzenetére
Tudok több olyan nagy pénzintézetet mondani Magyarországon, ahol jelentős programok MS Access-ben vannak megvalósítva.
-
#1363
modder
aktív tag
Sk8erPeter
#1362
modder
aktív tag
válasz
Sk8erPeter
#1362
üzenetére
Ehhez pedig én is még annyit hozzátennék, hogy az access-t, mint platformot vagy toolt amire alkalmazást lehet írni, tényleg felejtsd el. arra viszont jó, hogy gyakorold vele az SQL-t. Ha pedig az SQL-t már nagyjából ismered, a szemlélet és a szintaxis már nem annyira különbözik az egyes relációs adatbázisoknál. persze mindig vannak bonyolultabb esetek, amikor mélyebbre kell ásnia magát az embernek egyes adatbázis gyártók megoldásaiba.
Ha pedig azt mondod, hogy gyakorolni szeretnél, arra én is inkább a MySQL-t vagy az MS SQL express-t ajánlom, mert azok legalább rendes, "production" környezetben használt adatbázisok, és ingyenesek. -
#1356
Lacces
őstag
Sk8erPeter
#1354
Lacces
őstag
válasz
Sk8erPeter
#1354
üzenetére
jó, rosszul fogalmaztam
. Építő jellegű kritika... nem pedig, hogy ez, milyen sz***, inkább menj el vasútasnak stb... Na, halljam te hogy csinálnád -
#1331
lakisoft
veterán
Sk8erPeter
#1330
lakisoft
veterán
válasz
Sk8erPeter
#1330
üzenetére
Morcos voltam
-
#1322
sanzi89
addikt
Sk8erPeter
#1321
sanzi89
addikt
válasz
Sk8erPeter
#1321
üzenetére
Rendben, legközelebb igyekszem pontosabbnak lenni.
-
#1315
sanzi89
addikt
Sk8erPeter
#1307
sanzi89
addikt
válasz
Sk8erPeter
#1307
üzenetére
Ezek szerint mégse annyira egyértelműen könnyű a dolog...
@Goose-T
Köszi, szerintem valami ilyesmi lesz. Kitöröm őket, aztán beszúrok egy sort. Nem elegáns, de működik legalább. -
#1311
sanzi89
addikt
Sk8erPeter
#1309
sanzi89
addikt
válasz
Sk8erPeter
#1309
üzenetére
Egy Delphiben írt program egyik modulja lenne az, hogy bizonyos hiba miatt néha rekordok duplázódnak. Ezekből nem tudjuk mennyi van, vagy hogy hol vannak az adatbázisban. Eljutottam oda, hogy ezek a hibás adatok ki vannak listázva egy DBGrid-be. Itt a user kiválasztja, hogy melyiket hagyjuk meg - sajna így kell csinálni, mivel lehet más hiba is, és oda kell az, hogy el lehessen dönteni melyik maradjon - és a kiválasztottat törölni. Rengeteg sor van, több százezer, és lehet csak egy duplázott sor van benne.
Szóval külön adatbázis böngészőt nem használhatok, nem tudok simán rámenni és törölni. Plusz nincs ilyen, hogy id, nincs semmi. Ilyesmi sorokat képzelj el:
Név | Kártyaszám | Születési hely
Kis Pista | 1 | Budapest
Kis Pista | 1 | Budapest
Nagy Béla | 2 | DebrecenEbből kellene az egyik Kis Pistát törölni.
-
#1308
sanzi89
addikt
Sk8erPeter
#1307
sanzi89
addikt
válasz
Sk8erPeter
#1307
üzenetére
Hát, az a nehéz benne, hogy nem tudom hogyan kell.
Van egy adatbázis - Access - amiben van rengeteg adat, ebből kikeresem a szar sorokat, és ezekből kellene törölni úgy, hogy csak egy maradjon. ODBC-n fut, és Delphiben kellene rá egy Query-t csinálni, amihez ugye kellene egy SQL parancs. Ez hibádzik.
De örülök, hogy ilyen egyszerű probléma, mert akkor várom a megoldást.
-
#1304
rum-cajsz
őstag
Sk8erPeter
#1303
rum-cajsz
őstag
válasz
Sk8erPeter
#1303
üzenetére
Az a programozó, aki megengedi, hogy bármit beírhassanak a dátum típusú mezőbe, az megérdemli, hogy a tökén végigrobogjon egy GNU csorda. (de látom Te is pont ezt írod alant)
Azt pedig már tényleg csak nagyon zárójelben jegyzem meg, hogy ha a dátum adatok vegyes szerkezetűek, akkor elég nagy felelőtlenség/hanyagság előfeldolgozás nélkül belehányni őket egy dátum típusú mezőbe.
De az eredeti kérdés egyébként így nézett ki:
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)Szerintem nincs olyan valós indok, ami felhozható a prepare statment ellen. (de szerintem ebben is egyetértünk)
-
#1301
sztanozs
veterán
Sk8erPeter
#1300
sztanozs
veterán
válasz
Sk8erPeter
#1300
üzenetére
Paraméterezett esetben a fejlesztői nyelv általában segítséget nyújt abban, hogy az értéket ne string formában, hanem a nyelv natív adatformátumában (pl. java, .net) adja át, amit az adatbáziskezelő csomag képes olyan formában átadni a db szerver számára, hogy az ne okozzon értelmezési/konverziós problémát.
Persze olyan környezetben, ahol nincs natív datetime formátum, ott ez nem segít... -
#1299
sztanozs
veterán
Sk8erPeter
#1297
sztanozs
veterán
válasz
Sk8erPeter
#1297
üzenetére
Rosszul állt az elnevezés a fejemben - sorry
Szóval paraméterezett SQL utasítást kell használni -
#1298
martonx
veterán
Sk8erPeter
#1297
martonx
veterán
válasz
Sk8erPeter
#1297
üzenetére
és ez még csak a PHP. Van még néhány nyelv, ahol nem is prepared statement-nek hívják
A lényeg azonban ugyanaz, kerülendő a konkatenálás. -
#1296
sztanozs
veterán
Sk8erPeter
#1295
sztanozs
veterán
válasz
Sk8erPeter
#1295
üzenetére
Ahol paraméterként adod át a command változóit.
-
#1294
rum-cajsz
őstag
Sk8erPeter
#1292
rum-cajsz
őstag
válasz
Sk8erPeter
#1292
üzenetére
"Gondolom erre a képre gondoltál: [link]. "
Haha, ez király!
-
#1293
sztanozs
veterán
Sk8erPeter
#1292
sztanozs
veterán
válasz
Sk8erPeter
#1292
üzenetére
Prepared Statementnél a programnyelv natív formájában tudod átadni a változót, nem kell előtte stringgé alakítani. Ezt konkatenált utasítás esetén nem tudod megtenni.
Igen ezt volt
-
#1291
sztanozs
veterán
Sk8erPeter
#1290
sztanozs
veterán
válasz
Sk8erPeter
#1290
üzenetére
Ha sql parancsot konkatenálsz - amit ugye nem illendő - akkor ahány adatbáziskezelő annyi féle datetime megvalósítás, sőt a datetime string formátum még kultúra érzékeny is.
egy 10/11/12-ről megmondani, hogy mi volt az eredeti dátum 33%-os eséllyel lehet - és az adatbáziskezelő is ilyen eséllyel vesz fel jó értéket.Persze, ha prepared statement-et használ az ember, akkor rögtön nincs ilyen gond... (láttam is róla egy jó képet itt valahol
) De ugye a fenti esetben sem erre láttunk példát. -
#1282
sanzi89
addikt
Sk8erPeter
#1281
sanzi89
addikt
válasz
Sk8erPeter
#1281
üzenetére
Én meg nem mondom, hogy a log foglalt-e, de másik ezer SELECT meg DELETE megy így is, hogy log.
Egyébként kipróbáltam, de ugyanaz, szintaktikai hiba az insert into utasításban.
u.i.: Remélem nem ilyen gondom van...
-
wolandino
tag
válasz
Sk8erPeter
#1266
üzenetére
abszolút
Nagyjából igaz amit feltételeztél, a különbség, hogy nincs kényszer, egy helyzet van, hogy van két nem túl kompatibilis eszköz és felmerült az egyik integrálása a másikba.
De úgy néz ki, hogy le lehet cserélni és zöld utat kapok a mysql-es megvalósításra, a dolog amúgy is csak ideiglenes lett volna, amíg el nem készül a php mysql verzió. -
#1267
PazsitZ
addikt
Sk8erPeter
#1266
PazsitZ
addikt
válasz
Sk8erPeter
#1266
üzenetére
Partvonalról könnyebb bekiabálni, hogy én bezzeg...
-
wolandino
tag
válasz
Sk8erPeter
#1256
üzenetére
az a baj, hogy jelenleg van egy windows-os gépen egy office alkalmazás, amit fene tudja miben programoztak, ott lehet elérni ezt az access adatbázist, és párhuzamosan kellene futnia az én alkalmazásomnak, majd utána lehetne a jelenlegit lekapcvsolni, de én is hajlok abba az irányba, hogy ne átállás legyen, hanem csere.
-
#1243
SektorFlop
aktív tag
Sk8erPeter
#1239
SektorFlop
aktív tag
válasz
Sk8erPeter
#1239
üzenetére
tényleg célszerűbb lenne, meg se fordul a fejemben ez a megoldás.
-
#1240
Fecogame
veterán
Sk8erPeter
#1239
válasz
Sk8erPeter
#1239
üzenetére
Adott két fórum egy tárhelyen, és ezekhez 2 külön adatbázis tartozik ( jelenleg ).
Ezt a kettő adatbázist kell egybe összeraknom, mert az új tárhelyen csak egy használatára van lehetőség.
-
#1215
bpx
őstag
Sk8erPeter
#1213
bpx
őstag
válasz
Sk8erPeter
#1213
üzenetére
mint azt tegnap is írtam az ábrázolás és a tárolás formátuma teljesen független, te csak az megjelenítés formátumát tudod manipulálni, a dátum típusnak megvan a saját belső struktúrája
simán lehet csak bizonyos részeket megjeleníteni, vagy akár tök hülyeséget is (ami persze még érelmezhető) beállítani format stringnek (és ugye most Oracle-ről beszélünk)
SQL> select sysdate from dual;
SYSDATE
---------
28-JUN-12
SQL> alter session set nls_date_format='_#!+YYYYMMDDHH24MISS';
Session altered.
SQL> select sysdate from dual;
SYSDATE
------------------
_#!+20120628130131
SQL> alter session set nls_date_format='SS...:_"/=%!"YYYY!"%/%"HH24"%!"MI_DD_:MM';
Session altered.
SQL> select sysdate from dual;
SYSDATE
--------------------------------
07...:_/=%!2012!%/%13%!02_28_:06
SQL> alter session set nls_date_format='YYYY.MM.DD. HH24:MI:SS';
Session altered.
SQL> select sysdate from dual;
SYSDATE
--------------------
2012.06.28. 13:02:59 -
#1214
rum-cajsz
őstag
Sk8erPeter
#1213
rum-cajsz
őstag
válasz
Sk8erPeter
#1213
üzenetére
A dátumformátumot beállíthatod a kliens paraméterei között (mármint az oprendszerben), nem kell állandóan kiadni a lenti parancsot.
-
#1211
bpx
őstag
Sk8erPeter
#1210
bpx
őstag
válasz
Sk8erPeter
#1210
üzenetére
ez hogy ott pont van, semmit nem jelent
SQL> alter session set nls_date_format='YYYY.MM.DD. HH24:MI:SS';
Session altered.
SQL> select sysdate from dual;
SYSDATE
--------------------
2012.06.28. 12:03:06 -
#1188
Sk8erPeter
nagyúr
Sk8erPeter
#1187
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#1187
üzenetére
Pontos egyezés vizsgálatához át lehet alakítani így is:
SELECT * FROM `test_names`
WHERE
BINARY(stuff_name) LIKE "%lajos%"Így csak azt találja meg, ahol "lajos" vagy "lajoska" van, a "Lajos" vagy "LaJos", stb. neveket már nem.
-
#1183
martonx
veterán
Sk8erPeter
#1182
martonx
veterán
válasz
Sk8erPeter
#1182
üzenetére
Nincs itt nagyon mit megbeszélni. Az 5.1-es MySQL verzióban volt a legtöbb innováció. Ez pedig 2008 November 27-én jelent meg. Ez lassan 4 év távlatot jelent. lakisoft által jelzett újdonságok is ekkor kerültek bele. Azóta csak csiszolgatják.
Az Oracle pedig 2010 január 27-én vette meg a Sun-t, ami birtokolta a MySQL-t.
De ez részemről nagyon off topik, és nem vagyok egy nagy MySQL szakértő. -
#1181
lakisoft
veterán
Sk8erPeter
#1179
lakisoft
veterán
válasz
Sk8erPeter
#1179
üzenetére
Itt nem ezekre gondoltam. A tárolt eljárásokra pl. vagy MySQL Partitioning vagy Storage Engine: NDB kibővítették az elérhető adattipusokat.
-
#1180
martonx
veterán
Sk8erPeter
#1179
martonx
veterán
válasz
Sk8erPeter
#1179
üzenetére
Én inkább úgy mondanám, hogy mióta az Oracle kezében van, nem olyan a fejlődési üteme, mint régen. Az Oracle bolond lenne saját magának konkurenciát állítani.
-
#1171
lakisoft
veterán
Sk8erPeter
#1168
lakisoft
veterán
válasz
Sk8erPeter
#1168
üzenetére
Persze hogy el lehet rondítani, de próbálok áttekinthető kódot kiadni a kezemből.
-
kisbandima
tag
válasz
Sk8erPeter
#1165
üzenetére
Favágó módszer 2 paraméterre:
if ((a != 0) && (b == 0))
{
return ... Where Osszeg >= a;
}
if ((a == 0) && (b != 0))
{
return ... Where Osszeg <= b;
}
return ... Where Osszeg >= a & Osszeg <= b;Remélem így már érthető. A probléma, hogy nekem 4 paraméterem van és ezzel a módszerrel elég amatőr megoldásnak látszik. Igaz legalább működik.
-
#1169
Speeedfire
félisten
Sk8erPeter
#1168
Speeedfire
félisten
válasz
Sk8erPeter
#1168
üzenetére
Azért akarom (illetve akarja a fene, de nem látom rá mást...), hogy utána ki tudjam törölni a régi bejegyzéseket.
tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Így van, y mennyiség bejegyzés megmaradni minden usernek.
Nem tudom mit értetlenkedsz ha tudod mire gondolok.
Adott pl 1m rekord és 1k felhasználó és pl 500 bejegyzésnek kellene lennie csak felhasználónként maximum. Ergo akinek több mint 500 ilyen bejegyzése van, azoknak a legrégebbieket törölni kellene.
-
#1166
lakisoft
veterán
Sk8erPeter
#1165
lakisoft
veterán
válasz
Sk8erPeter
#1165
üzenetére
Hááát figy. Valóban csúnya de az agyam ráállt teljesen. Így jól és gyorsan tudom használni. A teljesítménybeli vonatkozásait nem ismerem de igazából jelenleg nincs is rá szükségem.
Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya
. -
#1161
SektorFlop
aktív tag
Sk8erPeter
#1160
SektorFlop
aktív tag
válasz
Sk8erPeter
#1160
üzenetére
nem feltétlenül kell view... sima select is elég kell hogy legyen igaz?
-
#1138
WolfLenny
senior tag
Sk8erPeter
#1136
WolfLenny
senior tag
válasz
Sk8erPeter
#1136
üzenetére
Havi lekérdezés extrém ritka. Inkább teljes év vagy up2date lekérdezések vannak. Viszont az input adatok havi szinten jönnek. Ha view-sal nézzük, akkor könnyebb kezelni, mert nem kell havin szinten nyitogatni. Akkor lehet érdemes egy táblába tenni egy teljes évet, ha view-sal lassabb....
-
#1123
Speeedfire
félisten
Sk8erPeter
#1121
Speeedfire
félisten
válasz
Sk8erPeter
#1121
üzenetére
Igen van. A többi sornál működik is a módosítás.
PazsitZ: Na, ezt megnézem majd.
Kapkodtam.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
.
Új hozzászólás Aktív témák
Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Hobby rádiós topik
- Autós topik
- Építő/felújító topik
- Beszántaná a marketingért felelős részlegét az Intel
- Hegesztés topic
- Samsung Galaxy S23 Ultra - non plus ultra
- Milyen videókártyát?
- Google Pixel topik
- Sokat fejlődött a Tecno belépő ajánlata
- További aktív témák...
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
- Microsoft Windows, Office & Vírusirtók: Akciók, Azonnali Szállítás, Garantált Minőség, Garancia!
- ÁRGARANCIA! Épített KomPhone i5 14600KF 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- AKCIÓ! ASUS TUF GAMING X670E-PLUS WiFi alaplap garanciával hibátlan működéssel
- AKCIÓ! Dell Optiplex 5060 TWR számítógép - i5 8500 16GB DDR4 256GB SSD 500GB HDD UHD630 WIN10
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest