BGAFC Vendégkönyv

Σ: 14 post

kemi (statz)

#2, Főfasz (2970)

73 | #26a3 | ^ | Idézet | Wed, 17 Jul 2013 08:30:43 +02

188.143.*.*

*.pool.digikabel.hu

SQL-ben mi a különbség a VARCHAR meg a VARCHAR2 között?

TCH (statz)

#1, Főfasz (10443)

393 | #26a4 | ^ | Idézet | Wed, 17 Jul 2013 11:56:00 +02

78.92.*.*

*.catv.pool.telekom.hu

Oké Prometheus, akkor elvileg, ha minden oké, akkor 26.-a?

VARCHAR2??? Az csak orákülben van! Menekülj kemi, menekülj!
Amúgy semmi különbség nincsen, a simát kompatibilitási okokból megtartották, majd a jövőben cserélik: http://ss64.com/ora/syntax-datatypes.html (Igen, ennek így semmi értelme sincs, hogy a régit dobják és írják át, dehát mit várunk, szarákül bazdmeg.)

Prometheus (statz)

#3, Főfasz (1824)

111 | #26a5 | ^ | Idézet | Wed, 17 Jul 2013 21:49:48 +02

80.99.*.*

*.catv.broadband.hu

Huhú, király, jupí!
Akkor miccólnátok ahhoz, ha Kemiéknél kockulnánk délután, aztán onnan mennénk lasertagezni?

TCH (statz)

#1, Főfasz (10443)

107 | #26a6 | ^ | Idézet | Wed, 17 Jul 2013 22:11:53 +02

78.92.*.*

*.catv.pool.telekom.hu

Oké, elméletileg tudok menni, gyakorlatilag majd kiderül, hogy melózunk-e idehaza aznap. (Elvileg épp nem.)

Prometheus (statz)

#3, Főfasz (1824)

74 | #26a7 | ^ | Idézet | Thu, 18 Jul 2013 07:41:57 +02

80.99.*.*

*.catv.broadband.hu

Meló este 20-tól?
THC, ez a kifogás randi ellen jó, barátoknál kevésbé. :P

TCH (statz)

#1, Főfasz (10443)

408 | #26a8 | ^ | Idézet | Thu, 18 Jul 2013 14:30:56 +02

78.92.*.*

*.catv.pool.telekom.hu

@Prometheus:
Meló este 20-tól?

A munkahelyi meló nekem teljesen időfüggetlen, van hogy hajnali háromkor megy. Az itthoni meg a ház befejező fázisa, azt odabennt csináljuk, az akár este is mehet villanyfénynél. De mondom, úgy néz ki, hogy aznap pont rá fogok érni.

@Prometheus:
THC, ez a kifogás randi ellen jó, barátoknál kevésbé. :P

Ha kifogást akarok, akkor benyögöm, hogy elütött egy kecske. :]

TCH (statz)

#1, Főfasz (10443)

1477 | #26a9 | ^ | Idézet | Thu, 18 Jul 2013 22:42:13 +02

78.92.*.*

*.catv.pool.telekom.hu

Na ERRE adjon valami szarákülguru választ, hogy ez hogy lehetséges?!

select count(*) from cc_codes

COUNT(*)
14135600

select count(*) from cc_codes where answer = ''

COUNT(*)
0

select count(*) from cc_codes where answer <> ''

COUNT(*)
0

Értsd van 14135600 db kód ebben a kurwa táblában. Van egy "answer" mező, ami alapján szűrni szeretnék. És akár üresre, akár nem üresre szűrök rá, az eredmény nulla sor!
Gyakorlatilag az eredmény szerint nincs se olyan sor, ahol ennek a mezőnek van tartalma, se olyan, ahol nincs tartalma, márpedig ez csak akkor lenne lehetséges, ha üres lenne a tábla, de amint az első lekérdezésben látszik, nem az!

Hovatovább, ha lekérem magukat a sorokat, akkor látszik, hogy csomó helyen van tartalma annak a szaros mezőnek!

WTFF?!

Sz*rk: Megfejtettem.

select count(*) from cc_codes where answer is not null;

COUNT(*)
14135500

Ez a nagyszerű, zseniális és csodálatos szarákül bazdmeg!!! Ha NULL a mező beállítása, akkor hiába is próbálsz üres sztringre szűrni, mert leszarja! Ha nincs a mezőnek tartalma, akkor még oké volna, de ha van, akkor üres sztringre működnie kéne!
Komolyan bazdmeg, ilyen nincs, ennyire nem lehet szar valami, ezt még az MSSQL is körberöhögi bazdmeg, ez egyszer így, egyszer meg úgy értelmezi amit mond neki az ember és aztán dolgozz vele, meg garantálj működést!

