Új hozzászólás Aktív témák

• #2753 Sk8erPeter nagyúr rum-cajsz #2752

  Új Válasz 2015-01-17 22:48:21 #2753

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz rum-cajsz #2752 üzenetére

  Azt írta, hogy "van szám, szám per betű, számtólszámig és több más forma is." Szóval nem túl szabályos. A regexp, amit előbb írtam, a legegyszerűbb megközelítés, ha lenne több példaadat is, akkor persze könnyebb lenne több esetet is lefedő regexpet írni, de a megadott példaadatokkal ez is működik (ld. SQL Fiddle-példát).

• #2751 Sk8erPeter nagyúr bambano #2750

  Új Válasz 2015-01-17 22:32:56 #2751

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #2750 üzenetére

  Esetleg ez:
  SELECT * FROM mytable ORDER BY substring(number, '^[0-9]+')::int ASC, number ASC;

  http://sqlfiddle.com/#!15/01174/3

• #2749 Sk8erPeter nagyúr bambano #2748

  Új Válasz 2015-01-17 21:08:11 #2749

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #2748 üzenetére

  Biztos sok hibalehetőséget rejt magában, amit most nem volt alkalmam normálisan tesztelni, és most gyorsan csak MySQL-lel teszteltem, de ilyen castolás nem jó?

  tesztként query (itt implicit castolással):

  mysql> SELECT * FROM `mytable` ORDER BY (`number` * 1) ASC, `number` ASC;
  +----+-----------+--------+
  | id | street_id | number |
  +----+-----------+--------+
  | 1 | 23 | 4/a |
  | 2 | 23 | 5/a |
  | 26 | 42 | 11 |
  | 5 | 23 | 11 |
  | 6 | 23 | 11/a |
  | 8 | 23 | 13 |
  | 9 | 23 | 13/b |
  | 3 | 23 | 14 |
  | 4 | 23 | 16 |
  | 24 | 46 | 16 |
  | 25 | 23 | 18 |
  | 7 | 23 | 20 |
  | 10 | 23 | 20/a |
  | 19 | 23 | 21 |
  | 18 | 23 | 38 |
  | 23 | 36 | 115 |
  | 22 | 36 | 117/a |
  | 21 | 36 | 117/b |
  | 20 | 36 | 119 |
  +----+-----------+--------+
  19 rows in set (0.00 sec)

• #2734 Sk8erPeter nagyúr Khelben #2733

  Új Válasz 2014-12-30 10:23:07 #2734

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Khelben #2733 üzenetére

  "Második megoldás egy titkosítás, amikor a törölt rekordokat tartalmazó táblát letitkosítom egy új kulccsal és a régi kulcsot eldobom. Ekkor a törölt rekordokat még vissza lehet állítani, de a tartalmuk nem látható a régi kulcs nélkül."
  Számomra még ez tűnik a legésszerűbbnek a felsorolt lehetőségek közül, tehát hogy hiába tudja valaki visszaállítani extrém esetben a rekordot, a tartalmával nem igazán tud mit kezdeni. A többi megközelítés túl macerás vagy túl kockázatos.

• #2696 Sk8erPeter nagyúr DNReNTi #2690

  Új Válasz 2014-12-04 15:16:09 #2696

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz DNReNTi #2690 üzenetére

  Erre a kérdésre a tárolandó adatok ismeretének hiányában tényleg nem nagyon lehet pontosan válaszolni, DE esetedben már kapásból látszik egy ilyen, hogy pl. user_log, ez már eleve feltételezi, hogy itt több bejegyzés is fog szerepelni, mert elég érdekes napló az, amiben minden korábbi értéket folyton felülírsz. (Az időnkénti tisztítás más tészta, mert az is kell, de nem így. ) Ergo ez már kapásból különválasztást, normalizálást igényel.
  Ha a user_settings sok mezőt feltételez, és akár már nem is 1-1 kapcsolat van köztük, akkor megint csak kötelező normalizálni (egyrészt ronda a teleokádott tábla, másrészt kerülni kell a szokásos anomáliákat).
  A többi adat széjjelbontása is csomó mindentől függ, de tényleg tervezési kérdés, ha szebb különválasztva, akkor tedd azt, ha nem, akkor ne. Nem kell erőltetni, de a jointól sem kell félni, sőt.

• #2670 Sk8erPeter nagyúr fordfairlane #2669

  Új Válasz 2014-11-14 12:46:58 #2670

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz fordfairlane #2669 üzenetére

  Mondjuk az nem túl jó, mivel akkor könnyű "segíteni" a dolgon egy sima session cookie-törléssel, és máris olyan, mintha egyszer se próbálkozott volna.

• #2667 Sk8erPeter nagyúr #68216320 #2665

  Új Válasz 2014-11-14 12:15:18 #2667

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz #68216320 #2665 üzenetére

  Nem biztos, hogy ezt egyetlen query-vel kell elintézned, lehetne ilyenekre tárolt eljárást is írni. Persze tervezési kérdés, hogy ezt biztos az adatbázisszervernek kell-e intéznie, vagy az alkalmazás(szerver) intézze.

  Viszont ez a jelszóbeírásnál legfeljebb 3 próbálkozást megengedő szokás egy időben nagyon elterjedtté vált, valószínűleg azért, mert az emberekben van egy ilyen hülyeség, hogy a 3 az egy olyan szép szám, meg három a magyar igazság, meg hasonló f@szságok, de ez egy ultrabaromság szerintem. Háromszor simán elkúrhatja a jelszót olyan felhasználó is, aki egyébként a felhasználói azonosító "tulajdonosa". Először mondjuk begépel egy olyan jelszót, amit másik oldalon használ, aztán rájön, hogy hoppá, ja, ez nem is az, ami ide kell (1/3). Vagy még az is lehet, hogy megpróbálja még egyszer, mert még nem ugrik be neki, hogy ezt a jelszót nem ezen az oldalon használja, hanem azt hiszi, hogy csak elgépelte. Utóbbi esetben máris 2 próbálkozásnál járunk (2/3). Aztán mondjuk begépelné a jó jelszót, de véletlenül nagybetű helyett kisbetűt ír (tehát megint elgépelte, 3/3). A 3 próbálkozást máris elértük, te meg kitiltod a francba, a felhasználó meg anyázhat, úgysem hallod meg.
  Simán lehet, hogy nincs is épp lehetősége IP-címet váltani (mivel mondjuk fix IP-címet kap).
  Nyilván a próbálkozások számát korlátozni kell, mivel így az automatizált kísérletek számát is korlátozni tudjuk, de akkor már jóval értelmesebb megkövetelni egy komolyabb kritériumoknak megfelelő (pl. kellően hosszú, stb.) jelszót, és egy pár próbálkozás után alternatív megoldásokhoz folyamodni (és csak még több próbálkozás után kitiltani átmenetileg).
  Ha megnézed, pl. a Google-fiókhoz való bejelentkezésnél sem tilt ki 3 próba után: egy pár elrontott próbálkozás után CAPTCHA megfejtését is követeli, ezzel máris szűri az automatizált kísérleteket (legalábbis azok egy részét biztosan).
  Gondoltam megemlítem, hogy fontold meg ezt a 3-as számot azért, túl kevés.