HALÁL A SZARÁKÜLRE!!!

TCH (statz)

#1, Főfasz (10443)

1867 | #26aa | ^ | Idézet | Fri, 19 Jul 2013 00:45:31 +02

78.92.*.*

*.catv.pool.telekom.hu

Bazdmeg, nézem a hávéesvét, látok egy ilyen linket: Ăzleti oldalon is erĹsĂśdik a platform (SIC!)
Mondom, mijezazelbaszottfos?
Rábökök. Egy mikrofosos portál. XDDDDDD
Még a linkben is el voltak baszva az ékezetes betűk. (Sőt a cím is, mert kimaradt egy 'a' betű is.)
http://<xenz0rD>.hu/2013/07/18/zleti-oldalon-er-s-dik-platform

Hát no comment. Ha így erősödik a winfosnyóc PLATFORM, akkor nyugodtan alhatunk. XD

Viszont egy érdekes linket fogtam benne: http://www.sg.hu/cikkek/98667/komoly_valtozasokkal_jon_a_windows_phone_9
Hát ez kész. A winfosnyócat pont nem kéne nulláról újraírni, mert ez nem belül szar (legalábbis nem szarabb, mint az ikszpé vagy a hét), hanem kívül: a felülete egy nagy fos. Ha most újraírják nulláról, akkor megint egy kiforratlan kódot fognak kapni és dettó ugyanúgy fos lesz belül, mint a wista, csak ez még a nyolcas felületét is megörökli és kívül is szar lesz!

Sötét gyökér mikorfos, ahelyett, hogy hallgatnának a júzerekre és kikapcsolnák a gecibe azt a sok fost, ami miatt a nyócast mindenki utálja, inkább újraírják... Hát no comment.

Footnote: Igen, látom, hogy ez nem winfoskilenc, hanem winfosfónkilenc, de azt is írják a cikkben, hogy a Microsoft már létre is hozta a WP9 fejlesztéséért felelős munkacsoportot, amelynek feladata az első körben egy olyan operációs rendszer megtervezése lesz, amely közelebb hozza egymáshoz az okostelefonok és a tábla PC-k kategóriáját, mégpedig a jelenlegitől eltérő kezelőfelülettel.
Na éppen ez az, amibe most is belebuktak! PC != Mobil! Na most, képzeljétek el mi lesz, ha a winfosnyolc külsejének használhatóságát kombináljuk a wista belsejének a használhatóságával. Szerintem minden idők legszarabb, leg-okádékabb winfosa lesz.

Persze ez nekünk csak jó, ha a mikrofos megint tökönszúrja saját magát. :)

TCH (statz)

#1, Főfasz (10443)

253 | #26ab | ^ | Idézet | Fri, 19 Jul 2013 13:11:25 +02

78.92.*.*

*.catv.pool.telekom.hu

HÁ-HÁ!

Vándékkönyv v3.19.6:
• A BBCode helper cellái és szövegei kaptak egy kis nullás paddingot, hogy 1024 szélesen is jobban elférjen az egész.

saxus (statz)

#9, Agyfasz (419)

1017 | #26ac | ^ | Idézet | Fri, 19 Jul 2013 19:39:47 +02

86.101.*.*

*.business.broadband.hu

"SQL-ben mi a különbség a VARCHAR meg a VARCHAR2 között?"

:)) Az, hogy rossz RDBMS-t használsz... Amúgy gyakorlatilag semmi (immáron 20+ éve), de nekem ezt még valaki úgy magyarázta, hogy "használja mindenki a VARCHAR2-t, mert fenntartják a jogot arra, hogy módosulni fog a VARCHAR" (rotfl)... Szerintem meg csak arról van szó, hogy az Oracle meg akarta nehezíteni a migrációt a szarjáról :)

"Ez a nagyszerű, zseniális és csodálatos szarákül bazdmeg!!! Ha NULL a mező beállítása, akkor hiába is próbálsz üres sztringre szűrni, mert leszarja!"

Ez nem szarákül, hanem így van az SQL standardban. Akármilyen összehasonlítást, műveletet végzel NULL-al, annak false/NULL-nak kell lennie.

Még a NULL-t sem tudsz NULL-al összehasonlítani.