• #2545 Sk8erPeter nagyúr martonx #2541

  Új Válasz 2014-08-15 21:40:43 #2545

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #2541 üzenetére

  "Aztán szerintem az alulvonósdi elég idétlen az SQL nevezéktanokban (html-ben persze tökéletes az alulvonás, de ez most SQL). Miért nem lehet simán SizeAndPrice-nak hívni a táblát? Ez totál szubjektív, de szerintem sokkal szebb felesleges alulvonások nélkül."
  Ahogy írtad, ez totál szubjektív, de még ráadásul függ attól is, hogy milyen környezetben/csapatban dolgozol, ott mi a konvenció, meg milyen programozási nyelv van "mögötte" (pl. Te elsősorban SQL Servert használsz, plusz C#-ot, ott egyértelműen a PascalCase/camelCase a nyerő/megszokott, furán mutatna a kód miatt is az underscore), nincs egyértelmű válasz rá. Egyébként érdekesség, hogy a phpMyAdminnál az van, hogy az underscore-ok "mentén" csoportosít (elvileg PHP-ben meg az underscore a megszokott, lásd a könyvtári függvényeket, leszámítva persze az OOP-seket; én ez utóbbiakhoz alkalmazkodom mondjuk): pl. ha van egy db_blabla, meg egy db_test táblád, azt egy "db" nevű lenyitható csoportba rakja. Szerintem amúgy egyáltalán nem idétlen az alulvonósdi, csak ha rááll az ember agya az egyikre, akkor inkább azt szereti.
  Erre is illik a közhely, hogy a konzisztencia a legfontosabb. Ahogy kifejtik több topicban is:
  http://programmers.stackexchange.com/questions/27264/naming-conventions-camelcase-versus-underscore-case-what-are-your-thoughts-ab
  http://stackoverflow.com/questions/953030/naming-conventions-for-tables-and-columns-in-database
  http://stackoverflow.com/questions/1881123/table-naming-underscore-vs-camelcase-namespaces-singular-vs-plural

• #2534 Sk8erPeter nagyúr PumpkinSeed #2532

  Új Válasz 2014-08-15 09:17:12 #2534

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2532 üzenetére

  Mikor vetted azt a könyvet? A prepared statementek használata nem egy újkeletű dolog. A PHP 5 meg már 2004 júliusában megjelent. Régi könyvekből meg szinte semmilyen folyamatosan fejlődő programozási nyelvet nem éri meg elkezdeni tanulni, mivel ezer dolog változhat az évek során, például a nyelvi adottságok, best practice-ek.

• #2531 Sk8erPeter nagyúr PumpkinSeed #2530

  Új Válasz 2014-08-15 09:01:03 #2531

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2530 üzenetére

  Akkor azt a könyvet öntsd le benzinnel, aztán gyújtsd fel. Manapság ezek szerint annyit ér. Egyébként a prepared statementeknek köze nincs az OOP-hoz, a kettő összevetése nem tudom, hogy miből jött ki.

• #2529 Sk8erPeter nagyúr joni1700 #2525

  Új Válasz 2014-08-14 23:45:48 #2529

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz joni1700 #2525 üzenetére

  Még jó, hogy ilyen értelmesen kifejtetted, hogy mi is a bajod vele... Legalább mindenki megfontolja ezentúl, hogy adjon-e legközelebb neked segítséget. (Főleg Apollo17hu, aki önzetlenül rádszánta az idejét.)

  (#2506) PumpkinSeed :
  "A Sublime Text is IDE-nek számít?"
  Szerintem nem számít annak. Ja, kb. olyasmi, mint a Notepad++, iszonyat sok pluginnal felokosítva. Az IDE ennél több. (Amúgy igazad van, hogy amikor beszéltem az IDE-kről, rossz ötlet volt odasorolni a Sublime-ot is a többi közé, inkább csak a népszerűsége miatt jutott eszembe.)

  Használod már végre a prepared statementeket?

• #2505 Sk8erPeter nagyúr PumpkinSeed #2504

  Új Válasz 2014-07-11 18:40:06 #2505

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2504 üzenetére

  Valahogy nehéz elhinni, hogy csak gyorsmegoldásként van így, mert a prepared statement használata nem jelent érdemben plusz időt ahhoz képest, hogy konkatenálod a query-t, és azzal szenvedsz, ha már legalább egyszer használtál prepared statementeket. Tényleg nem csak szopatásból találják ki ezeket, hanem a fejlesztő megsegítésére. Hidd el, miután úgy használod, sokkal minőségibbnek és átláthatóbbnak fogod látni a saját kódodat is. Jótanácsként mondom, nem csak hogy cseszegesselek, még ha úgy is tűnik...

  "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. "
  Egyáltalán nem értem az összefüggést. Miért, egy normális IDE használatával nem tudnád mindezt megoldani?
  Pont most írtam a másik topicban, hogy nem nagyon értem, akár egy kis projektnél is mire jó, hogy nehézkesebbé tesszük a dolgunkat azzal, hogy minimális fejlesztőkörnyezeti támogatást sem kapunk kódolás közben. Ujjbegy-és csuklóedzés, vagy mi?

  "Az aposztrófok zavartak be, mert utána nem jelentkezett a jelenség. "
  Ennek nem sok értelme van így, mivel azt mondtad, hogy egyszer sikeresen feltöltésre kerül az adat, máskor meg kinullázódik. Ha épp sikeres volt a feltöltés, és akkor is idézőjelben volt, akkor az miért volt sikeres?

  Szóval valami más lesz ott a probléma, és később is előjöhet.

• #2503 Sk8erPeter nagyúr fordfairlane #2502

  Új Válasz 2014-07-11 16:34:12 #2503

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz fordfairlane #2502 üzenetére

  Jaja, csak az a furcsa, hogy ha ilyen jellegű probléma van, akkor hogyan lehetséges, hogy ez nem ütközött ki korábban: végül is úgy, amilyennek a kódja látszik, semmi validálás, előfeldolgozás, csak úgy simán hadd szóljon.

• #2501 Sk8erPeter nagyúr sztanozs #2500

  Új Válasz 2014-07-11 16:22:26 #2501

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #2500 üzenetére

  Na ez simán lehet, viszont ezt a problémát már jóval adatbázis-buzerálás előtt kezelni kellene, ezért jogos fordfairlane megjegyzése, miszerint inkább csak elfedte a hibát, mintsem megszüntette volna.

• #2499 Sk8erPeter nagyúr bambano #2497

  Új Válasz 2014-07-11 16:12:54 #2499

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #2497 üzenetére

  Hopsz, na ez most tényleg az én hülyeségem volt, bevallom, a linkelt hsz. fölött átsiklottam. Nálam már korábban kiakadt a gányolásszenzor.
  Szóval innen a félreértés, bocsánat.
  Ez esetben már értem a felvetésedet is.

  (#2498) fordfairlane :
  Na ja. Engem azért érdekelt volna, vajon akkor pontosan miért is nullázódtak ki az értékei, de úgy látszik, ezt már nem tudjuk meg.

• #2496 Sk8erPeter nagyúr fordfairlane #2494

  Új Válasz 2014-07-11 15:50:05 #2496

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz fordfairlane #2494 üzenetére

  Ez teljesen jogos. Bár ha nagyon akarom, és a vonalkód fix hosszú, akkor string paddinggel fel lehetne akár tölteni 0-kkal a kimaradókat balról, de minek.

  Részemről a lebegőpontos ábrázolás szóba sem jött, ezzel bambano kezdett előhozakodni, bár nem értem még mindig, minek.

  (#2495) bambano :
  Hogy jött egyáltalán képbe a lebegőpontos ábrázolás? Pont erre kérdeztem rá, erre visszakérdezed ugyanazt... Kicsit érdekes irányt vett a beszélgetés, mintha némi skizofrénia került volna a képbe.

• #2493 Sk8erPeter nagyúr bambano #2492

  Új Válasz 2014-07-11 15:35:07 #2493

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #2492 üzenetére

  Hát te pont erről beszélsz, amit én nem kicsit furcsálltam, akkor magad sem érted, miről beszélsz, és tőlem kérsz segítséget?

• #2491 Sk8erPeter nagyúr jocomen #2490

  Új Válasz 2014-07-11 14:51:50 #2491

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz jocomen #2490 üzenetére

  Hát ha pl. betűk és számok egyaránt előfordulnak a vonalkódban, akkor nyilván nem kéne integerként tárolni. Ha biztosan csak számok vannak benne, akkor miért is ne, teljesítmény-szempontból még jobb is lehet. A kollégától azért kérdeztem vissza, mert nem igazán értem, hogy jönnek ide a tizedesvesszők/-pontok, amikor egy vonalkódról beszélünk.

• #2489 Sk8erPeter nagyúr bambano #2488

  Új Válasz 2014-07-11 14:26:54 #2489

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #2488 üzenetére

  Nem egész szám egy vonalkódnál?

• #2485 Sk8erPeter nagyúr PumpkinSeed #2479

  Új Válasz 2014-07-11 01:35:55 #2485

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2479 üzenetére

  Ez komolyan hihetetlen, már tudtommal legalább 1,5-2 éve foglalkozol webfejlesztéssel, hogyan lehetséges, hogy még mindig simán konkatenálod az adatbázis-query-ket? Miért nem használod azokat a rohadt nyomorult prepared statementeket? MySQLi-ben is vannak, PDO-ban is, mi akadályoz meg benne, hogy használd? Hogy valami rakás szar tutorialban nem azt a megoldást mutatták?
  A PHP topicot is követed, még mindig nem tűnt fel, hogy aki ilyen módon gányol, az mindig megkapja, hogy ne ölje már halomra a kismacskákat?
  Nem beszélve arról, hogy a $_POST-tömb tartalmát egyrészt közvetlenül, másrészt mindenféle ellenőrzés nélkül használod... Ha már kókányolsz össze-vissza, legalább ne ilyen durván. Csak hogy még fokozzuk az élvezeteket, még mindig csak Notepad++-ban kódolsz, "jó lesz az"-alapon?

• #2460 Sk8erPeter nagyúr PumpkinSeed #2459

  Új Válasz 2014-07-03 20:05:15 #2460

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2459 üzenetére

  Igazad van egyébként, mert foglalt neveket nagyon nem illik megadni,pont azért,mert olyan problémák adódhatnak belőle, amilyeneket a kérdező említett (sikertelen query-k),ha nem használnak megfelelő "körítő" karaktereket, amikkel a problémák elkerülhetőek.

• #2458 Sk8erPeter nagyúr PumpkinSeed #2457

  Új Válasz 2014-07-03 18:52:37 #2458

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2457 üzenetére

  "Ilyen oszlop nevet nem szokás adni, hogy key."
  Nincs ilyen íratlan és írott szabály. Bár jelen esetben ha a felhasználó azonosítójára gondolt a kérdező, akkor mondjuk tényleg hülyeség és indokolatlan a "key" név. Mondjuk ennél csak a magyar mezőnevek rosszabbak.

• #2456 Sk8erPeter nagyúr Joci93 #2455

  Új Válasz 2014-07-03 17:32:34 #2456

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Joci93 #2455 üzenetére

  Meg kellett volna inkább próbálnod úgy, hogy a lekérdezésben így használod: `key` (tehát grave accent/backtick használatával). Ezenkívül sose használj a SELECT-lekérdezésben *-ot. Add meg konkrétan azokat a mezőket, amiknek az értékét le szeretnéd kérdezni.

• #2414 Sk8erPeter nagyúr Agyasima #2413

  Új Válasz 2014-05-22 12:42:30 #2414

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Agyasima #2413 üzenetére

  Én túl sokat nem segítettem, inkább általánosságokat írtam, úgyhogy csak martonx-nek köszönd. Bár ettől még szívesen.

• #2410 Sk8erPeter nagyúr Agyasima #2404

  Új Válasz 2014-05-19 15:54:32 #2410

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Agyasima #2404 üzenetére

  Nincs olyan, hogy egy tábla "alá" tartozik egy másik tábla. Össze tudod kapcsolni őket, meg tudod határozni, ki kivel milyen kapcsolatban van, hol van idegen kulcs, stb., de fizikailag nem tartozik alá egyik sem a másiknak.

  Az egy projekthez tartozó feladatok és találkozók listájának megjelenítése egyáltalán nem triviális. Gondolom a "project" tábla tartalmazza egy projekt tök általános adatait, főbb jellemzőit, van egy id-je. Aztán feltételezem, egy másik kapcsolótáblában a projekt id-je és egy feladat id-je össze van kapcsolva, vagy csak magában a "feladatok" táblában egyből szerepel berakva az egyik mezőbe a projekt id-je.
  Aztán gondolom egy megint másik "talalkozok" táblában szerepel a projekt id, és a találkozó általános adatai, vagy megint csak egy kapcsolótábla van bevetve (de utóbbiról nem tettél említést, úgyhogy gondolom nincs ilyen különálló kapcsolótábla, nem is biztos, hogy kell, feladattól függ).

  Na de egy lekéréssel hogy akarnád ezt megjeleníteni? Miért lenne az neked jó?
  Ömlesztve szerepeljenek a projekt általános adatai folyton ismétlődve, minden eredményhez, és legyenek hozzákapcsolva a feladatok, aztán a találkozók meg ki tudja, milyen megjelenés szerint látszanának?

  Mivel nem ismerjük a tábláid összetételét, és a leírásod meg teljesen általános volt, minden konkrétum nélkül, a feladatot sem pontosítottad, így mi sem tudunk konkrétumokkal szolgálni.

• #2359 Sk8erPeter nagyúr jocomen #2358

  Új Válasz 2014-04-25 17:51:36 #2359

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz jocomen #2358 üzenetére

  Első felére: phpMyAdminban is összeállíthatsz query-ket.

  "Több adat (rekord) bevitele megoldható 1 utasításban? És az hogy néz ki?"
  Úgy érted, egyazon táblába?
  Például így érted?
  INSERT INTO `táblád_neve` (`egyik_mezo`, `masik_mezo`, `harmadik_mezo`)
  VALUES
  (1, 'masodik_adat', 'harmadik_adat'),
  (2, 'masodik_adat', 'harmadik_adat'),
  (3, 'masodik_adat', 'harmadik_adat');

• #2356 Sk8erPeter nagyúr FireFox1996 #2355

  Új Válasz 2014-04-23 22:19:58 #2356

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz FireFox1996 #2355 üzenetére

  "De írjatok csak nyugodtan olyan kód sorokat, amiben felesleges sorok/részek vannak"
  Fárasztó vagy nagyon, remélem, tudod... De a szavak értelmetlen kiforgatása legalább megy.
  Sztem is fejezzük be, eddig is értelmetlen volt.

• #2354 Sk8erPeter nagyúr dellfanboy #2352

  Új Válasz 2014-04-23 20:49:51 #2354

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz dellfanboy #2352 üzenetére

  Megpróbálhatnál esetleg nem úgy írni, mintha rohanva csetelnél, hanem összeszedetten írnád le, mi is a felépítése a tábláknak, és mi is a konkrét probléma, mert össze-vissza használtad a példakódodban a neveket is (most akkor mit joinoltál eredetileg mivel?!), plusz azt sem írtad le, igazából mi a hibaüzenet; egyszer "oszlopnév" nevet adtál a mezőnek, egyszer "oszlop1"-et, aztán "oszlopid"-t, ember legyen a talpán, aki kiigazodik ez alapján, hogy most akkor id-kat kapcsoltál-e össze, vagy mást (is).

• #2353 Sk8erPeter nagyúr FireFox1996 #2347

  Új Válasz 2014-04-23 20:45:53 #2353

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz FireFox1996 #2347 üzenetére

  Ne szívassál már ilyen teljesen elvetemült példákkal. Hogy jön ez ide? Semmi köze nem volt ahhoz, hogy ott volt egy WHERE 1=1 feltétel, ami lényegében SEMENNYI overheadet nem jelent. Erről beszéltünk. Nem másról (amit te említettél).
  Körülbelül a példádnak annyi köze volt ahhoz, amiről eredetileg szó volt, mintha azt mondtad volna, hogy nem illik SELECT *-ot használni, mert tök felesleges mezőket is lekérsz. Az állítás önmagában teljes mértékben igaz, csak köze nincs a témához, amiről szó van.
  Szóval ne keverjük a szezont a fazonnal, de egyébként is szerintem kimerült a téma, mert alapvetően egyetértünk abban, hogy ne legyen a kódban olyan, aminek nem kell ott lennie, csak az eredeti felvetésed - "szerintem az felesleges... még 1 értékelést kell végezni az sql servernek..." - volt kicsit félrevezető (mintha jelentene bármit is az az 1 értékelés).

  Tulajdonképpen most csak rágunk egy gumicsontot, de semmi hasznos nem sül ki belőle.

• #2346 Sk8erPeter nagyúr FireFox1996 #2345

  Új Válasz 2014-04-23 16:30:11 #2346

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz FireFox1996 #2345 üzenetére

  Ez az a kategória, amire még az elcsépelt "sok kicsi sokra megy"-mondást se lehet ráhúzni, annyira jelentéktelen a különbség. Az tény, hogy felesleges, de lényegében nem számít, max. ránézésre tűnik "szemetesebbnek" a kód, bár van olyan szempont is, amit Apollo17hu említett.

• #2344 Sk8erPeter nagyúr FireFox1996 #2342

  Új Válasz 2014-04-23 16:11:02 #2344

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz FireFox1996 #2342 üzenetére

  "szerintem az felesleges... még 1 értékelést kell végezni az sql servernek..."
  Tyűha, biztos HATALMAS overheadet jelent az adatbázisszervernek az 1-nek az 1-gyel való összehasonlítása...

• #2323 Sk8erPeter nagyúr Jagerszki #2322

  Új Válasz 2014-04-14 15:24:08 #2323

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Jagerszki #2322 üzenetére

  https://dev.mysql.com/doc/refman/5.7/en/mysql-for-excel-install.html

  "To install, download and execute the MySQL Installer. Select the MySQL for Excel product and then proceed with the installation. See the MySQL Installer manual for additional details."

• #2321 Sk8erPeter nagyúr Jagerszki #2319

  Új Válasz 2014-04-14 15:20:04 #2321

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Jagerszki #2319 üzenetére

  Csak a phpMyAdminból lehetett kitalálni, hogy MySQL-t használsz (nem mindegy, hogy milyen SQL-implementáció).

  "Létre kell hozni előtte egy megfelelő szerkezetű SQL adatbázist"
  Jaja.

  "vagy simán felismeri a szabályokat a phpMyAdmin?"
  Nincsenek "szabályok", úgyhogy nincs mit felismerni.

  Viszont amit Ablakos linkelt az imént, az igen jónak tűnik. Ez már próbálja is detektálni az egyes mezők típusát.

• #2299 Sk8erPeter nagyúr Akcept #2298

  Új Válasz 2014-04-11 01:25:19 #2299

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Akcept #2298 üzenetére

  Eleve nem kellene, hogy gondot okozzon az, hogy valaki aposztrófot tölt fel. Más egyebet nem tok elmondani, kérem kapcsolja ki.

• #2284 Sk8erPeter nagyúr PumpkinSeed #2281

  Új Válasz 2014-04-07 12:29:39 #2284

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PumpkinSeed #2281 üzenetére

  Például beillesztésnél tudod felhasználni a szekvenciát.
  Vegyünk egy nagyon egyszerű példát: van egy supplier nevű táblád (az általad létrehozott supplier_seq alapján), első mezője egy int id, ami primary key is egyben. Másik mezője legyen a példa kedvéért egy name mező, nvarchar2(50) típussal.
  Feltöltesz valami újat, pl.:

  insert into supplier
  values (supplier_seq.nextval, 'blabla');

  A lényeg tehát a supplier_seq.nextval, ezzel tudod kivenni a szekvencia soron következő értékét.

• #2279 Sk8erPeter nagyúr bambano #2278

  Új Válasz 2014-04-06 23:53:01 #2279

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-06 21:51:42 #2276

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-06 20:31:46 #2273

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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...

• #2271 Sk8erPeter nagyúr bambano #2270

  Új Válasz 2014-04-06 17:16:09 #2271

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #2270 üzenetére

  jó, tudom, te az "a" betűre is hibát dobsz

  Komolyra fordítva amúgy valahol eléggé el van cseszve a megközelítésed, ha egy felhasználótól érkező aposztróf miatt paráznod kell az SQL Injectiontől...

• #2269 Sk8erPeter nagyúr csabyka666 #2268

  Új Válasz 2014-04-06 15:08:47 #2269

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz csabyka666 #2268 üzenetére

  Eleve rossz a megközelítésed, ilyet SOHA nem csinálunk, nem konkatenálunk query-t változókkal, prepared statementeket használunk, ahogy a PHP topicban neked már vagy hússzor leírtuk, és a probléma meg van oldva.

  (#2266) bambano :
  Őő, hát azért az aposztróf vagy épp idézőjel karakter talán nem egy olyan extra karakter, ami miatt hibát kéne dobni a felhasználónak... lásd épp az említett példát.

• #2123 Sk8erPeter nagyúr martonx #2122

  Új Válasz 2014-02-16 19:39:44 #2123

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #2122 üzenetére

  Igazából ez nem olyan meglepő, az SSD amúgy is bármivel csodát művel.
  Aki kételkedik, vegyen magának, és nyilván az adatbázis szarai az SSD-n legyenek. Igen, hátránya nyilván a HDD-vel szembeni rövidebb élettartam és a relatíve magas ára.

• #2090 Sk8erPeter nagyúr martonx #2089

  Új Válasz 2014-01-27 02:47:56 #2090

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #2089 üzenetére

  "kis tábla méreteknél ez észrevehetetlen, de ha egy táblában van 2-3 ilyen szarul megoldott indexed, és a tábláid több százezer sorosak"
  Ha jól emlékszem, az eredeti felvetésben pont az szerepelt, hogy előre tudható, hogy a táblák relatíve kicsik (mit tekintünk egyébként kicsinek?), és sosem lesz bennük többszázezer rekord. Tehát szerintem arról nincs értelme jelen esetben beszélni, hogy "mi lenne, ha", hanem csak arról, ami van, mert pont azért érdekes a kérdés-felvetés, hogy vajon minden esetben helytállóak-e a tankönyvszerű, berögzült gondolatok, vagy van, amikor ettől el lehet térni, ha nem okoz észrevehető különbséget.
  Az alapötleten először én is felhördültem magamban, hogy háccccezmicsodadolog, én nem így tanultam, és nem ehhez vagyok hozzászokva, és én amúgy sem így oldanám meg, aztán rájöttem, hogy elképzelhető olyan eset, amikor kicsit rugalmasabban is meg lehet közelíteni a kérdést, ha valakinek adott esetben úgy kényelmes, amennyiben AZ ADOTT ESETBEN (és nem akkor, HA más lenne) nem okozna észrevehető teljesítménybeli romlást. Épp ezért érdekelt, hogy vajon mik lesznek a meglátások ezzel kapcsolatban (még ha én még az adott feladat kedvéért sem így oldanám meg), de sajnos aztán bejött az, amire számítottam, hogy jönnek a tankönyvszerű elvekre hivatkozások (néhol helytelenül, lásd korábban (de)normalizálás fogalmának/elvének nem sok köze van ahhoz, hogy az elsődleges kulcs int vagy string), és a "na de gondolj bele, HA LENNE többtízcsillióbilliókétszáz rekordod"-jellegű megjegyzések, meg a többtízgigarammalnemparaöcsém, és ezek általában csak pont a lényegről terelik el a szót.

• #1709 Sk8erPeter nagyúr Flashback #1704

  Új Válasz 2013-04-03 19:34:41 #1709

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Flashback #1704 üzenetére

  pl. decimal típusú mezőről beszélsz? A kérdésed nem volt túl specifikus.
  A mezőt magát szeretnéd általánosan beállítani ([link]), vagy pedig csak megjelenítésnél levágni ([link])?

• #1694 Sk8erPeter nagyúr alratar #1692

  Új Válasz 2013-03-20 17:32:49 #1694

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz alratar #1692 üzenetére

  "az id hosszúsága előbb-utóbb több tíz hosszúságú is lehet."
  http://dev.mysql.com/doc/refman/5.0/en/integer-types.html
  tartományok:

  signed int: -2147483648 - 2147483647
  unsigned int: 0 - 4294967295

• #1682 Sk8erPeter nagyúr bambano #1681

  Új Válasz 2013-03-11 21:17:59 #1682

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bambano #1681 üzenetére

  Minél jobb közelítést?

• #1664 Sk8erPeter nagyúr pittbaba #1663

  Új Válasz 2013-02-15 12:45:50 #1664

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1663 üzenetére

  Ne tőlünk kérj elnézést, hanem magadtól.

• #1662 Sk8erPeter nagyúr pittbaba #1661

  Új Válasz 2013-02-15 01:54:14 #1662

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1661 üzenetére

  De nézd meg az eredeti kérdésedet, abból nem az derül ki, hogy megpróbáltál volna minimális kutatómunkát is végezni kérdés előtt. Most érted, tök más, ha úgy kérdezed, hogy ezt meg azt találtam, és az alapján így meg úgy értelmezem, szerintetek így van-e, vagy ha tényleg nem találsz valamit, akkor megírod, hogy nem sikerült erről normális infót találnod, mintha egyszerűen rábízod másra az elméleti fejtegetést, vagy a találatok belinkelését (ahogy én is tettem, segítőszándékkal), hadd töltsön csak vele időt más helyetted... Ezáltal vész el a dolog szakmaisága, mert onnantól kezdve nem egy dolog jobb/rosszabb megvalósíthatóságáról, lehetőségekről, ötletekről beszélgetünk, hanem szimplán olyan dologról, ami a dokumentációban is kicsi keresgélés alapján megtalálható. Az eredeti kérdésedben ezzel szemben érdekes problémát vetettél fel, kaptál is választ rá bőven.

• #1660 Sk8erPeter nagyúr pittbaba #1659

  Új Válasz 2013-02-14 00:37:02 #1660

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1659 üzenetére

  Pedig angoltudás nélkül az informatika világában elég nehéz lesz mozogni.

• #1657 Sk8erPeter nagyúr pittbaba #1656

  Új Válasz 2013-02-13 15:13:21 #1657

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1656 üzenetére

  Javaslat: [link]

  http://stackoverflow.com/questions/924265/what-does-the-key-keyword-mean
  http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
  http://stackoverflow.com/questions/1401572/what-are-differences-between-index-v-s-key-in-mysql
  http://www.quora.com/MySQL/What-is-the-difference-between-using-KEY-and-INDEX-in-MySQL
  http://stackoverflow.com/questions/1071180/is-the-primary-key-automatically-indexed-in-mysql
  http://www.quora.com/MySQL/What-is-the-difference-between-using-KEY-and-INDEX-in-MySQL

  Az a baj, hogy túl kevés az információ a zzzinterneten...

• #1642 Sk8erPeter nagyúr martonx #1641

  Új Válasz 2013-02-12 11:31:33 #1642

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1641 üzenetére

  Elvileg már az indexelés is megvolt, ha hallgatott a tanácsokra. Egyébként a MySQL-szerver beállításairól sem tudunk semmit, hogy egyáltalán futási idők vannak engedélyezve, stb. Meg egy-egy EXPLAIN is segíthet a további teendők kiderítésében.

• #1640 Sk8erPeter nagyúr martonx #1639

  Új Válasz 2013-02-12 00:24:28 #1640

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1639 üzenetére

  Szerintem már a kérdező sem a telóján futtatja, mivel már nem SQLite-ról beszél, hanem MySQL-szerverről...

• #1633 Sk8erPeter nagyúr pittbaba #1630

  Új Válasz 2013-02-11 15:41:19 #1633

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1630 üzenetére

  Szívesen, akkor végül is ezzel megoldódott a sok mindent importálós para?

• #1625 Sk8erPeter nagyúr pittbaba #1622

  Új Válasz 2013-02-10 18:52:14 #1625

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1622 üzenetére

  Elolvastad a leírását annak, amit linkeltem? A hsz.-edből nem úgy tűnt.

  Azt sem értem, miért feltételezed, hogy na majd a következő hsz.-edben írt scripted megoldja, ami csak annyit csinál, hogy egy az egyben beolvassa az egész dumpot, és megpróbálja lefuttatni a query-t. Miért feltételezed, hogy ennél majd nem ütközöl ugyanazokba a korlátokba?

• #1621 Sk8erPeter nagyúr pittbaba #1620

  Új Válasz 2013-02-10 13:24:58 #1621

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1620 üzenetére

  Szabdald fel az adatbázist, és részenként importáld.

  Alternatíva:

  http://www.ozerov.de/bigdump/you-want/

• #1601 Sk8erPeter nagyúr pittbaba #1600

  Új Válasz 2013-02-08 18:25:12 #1601

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1600 üzenetére

  A látatlanbant arra írtam, hogy most nincs időm kipróbálni...

• #1599 Sk8erPeter nagyúr pittbaba #1596

  Új Válasz 2013-02-08 18:15:37 #1599

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz pittbaba #1596 üzenetére

  látatlanban: indexelés, EXPLAIN?

  Szerk.: ja, most látom, hogy írtad is (csak átfutottam a kérdéseden):
  "Olvastam, hogy létre lehet hozni index-et a tábla oszlopaihoz, milyen oszlopokhoz érdemes?"
  legalább próbálkozz egy EXPLAIN-nel. Na de konkrétabbat majd ha esetleg kipróbáltam (és elolvastam normálisan a kérdésedet ), meg ha addig nem érkezik másik válasz.

• #1559 Sk8erPeter nagyúr Sk8erPeter #1556

  Új Válasz 2013-01-18 23:13:22 #1559

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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?"

• #1556 Sk8erPeter nagyúr rum-cajsz #1552

  Új Válasz 2013-01-18 03:08:14 #1556

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz rum-cajsz #1552 üzenetére

  "Vagy mit nevez ő a XXI. század fejlesztői eszközének?"
  Ezeket a kérdéseket miért nem teszitek fel közvetlenül neki a belinkelt topicban?
  (Szerk.: tisztább is lenne, mint a háta mögött beszélni a hozzászólásáról...)

• #1548 Sk8erPeter nagyúr DonThomasino #1547

  Új Válasz 2013-01-16 11:45:38 #1548

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz DonThomasino #1547 üzenetére

  Konkrétabban?

• #1517 Sk8erPeter nagyúr lakisoft #1516

  Új Válasz 2012-12-28 22:43:10 #1517

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz lakisoft #1516 üzenetére

  Nem is neked küldte, hanem a kérdezőnek.

• #1515 Sk8erPeter nagyúr martonx #1514

  Új Válasz 2012-12-28 21:52:43 #1515

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1514 üzenetére

  Hű, ez tényleg jónak tűnik! Beleolvasgattam, és tök jó látni végre olyan e-bookot, ahol nem hordanak össze hülyeségeket, és tök emberi nyelven közlik a JÓ információt. Biztos én is hasznát fogom venni, köszi!

• #1509 Sk8erPeter nagyúr Inv1sus #1508

  Új Válasz 2012-12-19 00:05:31 #1509

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Inv1sus #1508 üzenetére

  Na, ez gyorsan ment, jóhír, szívesen!

• #1505 Sk8erPeter nagyúr fordfairlane #1504

  Új Válasz 2012-12-18 14:53:52 #1505

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz fordfairlane #1504 üzenetére

  De ilyen tagelés-kategorizálás esetében miért lenne már jó a pipe-karakterrel elválasztott módszer? Indokot még nem írtál, szerintem jogos volt, hogy elég csúfnak találták a megoldást a többiek, meg én is.
  Nehézkes és lassú lehet a keresése, nehezebb szűrni, eleve ez a LIKE-os megoldás elég hányadék. Nem is lehet normálisan végigiterálni a kapcsolt elemeken. Módosítás/törlés is problémás, és még elég sok más érvet is fel lehetne sorolni ellene.

• #1503 Sk8erPeter nagyúr Inv1sus #1502

  Új Válasz 2012-12-18 13:46:02 #1503

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Inv1sus #1502 üzenetére

  Szívesen! Írd meg itt, ha nem megy.

• #1499 Sk8erPeter nagyúr Inv1sus #1497

  Új Válasz 2012-12-17 21:49:17 #1499

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Inv1sus #1497 üzenetére

  "A kategóriákat '|' jellel elválasztva rakom be az adatbázisba"
  Ez az, amit kerülj el, válaszd szét rendesen. Sok sort fog eredményezni, de az nem baj. Annyi sor lesz, ahány taget/terméket/akármit akarsz hozzákapcsolni az adott entitáshoz.

  Leegyszerűsítve:

  termékek tábla
  -----------------------
  id ; termék neve; kategóriák
  123 ; én termékem ; kategória1|kategória765

  HELYETT

  termékek tábla
  -----------------------
  id ; termék neve
  123; én termékem

  kategóriák tábla
  -----------------------
  id; kategória neve
  1; kategória1
  765; kategória765

  termékek-kategóriák összekapcsoló tábla
  -------------------------------
  id; termék_id; kategória_id
  1; 123; 1
  2; 123; 765

• #1470 Sk8erPeter nagyúr Lacces #1469

  Új Válasz 2012-12-04 16:26:40 #1470

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1469 üzenetére

  "suli-ban" sulitiltás?
  A tárolt eljárás pedig sokszor jó kis segítség tud lenni, például ASP.NET-ben. Amúgy a tárolt eljárás arra is jó, hogy nem kell a query-vel elrondítanod az alkalmazásod kódját, hanem az adatbázisban tartod azt, aminek épp ott a helye, vagy amit úgy érzel, nyugodtan rábízhatsz az adatbázisra, és azt terheled a feladat megoldásával, stb. Meg így adhatsz neki egy jó beszédes nevet, aztán meghívhatod az alkalmazásod kódjából a megfelelő paraméterek átadásával. Csomó mindent el lehet intézni benne, ami csúnya lenne alkalmazásból, vagy épp nem akarsz ORM-et igénybe venni rá, satöbbi.

• #1458 Sk8erPeter nagyúr martonx #1457

  Új Válasz 2012-12-02 13:38:20 #1458

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1457 üzenetére

  OK, köszi a választ! Még nincs tapasztalatom Postgre-val, kíváncsi vagyok rá.

• #1456 Sk8erPeter nagyúr martonx #1455

  Új Válasz 2012-12-01 23:57:32 #1456

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1455 üzenetére

  "Ha kocka vagy a szó jó értelmében, akkor mindenhez PostgreSQL-t érdemes használni"
  Miért?
  (Most nehogy attól tarts, hogy én védelmezni kívánom bármelyik SQL-nyelvet, mert eszem ágában sincs, csak kíváncsi vagyok a szempontokra. )

• #1454 Sk8erPeter nagyúr Lacces #1453

  Új Válasz 2012-12-01 16:36:27 #1454

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1453 üzenetére

  Örülök, hogy leesett

• #1452 Sk8erPeter nagyúr Lacces #1451

  Új Válasz 2012-12-01 15:40:45 #1452

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1451 üzenetére

  "-labels ( ez egy olyan varchar lenne, ahol a label_id-k vanak tárolva, például ilyen formátumban: |1|34|45|54| ) - magyarul, minden egyes label_id | | között lenne."
  Ha hatékony megoldást keresel, egyből le kéne, hogy essen, hogy ez aztán garantáltan nem lesz az.
  Amúgy sem értem, minek kéne ilyen pipe-pal elválasztva tárolnod, amikor létrehozol neki egy külön táblát... A product id-val kéne összekapcsolnod, aztán kész.
  Csak gondolj bele, hogy hogyan tudnál ezek között hatékonyan keresni, ha stringben egybe van b@szva... hatékonyan sehogy.

• #1435 Sk8erPeter nagyúr klambi #1434

  Új Válasz 2012-11-13 16:49:30 #1435

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz klambi #1434 üzenetére

  És ezzel mi bajod van? Pont azt csinálja, ami neked kell, egyszerűbben nem lehet megoldani.

• #1426 Sk8erPeter nagyúr Geryson #1425

  Új Válasz 2012-11-04 16:08:26 #1426

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Geryson #1425 üzenetére

  csá Cleveland Brown Jr.

  Egész pontosan mivel próbálkozol? Mutass kódot!

  szerk.: látom közben megoldódott. Bár a pontosvesszőnek pont nem kéne gondot okozni.

• #1424 Sk8erPeter nagyúr Geryson #1423

  Új Válasz 2012-11-04 15:53:40 #1424

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Geryson #1423 üzenetére

  [link]

• #1413 Sk8erPeter nagyúr UBO #1412

  Új Válasz 2012-10-29 17:32:44 #1413

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz UBO #1412 üzenetére

  Azt sem írtad, milyen SQL konkrétan. Ha már vágod az SQL-t, elvileg mindegynek kéne lennie, melyiket használod, gyorsan át tudsz állni rá.
  Nekem pl. MySQL-hez a dbForge Studio for MySQL jött be eddig legjobban, de még nyilván van hatszáz másik fasza program.
  Microsoft SQL Serverhez meg persze Microsoft SQL Server Management Studio.

• #1373 Sk8erPeter nagyúr sztanozs #1372

  Új Válasz 2012-08-29 14:32:59 #1373

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #1372 üzenetére

  Nem lehetne konkretizálni? Biztos nem fognak lenyakazni érte...

• #1371 Sk8erPeter nagyúr martonx #1364

  Új Válasz 2012-08-29 14:13:00 #1371

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1364 üzenetére

  És ez szerinted jó?
  Amúgy az Exceles+TXT-s+rendes adatbázisos összekattintgatós móka valóban egyszerűnek tűnik, bár ha normálisan egységesítve vannak a dolgok, akkor elvileg nem lenne szükség TXT-re és Excelre, de nem akarok naiv lenni, tudom, hogy ez soha nincs így. Tehát az a funkciója hasznos lehet.

  Amúgy sorolhatnál pár ilyen pénzintézetet (!), ahol az Access a fő alap, tényleg érdekelne.

• #1362 Sk8erPeter nagyúr Dave-11 #1361

  Új Válasz 2012-08-28 23:14:39 #1362

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Dave-11 #1361 üzenetére

  "Állítólag nagyon hasznos"
  Ki szerint? És milyen célra hasznos?

  "ami ezt a fajta használatát mutatja be"
  Melyik fajta használatát?

  Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják. Ezerszer hasznosabb, ha a MySQL-re fekszel rá (ha már amúgy is van valami előismereted), vagy MS SQL Serverre, Oracle-re, stb... na, ezek hasznosak.

• #1360 Sk8erPeter nagyúr Lacces #1359

  Új Válasz 2012-08-21 17:47:00 #1360

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1359 üzenetére

  Akkor ezt folytatva: mindenki érti már szerintem, mit szeretnél, úgyhogy még egy ilyen csodás példa nem kell a magyarázat tisztázásához . Előbb linkelt cucc utsó hsz.-ében leírtam, hogy OK, minden hirdető júzer, de nem minden júzer hirdető.
  Tehát akkor rövidre zárva a dolgot: nem kell az a kapcsolótábla. A hirdető egyéb adataiba egyszerűen bepakolod a user id-t.

  Persze lehet ezt tovább bonyolítani, ha még tovább lenne bontva, hogy bizonyos hirdetőknek extra paramétereik lehetnek, és akkor megint előkerül a probléma, hogy NULL értékűek bizonyos paraméterek azoknál a hirdetőknél, amelyeknél nincsenek meg azok az extra paraméterek.
  Akkor már egy táblába kéne pakolni a user id-t, paraméter id-t, paraméterhez tartozó egyik lehetséges value id-t, és így tovább... de gondolom nálad egyezne az összes hirdető plusz adata.

• #1357 Sk8erPeter nagyúr Lacces #1356

  Új Válasz 2012-08-21 13:51:52 #1357

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1356 üzenetére

  modder sok mindent leírt előttem, ami a megvalósítást illeti, tehát azzal a résszel egyetértek. Viszont én még annyit tennék hozzá, hogy bennem a hsz.-ed láttán egyből az a kérdés merült fel, hogy vajon miért feltételezed, hogy a hirdető egy külön állatfaj. A hirdető is egy regisztrált felhasználó, tehát egy user, akinek a helye a user táblában van. Tehát teljesen felesleges a "hirdető neve, hirdető kora, hirdető egyéb adatai", stb. adatokat külön táblában tartani. Ez a felhasználóhoz tartozó adat (user tábla, vagy esetleg egyéb adatok miatt ehhez kapcsolt tábla, de ez opcionális). Az már másik kérdés, hogy ez a felhasználó egyáltalán hirdethet-e, ad-e fel hirdetést, és ha igen, az adott hirdetésekhez milyen adatok tartoznak.
  Itt most a hirdetés hozzákapcsolása szempontjából tehát mellékes, hogy szerepkör alapján hirdethet-e csupán a felhasználó, vagy bármilyen bejelentkezett felhasználó feladhat hirdetést. Nyilván egy expressz.hu-hoz hasonló oldalon az a fő profil, hogy bárki feladhasson hirdetést (mondjuk adott összeg befizetése után), tehát ott nem kell külön hirdető szerepkör (hacsak nem a fizetés után kapja meg a felhasználó a "hirdető" szerepkört, ami akár le is járhat, de még ezt a kérdéskört is lehetne boncolgatni).

  Lényeg tehát: a hirdető is egy felhasználó. A hirdetés pedig külön adat, ami - ahogy előttem elmondták - egyértelműen egy felhasználóhoz tartozik (elég ritka az az eset, hogy több embert akarsz megjelölni hirdetés feladójaként...), tehát itt nem kell külön kapcsolótábla a hirdetés-user kapcsolathoz.

• #1354 Sk8erPeter nagyúr Lacces #1353

  Új Válasz 2012-08-21 13:32:46 #1354

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz Lacces #1353 üzenetére

  "Pozitív kritikát szívesen fogadok."
  Ezen nagyot nevettem. DE POZITÍV LEGYEN ÁM!!!

  Egyébként nem jó a struktúra, de azt mondtad, csak pozitív kritikát fogadsz szívesen.

• #1330 Sk8erPeter nagyúr lakisoft #1329

  Új Válasz 2012-08-10 16:15:48 #1330

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz lakisoft #1329 üzenetére

  "Kedves Uram,"
  Mi van veled

  Feltételezem, kézzel gyorsban bepötyögött kód volt, de ilyen alapon bele lehetne kötni a
  set valami = t2.valami
  részbe is, mert az lehetne pl.
  set t1.valami = t2.valami
  

• #1321 Sk8erPeter nagyúr sanzi89 #1318

  Új Válasz 2012-07-30 13:32:19 #1321

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sanzi89 #1318 üzenetére

  Abban igazad van, hogy írtad, hogy nincs kulcs, ez őszintén szólva kissé számomra elsikkadt a hsz.-ek után. DE ilyen alapon - ha már ilyen jól belejöttünk az egymásba való belekötésbe - attól még tartozhat valami olyan mező is a táblához, ami alapján egyértelműen lehet azonosítani az adott sort (még ha nem is ténylegesen KULCS az adatbázis szintjén!!), de erről sem írtál SEMMIT, tehát fogalmunk nem lehetett az adatbázis-szerkezetedről sem.
  Delphi? Mutasd már meg, itt hol írtál ilyenről egyáltalán: [link]. És ha Delphi, akkor mi van? Ez a rész a lényeg szempontjából miért érdekes? Attól még miért ne lehetne akár grafikus alapú adatbázis-kezelőből módosítani az adatbázist? Mi köze a kettőnek egymáshoz?
  A sok-sok (!!) duplikációval kapcsolatban meg hadd idézzelek:
  "Van benne 2 sor, ami totálisan megegyezik, minden mező értéke ugyan az."
  Amit itt írsz, azt jelenti, összesen 2 sorral van problémád. Ebből tehát rohadtul nem derül ki az, amit a későbbiekben írtál le, hogy SOK duplikáció van, ergo NEM csak két sor.

  "Van egy táblám, benne adatok."
  Semmi információ arról, hogy ez Access lenne, és milyen adatokról van szó (értsd: adatbázis-struktúra, esetleg példa).

  Idióta visszakérdezgetések és a mostani, tök felesleges veszekedés és e-pénisz-villogtatás elkerülése érdekében pl. feltehetted volna a kérdést úgy (csak egy példa), hogy "van egy Access-táblám, semmilyen mező nem azonosítja egyértelműen a sorokat (nincs azonosítójuk), és elég sok sor duplikálva van. Milyen módon tudnám megszüntetni a duplikációt?
  Struktúra:
  ABCDE
  Egy konkrét példa egy sorra (ilyenből van kettő):
  XYZ"

  ======

  (#1319) -Zeratul- : ja, nyilván a kérdés tökéletes volt. Azért olvasd el a fentit, hogy hogyan lehetett volna elkerülni, hogy most itt ilyen óvodás hőzöngés alakuljon ki.

• #1316 Sk8erPeter nagyúr sanzi89 #1315

  Új Válasz 2012-07-30 13:00:16 #1316

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sanzi89 #1315 üzenetére

  Nem tudom, mi a frászt vársz, amikor az elején nekünk kell helyetted kitalálni az infókat, belőled meg harapófogóval kell kihúzni...
  Ha szarul teszed fel a kérdést, talán ne lepődj meg, hogy nem kapsz egyből konkrét választ. És ne forgasd a szemeidet, ha már te kérsz segítséget...

• #1309 Sk8erPeter nagyúr sanzi89 #1308

  Új Válasz 2012-07-30 11:39:26 #1309

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sanzi89 #1308 üzenetére

  Szerencsére nem sok dolgom van Access-szel.
  De gyorsan rákeresve ezzel pl. lehet böngészni Access adatbázist is: RazorSQL
  Lehet, hogy elbeszélünk egymás mellett, de amit írtál, azt úgy értelmezhető, hogy összesen 2 egyező sor van, és az egyiket törölni kellene. De javíts ki, ha arra gondolsz, hogy MINDEN sorból dupla van......
  Ha viszont csak egy, akkor igazából nem vágom, hogy most mi is a probléma, egy rendes grafikus alapú adatbázis-kezelőben csak az adott sornál rámész, hogy delete, és meg is vagy. Vagy beadod query-ként, most csak legegyszerűbb példával élve:
  DELETE FROM akármitábla WHERE id = 3
  [link]

• #1307 Sk8erPeter nagyúr sanzi89 #1306

  Új Válasz 2012-07-30 11:27:31 #1307

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sanzi89 #1306 üzenetére

  Már miért ne lehetne? Összesen van 2 sor, ami egyezik, és az egyik sort törölni szeretnéd? Mi ebben a nehéz? Milyen adatbázis? Milyen adatbázis-kezelőt használsz egyáltalán, hogy a kérdés felmerült?

• #1305 Sk8erPeter nagyúr rum-cajsz #1304

  Új Válasz 2012-07-25 14:41:49 #1305

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz rum-cajsz #1304 üzenetére

  Na várj, szerintem elbeszélünk egymás mellett.
  Senki nem is mondta eddig, hogy a prepared statement ne lenne jó, sőt, eddig mindenki amellett érvelt. Amit sztanozs felhozott, az az, hogy adatbázisonként eltérhet a datetime formátuma (erre én is linkeltem a MySQL-es, meg az MSSQL-es példát, hogy máshogy néz ki), ez már eleve problémát okozhat, tehát hiába adsz át stringként prepared statementtel valamit, ha a formátum akkor is rossz, mert mondjuk más formátumra van konfigurálva az adatbázisszerver, vagy mittudomén.
  De már kezdek én is belezavarodni.

  "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."
  
  Agreed.

• #1303 Sk8erPeter nagyúr rum-cajsz #1302

  Új Válasz 2012-07-25 14:19:11 #1303

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz rum-cajsz #1302 üzenetére

  Idézem, amit itt írt:
  "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."
  Ez egy jogos szempont, erre hogy alkalmazol dátumkonverziós függvényeket úgy, hogy biztosan a jó eredményt kapd?
  Még akkor sem egyértelmű, ha legalább az évszám négy számjegyű, mert így is felcserélődhet a nap-hónap.

  ====

  (#1301) sztanozs : ez végül is igaz.
  Mondjuk a UNIX timestamp (másodpercek) legalább tuti nem téved, aztán abból akármilyen formátumra is átalakíthatod.
  A felhasználói inputnál meg normális esetben a normális fejlesztő úgyis megoldja, hogy a dátum szigorúbb feltételekhez legyen kötve, akár szétbontva a dátumot külön-külön mezőkre (év, hónap, nap, stb.), akár egy JavaScript-alapú datepickerrel egyszerűbbé téve a választást.

• #1300 Sk8erPeter nagyúr sztanozs #1299

  Új Válasz 2012-07-25 11:56:45 #1300

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #1299 üzenetére

  Még mindig nem értem, hogy ez önmagában miért oldaná meg azt, ha a fejlesztő vagy a user rossz inputot akarna megadni a datetime mezőhöz. A kiindulópont ez volt, erre állítottad, hogy ez egy megoldás lehet, de még mindig nem mondtad el, hogyan kínál ez áthidaló megoldást nyelvektől függetlenül.

  ===

  (#1298) martonx : igen, de most nem ez a lényeg, hanem hogy ez hogyan oldja meg a rossz formátumok problémáját (ha már ez volt az állítás), amiről korábban szó volt.

• #1297 Sk8erPeter nagyúr sztanozs #1296

  Új Válasz 2012-07-24 22:24:57 #1297

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #1296 üzenetére

  
  Most akkor mutatok két lehetséges változatot, csak kiragadott példa:

  MySQL Prepared Statements
  PHP + PDO Prepared Statements

• #1295 Sk8erPeter nagyúr sztanozs #1293

  Új Válasz 2012-07-24 20:15:20 #1295

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #1293 üzenetére

  Attól függ, milyen prepared statementről beszélsz, mert most már nem egyértelmű számomra.

  =========================

  (#1294) rum-cajsz : jaja, ArchElf készítette, mert a t×künk tele volt a PHP topicban a sok konkatenált fosadék query-vel. Elég találó.

• #1292 Sk8erPeter nagyúr sztanozs #1291

  Új Válasz 2012-07-24 14:32:34 #1292

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #1291 üzenetére

  Ja, hogy így. Igen, mondjuk adatbázisonként eltérhet a formátum, MySQL-ben ilyen: [link]
  "MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'."

  MSSQL-ben: [link]
  "Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds"

  Egyébként konkrétan azért kérdeztem vissza, mert feltételezem, a TÁROLÁS módja a háttérben (tehát magának az adatbázis-kezelőnek a szintjén) viszont általánosan van megoldva, tehát ez alapján magából a tárolt értékből ki lehet nyerni a megfelelő dátumot, legfeljebb lekérdezéskor előfordulhat, hogy valaki nem megfelelő formátumban adja meg a datetime-ot, és akkor nem azt az eredményt kapja, amit elvárt; vagy épp feltöltéskor más formátumban adja meg, mint ami az elvárt, és "rossz" datetime tárolódik, nem?

  Mondjuk egy UNIX timestamp legalább valszeg mindenhol ugyanolyan.

  "Ha sql parancsot konkatenálsz - amit ugye nem illendő - akkor ahány adatbáziskezelő annyi féle datetime megvalósítás"
  Itt viszont nem értem, miért emeled ki a konkatenálást, mert elvileg akkor épp azért, amiről beszélünk, tök mindegy, hogy most konkatenálva adtál át rossz formátumot, vagy prepared statementként.

  Gondolom erre a képre gondoltál: [link].

• #1290 Sk8erPeter nagyúr sztanozs #1285

  Új Válasz 2012-07-24 12:52:53 #1290

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sztanozs #1285 üzenetére

  "A DateTime full szívás, bármilyen adatbázisban "
  Miért?

• #1281 Sk8erPeter nagyúr sanzi89 #1280

  Új Válasz 2012-07-23 15:23:16 #1281

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz sanzi89 #1280 üzenetére

  Nem az a baj, hogy a "log" egy foglalt név? Ilyen problémával már találkoztam MySQL-nél, és ott az a megoldás, hogy köréteszed a visszafelé dőlő aposztrófot, aminek most nem jut eszembe a neve
  Tehát
  log
  helyett
  `log`

  De mindez Access-ben nem rémlik, megy-e, szerencsére nem sok dolgom volt Access-szel.

• #1270 Sk8erPeter nagyúr wolandino #1269

  Új Válasz 2012-07-19 13:11:20 #1270

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz wolandino #1269 üzenetére

  Ja, hát a "kényszert" magára a helyzetre értettem, hogy a régi szar rendszerhez kell igazodnod. Aztán lehet, hogy csak túl kevés információ birtokában vagyok a helyzetetekkel kapcsolatban, és túl jóindulatúan közelítem meg a kérdést.

• #1268 Sk8erPeter nagyúr PazsitZ #1267

  Új Válasz 2012-07-18 15:14:33 #1268

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz PazsitZ #1267 üzenetére

  Most remélem ezt nem rám értetted, még ha az enyémhez is fűzted a kommentedet...
  Lényegében én is ezt magyaráztam.

• #1266 Sk8erPeter nagyúr martonx #1260

  Új Válasz 2012-07-18 14:14:54 #1266

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz martonx #1260 üzenetére

  Amennyire én értettem, rákényszerítik a Linux-környezetet, amiben használnia kell a meglévő, ósdi fosadék rendszert, ami alapvetően MS-alapú, és jelenleg egyszerűbb hozzátákolni némi plusz PHP-kódot, hogy elérje/módosítsa az adatokat, mint az egészet átültetni egy totál új rendszerbe (új adatbázist használva, új alkalmazást fejlesztve), mivel az új rendszer fejlesztése, a régi lelövése épp túl nagy időbeli és anyagi befektetést igényelne. Nyilván ő sem szívesen választotta ezt a gányolást, de ha ez van, hát akkor ez van... ne oltsd le szegényt azért, mert időszűkében kényszermegoldást választ, valószínű, hogy rövidebb alatt sikerült működő tákolmány megoldást találnia, mint amennyi idő alatt egy új rendszert kialakított volna, tulajdonképpen nem ő a hibás azért, hogy kapott egy szar feladatot, egy gány adatbázist és egy szar alkalmazást. Feltételezem és remélem, hogy majd áttérnek normális rendszerre.

• #1256 Sk8erPeter nagyúr wolandino #1255

  Új Válasz 2012-07-16 14:44:47 #1256

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz wolandino #1255 üzenetére

  10 évvel ezelőtt sem értem, minek írtak ékezetet a táblanevekbe. (Mondjuk semmilyen kódba nem szabad ékezetet tenni, legfeljebb kommentbe.)
  Nem tudod átszabni a jelenlegi adatbázis-struktúrát? Mindenhol lecserélni az ékezetes táblaneveket is (gondolom ehhez tartozik valami alkalmazás, ott is átírni), plusz Access helyett valami értelmesebb adatbázist alkalmazni. Ehhez nem is kell átírni a teljes alkalmazást, ami nyilván nagyon időigényes, csak legalább ezeket kellene lecserélni, ez akár max. pár óra alatt is kivitelezhető lenne.

• #1239 Sk8erPeter nagyúr SektorFlop #1220

  Új Válasz 2012-07-13 11:37:13 #1239

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz SektorFlop #1220 üzenetére

  Más, mert a többiek az eredeti kérdést már megoldották: miért nem használsz prepared statementeket? Ez a query-konkatenálás nagyon csúnya és kerülendő megoldás.

  (#1238) Fecogame :
  Mit értesz azalatt, hogy "egybeolvasztani"? Magyarul egy adatbázisba rakni? Mi vele a problémád?
  Amúgy azonos tárhely alatt akarsz két fórummotort használni, vagy két különbözőn?
  Ha az első, akkor annak mi értelme? Ha a második változat, akkor viszont meg kell oldani a külső hozzáférést is az adatbázishoz.

• #1217 Sk8erPeter nagyúr bpx #1215

  Új Válasz 2012-07-02 00:31:55 #1217

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bpx #1215 üzenetére

  Na, a kérdés maga annyira megzavart, hogy már én is félrebeszéltem, meg pontatlanul is írtam, bocsi. A kérdező azt írta, hogy "A dátum 2003.11.26. 10:28:14 ilyen formátumban van.", én ebből úgy értelmeztem, hogy valamilyen oknál fogva string típusként van TÁROLVA az adatbázisban (most szándékosan írtam tárolást!! Mindegy, hogy varchar vagy egyéb ilyen jellegű típusról van szó, és NEM a dátumformátumok valamelyikéről, aminek nyilván megvan a maga tárolási módja, de attól még valamelyik tényleges dátumformátumról van szó), ezért kénytelen vagdosni, stb., de akkor valószínű félreértettem az eredeti felvetést.
  Utána már azt is félreértettem, amit Te írtál, pedig így másodszor elolvasva elég világos, hogy itt csak dátum-megjelenítési formátumot változtatsz, attól még nem tárolod másik formában.
  Akkor most megpróbálom értelmesen megfogalmazni: arra gondoltam, hogy még a megjelenítési formátumot sem biztos, hogy szerencsés, ha az ember változtatja, mert ha mondjuk egy alkalmazást megír (hogy most az asztali vagy webes, tök mindegy), ami az adatbázistól bizonyos formátumban (megjelenítési formátumban) vár adatokat, és tök más formában kapja meg, mint egy másik szerveren, akkor abból adott esetben probléma lehet - mondjuk a probléma kimerül annyiban, hogy át kell állítani a formátumot úgy, ahogy mutattad, de nem biztos, hogy azonnal leesik, mi is a gond.

• #1213 Sk8erPeter nagyúr bpx #1211

  Új Válasz 2012-06-28 12:18:12 #1213

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz bpx #1211 üzenetére

  Ja oké, kösz, ezt nem ismertem.
  Szerk.: habár jobb akkor is a "default" formátumban tárolni, nem? Úgy könnyebben migrálható. Különben mindig oda kell írni ezt az ALTER-t, amit írtál.

Új hozzászólás Aktív témák