> select case when null = null then 'T' else 'F' end
"F"

(És erre minden RDBMS-nek F-et kell visszaadnia.). Ez van, SQL-ben a NULL nem egy speciális érték (mint pl. a C NULL), hanem egy kb. egy "állapot".

TCH (statz)

#1, Főfasz (10443)

5477 | #26ad | ^ | Idézet | Sat, 20 Jul 2013 00:01:32 +02

78.92.*.*

*.catv.pool.telekom.hu

@saxus:
:)) Az, hogy rossz RDBMS-t használsz...

Kurwa nagy +1.

@saxus:
(rotfl)...

Kurwa nagy +1.

@saxus:
Szerintem meg csak arról van szó, hogy az Oracle meg akarta nehezíteni a migrációt a szarjáról :)

Kurwa nagy +1.

@saxus:
Ez nem szarákül, hanem így van az SQL standardban. Akármilyen összehasonlítást, műveletet végzel NULL-al, annak false/NULL-nak kell lennie.

Még a NULL-t sem tudsz NULL-al összehasonlítani.

> select case when null = null then 'T' else 'F' end
"F"

(És erre minden RDBMS-nek F-et kell visszaadnia.). Ez van, SQL-ben a NULL nem egy speciális érték (mint pl. a C NULL), hanem egy kb. egy "állapot".

C-C-C-COMBO BREAKER!!!
Félreértetted amit mondtam. Nem NULL tartalmú mezőkkel végeztem műveletet, ha megnézed mégegyszer a kapott eredményeket

select count(*) from cc_codes;

COUNT(*)
14135600

select count(*) from cc_codes where answer is not null;

COUNT(*)
14135500

akkor látod, hogy a mezők java nem volt NULL, tehát én nem NULL-al végeztem összehasonlítást, hanem érvényes sztringekkel. Azt tudom, hogy NULL-al nem lehet komparálni, tehát NULL állapotú mező komparálása mindig hamisat ad vissza, de én nem is ezt csináltam. A mező beállítása volt, hogy lehet NULL (nem a mi hibánk!) minek következtében a szarákül egyfelől az INSERT kérésekben található összes üres sztringet NULL-ként szúrta be, másfelől pedig a tartalommal bíró mezőket sem volt képes összehasonlítani az üres stringgel, gyakorlatilag az orákül szerint ('blablabla' != '') hamisat ad vissza, márpedig ha a mező tartalma nem egy üres sztring, akkor a select count(*) from cc_codes where answer <> ''; ugyanúgy vissza kéne, hogy adja a sort, kivéve persze, ha a mező NULL - ahogy te is mondtad - de a mező nem volt NULL.

Ez konkrétan azt jelenti, hogy az oracle szerint ('' == NULL) && (NULL != ''), lévén az üres sztringet nem csak a beszúrásnál, de a keresésnél is NULL-nak vette, a NULL értékeket, meg nem vette üres sztringnek, mert ha a kettő közül bármelyiket nem csinálta volna, akkor adott volna vissza sorokat, ergo EGYSZERRE csinálja a kettőt, nála az üres sztring az NULL, de a NULL nem üres sztring! Mijezmárbazdmeg?!

A select count(*) from cc_codes where answer <> ''; odabent így értelmeződött: select count(*) from cc_codes where answer <> NULL; ami naná, hogy hamisat ad vissza, de bazdmeg, én nem NULL-ra kerestem, hanem üres sztringre! A szarákül nem az általad leírt SQL standard szerint dolgozik, a mellékelt példa bizonyítja, hogy simán megfelelteti az üres sztringet a NULL-nak, ami viszont epic fail, mert INSERT INTO pina (faszom) VALUES (NULL); baromira nem ugyanaz, mint INSERT INTO pina (faszom) VALUES (''); (ld. mindjárt a PgSQL-es példámban), de még nagyobb fail, hogy aztán visszafele már nem csinálja! A szarákül konkrétan magasról leszarja az SQL szabványt! Egyszer így, egyszer meg úgy működik, aztán dolgozz vele, ha tudsz!
A bizonyítás kedvéért (bár az axióma, hogy az orákül fos, tehát nem szorul bizonyításra): íme PgSQL-ben NULL alapbeállítású mező, tartalommal, üres sztringgel és NULL értékkel:

CREATE TABLE "pina" (
  "faszom" character varying(15) NULL
); -- 0.003 s

INSERT INTO "pina" ("faszom") VALUES ('shgfdhsfdh'); -- 0.002 s
INSERT INTO "pina" ("faszom") VALUES ('32trtfj'); -- 0.002 s
INSERT INTO "pina" ("faszom") VALUES (NULL); -- 0.001 s
INSERT INTO "pina" ("faszom") VALUES (''); -- 0.002 s

select count(*) from pina where faszom <> '';

count
2
-- ahogyan az SQL szabvanynak megfelel
-- a ket tartalommal biro sor igen, az ures stringes sor nem es a NULL sem, mert azt nem lehet komparalni
-- szarakulben ez NULLA sort adott vissza!

select count(*) from pina where faszom = '';

count
1
-- ez is megfelel az SQL szabvanynak
-- az ures stringes sor igen, a ket tartalommal biro sor nem es a NULL sem, mert azt nem lehet komparalni
-- szarakulben EZ IS nulla sort adott vissza!

select count(*) from pina where faszom is null;

count
1
-- igy van, egy NULL sor van! SQL standard-nek megfelel.
-- igaz, ez mar szarakulben is jo volt

select count(*) from pina where faszom is not null;

count
3
-- es ez is jo, mert egy NULL sor van, harom nem az. SQL standard pipa.

QED. A szarákül rohadtul nem az SQL szabványnak megfelelően csinálta, amit csinált. A PgSQL igen. PostgreSQL (& Adminer :) ) gigarulez, szarákül gigasux.
Egyszerűen szar a szarákül. Mit várunk attól a ratyi motortól, ami még INSERT-ben sem enged szekvenciákat használni, meg 4000 karakterenként akar feltölteni egy 128 TB-s mezőt, arról meg ne is beszéljünk, hogy ha egy NOT NULL mezőnek alapértéket akar adni az ember, akkor szerinte hiányzik egy zárójel...

Vándékkönyv v3.20.0:
• PREVIEW!!! \o/
• Innentől rákérdez az elküld gomb, hogy elküldöd-e, hogyha az ember véletlen arra nyomna a preview helyett, oszt elmenne szarul a post.

TCH (statz)

#1, Főfasz (10443)

1094 | #26ae | ^ | Idézet | Sat, 20 Jul 2013 21:50:23 +02

78.92.*.*

*.catv.pool.telekom.hu

Ugye számítástechnikus?
(Ez a szó hogy eltűnt a köztudatból...)

Egyfelől: há-há megint, másfelől meg meg kell, hogy mondjam: a Yahoo mostani oldala egy borzasztó nagy rakás fos, bekapcsolt dzsuvaszkripttel egyszerűen nézhetetlenül lassú...

Azonfelül:

Hogy is volt ez saxus? Linuxon az a sok függőségi probléma, bezzeg windózon, az az igazi?

Aztán: Volt nemrég a hupon valami minibotrány egy mikrofosos/hávéesvés felmérés kapcsán, ami nem a felmérésről szólt, hanem arról, hogy az embereket beazonosítsák.
Én is kitöltöttem, itt van pár válaszom:

TCH (statz)

#1, Főfasz (10443)

358 | #26af | ^ | Idézet | Sun, 21 Jul 2013 20:06:08 +02

78.92.*.*

*.catv.pool.telekom.hu

http://hup.hu/cikkek/20130721/lxde-qt_hivatalosan_egyesul_a_razor-qt_es_az_lxde_projekt
Na végre! Végre valami értelmes dolog! Razor Qt pozitív volt, hogy Qt-s, negatív, hogy használhatatlan, LXDE pozitív, hogy használható, negatív, hogy GTK-s. Így most lesz még egy használható Qt felület! Meg ha a KlyDE is fasza lesz, akkor lesz itt még bazmeg!

TCH (statz)

#1, Főfasz (10443)

485 | #26b0 | ^ | Idézet | Sun, 21 Jul 2013 23:09:08 +02

78.92.*.*

*.catv.pool.telekom.hu

Bizonyíték arra, hogy a mikipédiát a mikiszoft pénzeli:
• A Console Wars cikket törölték, mert egyértelműen kiviláglott belőle, hogy a a sima suxbox óriási fiaskó volt, a második meg mindenkinél megdöglött és ráadásul utolsó lett az eladásokban.
• A List of best-selling game consoles cikkből törölték a Sony által hivatalosan kiadott 2012-es jelentést, ezzel lecsalták a PS3 eladásait (78.4 vs 77.2 helyett 75 vs 77.2) és lezárták a cikket!

Gázkamrába a mikipédiával.