BGAFC Vendégkönyv

Σ: 16 post

kemi (statz)

#2, Főfasz (2970)

156 | #1c50 | ^ | Idézet | Fri, 04 May 2012 19:54:20 +02

77.234.*.*

*.pool.digikabel.hu

TCH írta/wrote:
11-től felfele atom-über-hulladék-takony-moslék-okádék-ótvar-fos.

Használj Krómot, vagy TűzRókázót.

TCH (statz)

#1, Főfasz (10443)

55 | #1c51 | ^ | Idézet | Fri, 04 May 2012 20:06:01 +02

89.134.*.*

*.catv.broadband.hu

Tök mindegy miben használom, nem csak Operában fosadék.

TCH (statz)

#1, Főfasz (10443)

237 | #1c52 | ^ | Idézet | Sat, 05 May 2012 00:17:12 +02

89.134.*.*

*.catv.broadband.hu

Itt ülök a melóban bazdmeg és szeretném kifejezésre juttatni, hogy a szarákül akkora fos, hogy hihetetlen. Ugyanaz a query egyik helyen megy, másikon ÜRES errort ad vissza, se ORA-XXXXX, se semmi.

SZARÁKÜL SUKSZ!!!

TCH (statz)

#1, Főfasz (10443)

146 | #1c53 | ^ | Idézet | Sat, 05 May 2012 03:21:25 +02

89.134.*.*

*.catv.broadband.hu

kemi: Geci most esik le, hogy félreértettük egymást. Nem az Opera fos 11-től felfele, meg Opera 11-től fos a flashplugin, hanem adobífless 11-től.

TCH (statz)

#1, Főfasz (10443)

986 | #1c54 | ^ | Idézet | Sat, 05 May 2012 04:18:20 +02

89.134.*.*

*.catv.broadband.hu

Tökkirájbazmeg. Tegnap esete halynali kettőkó' kerültem agyba ágyba és hajnali hétkor már felvertek a csatornaásó munkások. Egy tizenkét órás műszak után négy órát aludni, majd lehúzni egy eddig tizennyolc órás műszakot überbrutálkirály bazmeg.
Hajnali híreinket hallják: Rohadófélben lévő döglött sündisznókkal teletömött kecskegecivedelő bálnát csempésztek be Vlagyivosztokból Nicaraguába egy dízelmeghajtású villanytraktoron.
A náza legújabb elektronikusan szabadalmaztatott biológiai fülviasszal funkcionáló jósgépe megjósolta a tegnapi időjárást és azt, hogy a hegyikecske természetes ellensége a hegyikaktusz, ami a völgyekben és a tengerfenéken lakik. Szar vers:
Kis kacsa fosik,
kurwa az anyja,
rohad a segge,
bazmeg bazmeg BAZDMEG!!!
A ZTE 6:0-ra verte az MTK-t, az LSD 8:0-ra a TDK-t, az MSTXC meg a HTZFU meg az HBO meg SS, tehát GHZTF és XZGE ami 76:32 továbbá 16:9 de csak ha X(RD?S és 743:ü3ö4 dk dféoij, meg 49 éljkdfasdf9 3 wazzegbazmeg.

TCH (statz)

#1, Főfasz (10443)

189 | #1c55 | ^ | Idézet | Sat, 05 May 2012 07:53:08 +02

89.134.*.*

*.catv.broadband.hu

\o/
Kellett ez így egy 22 órás (still counting) marathón után.

kemi (statz)

#2, Főfasz (2970)

389 | #1c56 | ^ | Idézet | Sat, 05 May 2012 08:38:50 +02

77.234.*.*

*.pool.digikabel.hu

Az ítélet értelmében betilthatják több Microsoft termék - Xbox 360 játékkonzol, Windows 7 operációs rendszer, Internet Explorer és Windows Media Player - németországi forgalmazását.

Hehe (trollface)
Amúgy azt hittem, hogy a Motorola kapcsán az Androidos perről van szó. Az is egy elég unfair dolog, hogy minden Androidos gyártónak telefononként kell perkálnia a mikrofosnak.

TCH (statz)

#1, Főfasz (10443)

360 | #1c57 | ^ | Idézet | Sat, 05 May 2012 09:29:41 +02

89.134.*.*

*.catv.broadband.hu

kemi írta/wrote:
Amúgy azt hittem, hogy a Motorola kapcsán az Androidos perről van szó.

Nem, ez egy viszontszivatás volt.

kemi írta/wrote:
Az is egy elég unfair dolog, hogy minden Androidos gyártónak telefononként kell perkálnia a mikrofosnak.

Mint minden ami mikrofos, nem fair.

TCH (statz)

#1, Főfasz (10443)

51 | #1c58 | ^ | Idézet | Sat, 05 May 2012 17:03:10 +02

89.134.*.*

*.catv.broadband.hu

Na, most végeztünk bazdmeg. Usque 32 óra. Fúbazmeg.

djpety alias "Pety"

#6, Lófasz (953)

42 | #1c59 | ^ | Idézet | Sat, 05 May 2012 22:19:04 +02

84.2.*.*

*.pool.t-online.hu

Chuck Norris végigvitte a Máriót... balra.

saxus (statz)

#9, Agyfasz (419)

1880 | #1c5a | ^ | Idézet | Sun, 06 May 2012 03:25:46 +02

81.183.*.*

*.dsl.pool.telekom.hu

kemi írta/wrote:
Na így lesznek aztán programozók helyett gányolók. Nem baj, majd a náluk okosabb compiler kioptimalizálgat.

A ganyolok nem ugy lesznek. A ganyolok ugy "lesznek", hogy az egyebkent total leszarom hozzaallasu billentyuzetet csapkodo majmot beultetik kodot lapatolni mindenfele osszebaszott, struktura nelkuli, atgondolatlan, barmifele tervezest es tudatossagot nelkulozo, try-and-error modszerrel keszult spagetti kodot anelkul, hogy tudna mit csinal. Ebbe beletartozik az is, hogy tudja, hogy a fordito/VM/interpreter mit muvel(het) azzal, ami kodot osszelapatol. (es most mindegy, hogy statikus, JITter vagy nativ kodrol/JVM/CLR/PHP interpreterrol).

TCH írta/wrote:
Te megbíznál a GCC-ben?

Es egyebkent igen hamarabb biznam ra az optimalizalast egy -O2 -re barmely random C fordito eseten, minthogy kezzel nekialljak minden mikroarchitekturara leoptimalizalni *HA NEM MUSZAJ*.

Mert amikor valamivel dolgozni akarok, nem mindenfele low level optimalizaciot akarom fejben tartani (valoszinuleg soha az eletben nem lennek kepes az osszeset fejben tartani. Szerintem az Intelnel sincs mar olyan ember, aki mindent tudna, egyszeruen tul komplexek es tul sokretuek ahhoz a mai rendszereink).

De ez olyan, hogy most minek talaljam fel a spanyol viaszt es irjam meg mondjuk ujra egy Stack<T> osztalyt? Megirtak egyszer, ki is optimalizaltak azokat, en minek irjam meg minden egyes alkalommal ujra es ujra es ujra? (Es kemi: ez nem jelenti azt, hogy ne tudnam, hogy mi az, vagy megirni sajat magamtol.) Ugyanez van a forditoval:ami automatizalhato, azt nem en akarom kezzel ujra es ujra megcsinalni. Azert van a gep es azert vannak a szoftverek, hogy a mi eletunket konnyitsek meg. Egy fordito miert ne konnyitse meg a fejleszto eletet? Elvegre is, azert van, nem?

saxus (statz)

#9, Agyfasz (419)

327 | #1c5b | ^ | Idézet | Sun, 06 May 2012 03:27:28 +02

81.183.*.*

*.dsl.pool.telekom.hu

TCH írta/wrote:
SZARÁKÜL SUKSZ!!!

Maximalisan egyet tudok erteni ezzel a kijelentesseddel. (Egyebkent nagy osszegben mernek fogadni, hogy
- vagy valami eltero nyelvi beallitas lesz a hatterben
- vagy valami felesleges whitespace karakter (miez bazdmeg, python, hogy ezen hisztizzen?)

TCH (statz)

#1, Főfasz (10443)

12974 | #1c5c | ^ | Idézet | Mon, 07 May 2012 00:31:24 +02

46.107.*.*

*.catv.pool.telekom.hu

djpety írta/wrote:
Chuck Norris végigvitte a Máriót... balra.

Jézus jár a vizen, Chuck Norris úszik a szárazföldön. :)

saxus írta/wrote:
A ganyolok nem ugy lesznek. A ganyolok ugy "lesznek", hogy az egyebkent total leszarom hozzaallasu billentyuzetet csapkodo majmot beultetik kodot lapatolni mindenfele osszebaszott, struktura nelkuli, atgondolatlan, barmifele tervezest es tudatossagot nelkulozo, try-and-error modszerrel keszult spagetti kodot anelkul, hogy tudna mit csinal. Ebbe beletartozik az is, hogy tudja, hogy a fordito/VM/interpreter mit muvel(het) azzal, ami kodot osszelapatol. (es most mindegy, hogy statikus, JITter vagy nativ kodrol/JVM/CLR/PHP interpreterrol).

Ez igaz, de azért tegyük hozzá, hogy az általad említett total leszarom hozzaallasu billentyuzetet csapkodo majmok nem C-ben, Delphiben vagy ASM-ben nyomják, hanem dzsuvában vagy cisztában/vizuálbuzikban/egyébfosnetes nyelvben. :P

saxus írta/wrote:
Es egyebkent igen hamarabb biznam ra az optimalizalast egy -O2 -re barmely random C fordito eseten, minthogy kezzel nekialljak minden mikroarchitekturara leoptimalizalni *HA NEM MUSZAJ*.

Ácsi, itt most nem arról beszélek, hogy az adott algoritmus gépi kódú implementációjának az optimalizációját bíznád rá, hanem magának az algoritmusnak a kioptimalizásáról. Értsd: az nem optimalizáció, hogy itt is, meg ott is megspórolok egy órajelet; az az optimalizáció, hogy a feladatra ír az ember egy hatékonyabb algoritmust. A fordító csak az elsőt tudja nyújtani pl. adott architektúrán van bizonyos összetettebb műveletekre is utasítás és azt használja ahelyett, hogy a BIS-ben található parancsokkal valósítaná meg.

saxus írta/wrote:
Mert amikor valamivel dolgozni akarok, nem mindenfele low level optimalizaciot akarom fejben tartani (valoszinuleg soha az eletben nem lennek kepes az osszeset fejben tartani. Szerintem az Intelnel sincs mar olyan ember, aki mindent tudna, egyszeruen tul komplexek es tul sokretuek ahhoz a mai rendszereink).

Ez igaz, de nem is kell egyszerre mindet fejben tartani, csak azt amin épp dolgozol, továbbá alapvetően olyan kódot kell írni, ami CPU szemszögből "ehetőbb".

saxus írta/wrote:
De ez olyan, hogy most minek talaljam fel a spanyol viaszt es irjam meg mondjuk ujra egy Stack<T> osztalyt? Megirtak egyszer, ki is optimalizaltak azokat, en minek irjam meg minden egyes alkalommal ujra es ujra es ujra?

Ebben is van igazság, de sajnos vannak olyan technológiák, amik annyira fosok, hogy jobb kikerülni őket és saját implementációt írni.

saxus írta/wrote:
Azert van a gep es azert vannak a szoftverek, hogy a mi eletunket konnyitsek meg. Egy fordito miert ne konnyitse meg a fejleszto eletet? Elvegre is, azert van, nem?

Ez enyhén csúsztatás; mi nem a komfort, vagy nem az intelligens cuccok ellen ágálunk, hanem a hülyebiztosítottak ellen! Nem az a baj, ha egy környezet sokat tud, hanem az a baj, ha azt hiszi, hogy többet tud a használójánál és ennek megfelelően olyan dolgokat tesz, amit nem kértem. Egy gép (program) ne cselekedjen önhatalmúlag. Magasról, vastagon, folyékonyan és jó nagy ívben leszarom, hogy vannak emberek akik ezek a hülyebiztosítások hiánya esetén katasztrófákat okoznának és ezért pakolják bele ezt a sok túlintelligens, "mindenre" felkészített védelmi mechanizmust, hogyha a hülye programozó ezt vagy azt nem csinál meg, akkor megcsinálja a program. Csakhogy én az ilyen emberek esetén nem a hülyebiztosítást választanám, hanem a balfaszok elhajtását; hiszen egyáltalán: mi a fasznak engedték őket egyáltalán gépközelbe?! Most mutogathatnék megint bilgécre, de megint csak azt mondanád, hogy már unalmas...

saxus írta/wrote:
Maximalisan egyet tudok erteni ezzel a kijelentesseddel.

Remélem ez nem szarkazmus volt, örülnék, ha végre egyetértenénk valamiben. :P

saxus írta/wrote:
(Egyebkent nagy osszegben mernek fogadni, hogy
- vagy valami eltero nyelvi beallitas lesz a hatterben
- vagy valami felesleges whitespace karakter (miez bazdmeg, python, hogy ezen hisztizzen?)

Nem tudom, lehet, hogy igazad van, de már leadtuk a projektet, így nem tudom kipróbálni. A problémáink túlnyomó részére hipergusztustalan workaroundokat voltunk kénytelenek tákolni Mcloaddal. Felsorolom mitől hullott ki a hajunk. De mielőtt kiröhögnél, most toltuk először szarákülben és meg is mondtuk a főnöknek, hogy kurwa nagy rizikót vállal azzal, hogy a mélyvízbe dob minket.

De lássuk a kecskét.

• fetch_assoc uppercase.
Mivel az elején nem volt szarákülös gép, addig elkezdtük MySQL-ben és gondoltuk majd átkonvertáljuk utána a táblákat meg a kódot is, ha összerakta a rendszergazda a szarákülös gépet. Aztán a legelső probléma amibe belefutottunk, hogy a szarákül fetch_assoc esetén a field neveket csupa nagybetűvel adja vissza! Ezt mégis ki a faszom kérte! És ha már caseconvert, akkor legalább miért nem lower?! Hogy az ember taposhassa a capslockot vagy a shiftet, ha mezőnevet használ?! Írhattuk át a mezőneveket mindenütt a PHP kódban! (Egy array_keys_to_lowercase func nem játszott, így is egy csomó CPU zabáló fasság került bele.)

• Nincs integer adattípus.
Ez igazából gondot nem okozott, csak egy fészpalmot, hogy miért kell nekem egy 8 bites integert kötelező jelleggel 128 jegy pontosságú lebegőpontoson (~160-192 bit) ábrázolni. Persze már megint hazudok, mert igenis van integer szarákülben...tárolt eljáráson belül, szarákül powa, yeah! Illetve ha a NUMBER típusnak nem adok skálát, csak precíziót, akkor elvileg integer a számunk, gyakorlatilag viszont a tárolás ugyanúgy nem.

• LIMIT vagy ekvivalens parancs hiánya.
Én értem, hogy ez nincs benne az SQL szabványban, de sajnos a szabvány írói is kifelejthetnek dolgokat, nem tilos a szabványok tetején saját kiterjesztéseket alkalmazni. LIMIT nélkül iszonyatos SQL-ben programozni, nézzétek meg ezt a "lapozó" kódot (http://stackoverflow.com/questions/241622/paging-with-oracle):

SELECT * FROM
(
    SELECT a.*, rownum r__
    FROM
    (
        SELECT * FROM ORDERS WHERE CustomerID LIKE 'A%'
        ORDER BY OrderDate DESC, ShippingDate DESC
    ) a
    WHERE rownum < ((pageNumber * pageSize) + 1 )
)
WHERE r__ >= (((pageNumber-1) * pageSize) + 1)

Miért?! MySQL-ben, SQLite-ban és PostgreSQL-ben ez:

LIMIT pageNumber * pageSize, pageSize

Vagy:

LIMIT pageSize OFFSET pageNumber * pageSize

Hát nem igaz, hogy a szarákül fejlesztői ennyire nem jönnek erre rá! WTF?!

• Autoincrement bajok.
Oké én értem, hogy a MySQL ainc az nem szabványos és szekvenciák vannak rá, ezzel semmi baj sincsen, most próbálgatom a PgSQL-t és abban fasza is. De itt csak a szopás volt. Pl. példában írták, hogy a megfelelő mezőnél

sequence.nextval()

és csá. Oké, mondom legyen így.

ora-02287: sequence number not allowed here

WTF?! Ask Google. Oké nem használhatok sequence-t selectben, group by-ban, distinct kapcsolatban, stb. stb. de bazdmeg én egy kibaszott INSERT parancsot akarok futtatni! Erre sem találtam választ.

• CLOB sorozat.
Szarákülben nincsenek TEXT típusok és a VARCHAR2 is max 4000 karakter lehet, vagyis hosszú szövegeket tárolni benne nem lehet. Vagy mégis? Hát persze, hogy de, hiszen erre való a CLOB! Vagy mégsem?

• CLOB #1.
A CLOB PHP-ban nem stringként jön vissza, hanem objektumként, amit loaddal kell betölteni. Überfasza volt, hogy a tömbökkel operáló db függvényeinkben mindenütt rakhattunk bele egy foreach-et, ami fetch_assoc/fetch_row után véigigment a tömbön és

if (is_object($row[$key]))
{
	$row[$key] = $row[$key]->load();
}

Fájna, ha egy szaros string stream lenne, mint MySQL-ben vagy PgSQL-ben? Nagyon fájna?

• CLOB #2.
A CLOB-ban nem lehet keresni LIKE paranccsal! (?!) Felejtsd el az oldal tetején lévő keresőmezőt, vagy írd meg PHP-ban foreach-el az id kigyűjtést! 10 tartalmi oldal esetén még oké, de 10000 esetén mi lesz?

• CLOB #3.
A CLOB-ot nem lehet JOIN-olni!!! (?!!!) Vagyis, ha a nyelvi adatok külön táblában vannak, ahonnan JOIN by lang_id and by primary_table_id, akkor bármi ami 4000-nél hosszabb (vagyis must be in CLOB) az nem kérhető le, vagyis ami minden tisztességes nyelvben egyetlen JOIN-os SQL kérés és voila, azt itt lehet mezőnként plusz subselectekkel, vagy újfennt PHP-s taknyo... workarounddal!

• CLOB #4.
A CLOB 8 TeraByte adatot tud tárolni. Ez egyszerűen lenyűgöző. Tényleg. Képes a legnagyobb ma létező winyó kapacitásának kétszeresét is eltárolni. Zzzigen. VISZONT ADATOT BELETÖLTENI EGYSZERRE MAX. CSAK 4000 KARAKTERT LEHET!!! KHÚÚÚÚÚÚÚÚÚÚRWAAAANYÁÁÁÁÁÁÁÁÁD!!!!!!!! Én azt hittem, ott helyben kettéfejelem az asztalt! Ilyen nincs bazdmeg! Egy ultragány workaround volt helyette, amit csak INSERT után lehetett futtatni; az ember beszúrta a sort mint egy normális DB nyelvben - csak üresen hagyta a CLOB mezőt. Utána lefutott egy ciklus ami annyiszor UPDATE, ahányszor 4000 karakter volt a beszúrandó adat... Kb. ez:

function store_text_in_CLOB($table, $field, $text, $idn, $idv)
{
	$l = strlen($text);
	for ($i = 0; $i < $l; $i += 4000)
	{
		query("UPDATE $table SET $field = $field || '".substr($text, $i, 4000)."' WHERE $idn = '$idv'");
	}
}

• CLOB Σ.
Persze mindez csak szemét csúsztatás, hiszen minek kellene ilyen fasságokkal foglalkozni, kit érdekel, hogy ezek nincsenek se PgSQL-ben, se MySQL-ben, se SQLite-ban; hiszen itt vannak nekünk a tárolt eljárások! A tárolt eljárások segítségével kedves programozó, írhatsz Te is iszonyatosan bonyolult és konvulens lekérési eljárásokat, miknek segítségével a CLOB-ot 4000 byte méretű darabonként VARCHAR2-be konvertálhatod...egészen 32000 byte méretig bezárólag!
http://oscomp.hu/depot/uristen_bazmeg.jpg
Most inkább nem kísérleteznék azzal, hogy olyan SQL eljárásokat írok, ami többszörösen egymásba ágyazott subselectek végtelen sorozatával és konkatenációk egész hadseregével lehetővé teszi azt, hogy helyettesítsem a LIKE vagy a JOIN parancsot, inkább beismerem, hogy nem tudok ilyet, nem megy ez nekem, leülök elégtelennel és elmegyek kapálni...vagy használok PgSQL-t, vagy MySQL-t, a szarákül meg szopjon le!

• Karakterkódolás és entitások.
Hogy a karakterkódolást képtelenek voltunk beállítani és mindig hieroglifák jöttek vissza az ékezetek helyén az egy dolog. Viszont mivel ezt nem sikerült szolválni, így workaround gyanánt HTML entitássá alakítottuk az ékezeteket és úgy tettük be a DB-be. Viszont lekéréskor ezek egyszerűen átalakultak ékezet nélküli karakterré! Úgyhogy kénytelenek voltunk HTML entitás helyett befelemenetelkor saját "entitássá" alakítani (pl. ó = __o__, ö = _*o*_, ő = **o**) és kifelemenetelkor meg vissza. Fuck yeah!

• Tisztességes kezelőfelület hiánya.
Többet is nyomtak a neten. Mind fos volt. A szarákül sajátja pláne.
Szerencsére az Adminer nevű univerzális SQL csodatool a segítségünkre sietett. Jakub Vrana Bůh vám žehnej! És a lófasszopó büdös kurwa anyja szarszeplős picsáját a szarákülnek.

• Rejtélyes csakazértseműködök megdöglések.
Amik aztán vagy meggyógyultak, vagy nem, vagy kódátíráskor tűntek el. Had no idea, de amit írtál - hogy még a whitespace-eken is beszarik ez a hulladék foskupac - nem jutott az eszünkbe, szóval lehet, hogy fején találtad a szarva közt a tőgyit.

• Értelmetlen és értéktelen hibaüzenetek.
Pl.: tábla létrehozásakor bármit írunk be DEFAULT kulcsszó elé, akkor ORA-00907: missing right parenthesis. Miféle zárójel, a kurwa anyád?

• Nincs üres stringre lehetőség. (!!!)
Ez a balfasz "adatbázismotor" nem tud üres stringet kezelni, hanem NULL-t használ helyette, amivel nem lehet komparálni. Szopjál paraszt, mire rájössz.

(Utólag még két röhejentry-t hozzáadtam.)

Hát ennyit tudtam összeszedni emlékezetből. Én nem tagadom, hogy első próbálkozás lévén kurwa sokat összebénáztunk és lehet, hogy az itt felsorolt fasságokra van épeszű megoldás is, de csak a guglira támaszkodhattunk. De azért azt leszögezném, hogy a MySQL-el sosem voltak ilyen gondjaink és most nekem a PgSQL-al való ismerkedés közben is csak pozitív tapasztalataim vannak, a szarákült meg csak szapulni tudom.

U.I.: Mcload szerint ilyen fost véletlenül nem, csak szándékosan lehet írni, ezt készakarva basszák így el, hogy az alapfunkciók hiányát pótló, kötelező jelleggel megírandó tárolt eljárások mennyisége és komplexsége elrettentsen mindenkit attól, hogy bepróbálkozzanak vele és inkább megvegyék az überdrága, seggkinyaló fejlesztőeszközöket...

saxus (statz)

#9, Agyfasz (419)

6108 | #1c5d | ^ | Idézet | Mon, 07 May 2012 03:28:35 +02

81.183.*.*

*.dsl.pool.telekom.hu

TCH írta/wrote:
Ez igaz, de azért tegyük hozzá, hogy az általad említett total leszarom hozzaallasu billentyuzetet csapkodo majmok nem C-ben, Delphiben vagy ASM-ben nyomják, hanem dzsuvában vagy cisztában/vizuálbuzikban/egyébfosnetes nyelvben. :P

Sajnos kodolnak azok mindenben, ami mainstream. C-ben, Pythonban, Perlben, PHP-ban, C#-ban, JS-ben, Java-ban, stb. ASM-ben azert nem, mert nincs ra igeny ;)

TCH írta/wrote:
hanem magának az algoritmusnak a kioptimalizásáról.

Akkor kurvajol elbeszeltunk egymas mellett. Egy imperativ nyelvben nincs az az optimalizalo, ami megment teged attol, hogy szar adatszerkezetet, algoritmust hasznalsz. De ezt szerintem kiscsillioszor elmondtam: attol, hogy rabizzunk a gepre dolgokat, attol meg tudni kell, hogy mi folyik a felszin alatt.

TCH írta/wrote:
adott architektúrán van bizonyos összetettebb műveletekre is utasítás és azt használja ahelyett

Mondjuk ez tipikusan az az optimalizacio, ami sok esetben, pont ugyanaz a kategoria, hogy eljenek a szuperskalar procik, dolgozzon a compiler. (Nem veletlen, hogy az MSVC++-ban es a GCC-ben is rendszeresen gyurnak az ujabb SSE utasitasokra.)

TCH írta/wrote:
Remélem ez nem szarkazmus volt

Nem az volt. Jo, azt elismerem, hogy megfelelo vason (aranyarban) megfelelo gardaval (+ aranyaras supporttal) iszonyu brutalis teljesitmenyt ki lehet sajtolni a tobbihez kepest, de ha epp nem egy penzintezetet kell megepiteni, ahova azert az ember megse rakhat MySQL-t meg PostgreSQL-t, akkor isten ments, hogy egyaltalan bottal is piszkalni merjem azt a szemetbanyat.

TCH írta/wrote:
a szarákül fetch_assoc esetén a field neveket csupa nagybetűvel adja vissza!

Hiaba na, nosztalgikus azert, hogy a PDP-7/11 es VAX-os idokbol mik nem maradtak rank ;)

TCH írta/wrote:
Hát nem igaz, hogy a szarákül fejlesztői ennyire nem jönnek erre rá! WTF?!

Nos, ennek okat, megintcsak a tortenelem konyvekben kell keresni. A "nagy" RDBMS-eket (Oracle, IBM DB2, meg ilyenek, valamint ujabban az MSSQL is kuszik azert szepen felfele) alapvetoen tranzakciok feldolgozasara terveztek. Nem veletlen, hogy rengeteg bankban vagy uzleti kozegben foleg Oracle, kisebbreszt DB2 es mas hasonlo rendszerek futnak. Az OLTP mellett a masik jelentos felhasznalasi teruletuk ezeknek meg az OLAP. Ezeknel szimplan nem volt igeny az OFFSET -re, ha limitalni kellett a visszaadando sorok szamat, akkor meg volt ra valami egyszeru moka (rownum, SELECT TOP x, stb.)

Ezt a vizet kavarta meg a web fejlodese, ahol ugye jellemzoen rovid listakra tagoljuk a hosszuakat, igy jott meg az igeny az OFFSET-re. A MySQL (egyebkent jo uzleti erzekkel) meg pont a webes piacokat akarta betomni. No, ezert van a "kicsikben" LIMIT...OFFSET, mig a nagyokban csak ilyen workaroundok.

(Btw., csak nem allami megrendeles volt, hogy Oracle? :) Baaar, akkor nem PHP lenne, ott inkabb a Java-t preferaljak RHEL alapokon.)

TCH írta/wrote:
sequence.nextval()

Az hotzicher, hogy nem ilyen a szintaxisa. nextval("sequencename") esetleg. (Es szerintem default erteke is lehet egy mezonek, mint pg-ben.)

TCH írta/wrote:
ora-02287: sequence number not allowed here

Johat, az ora-XXXX meg a "sokatmondo" hibauzenetei. Nekem a kedvencem, hogy pl. egy CREATE TABLE -ban nem lehet ures sor.

TCH írta/wrote:
A CLOB-ot nem lehet JOIN-olni!!! (?!!!) Vagyis, ha a nyelvi adatok külön táblában vannak, ahonnan JOIN by lang_id and by primary_table_id, akkor bármi ami 4000-nél hosszabb (vagyis must be in CLOB) az nem kérhető le, vagyis ami minden tisztességes nyelvben egyetlen JOIN-os SQL kérés és voila, azt itt lehet mezőnként plusz subselectekkel, vagy újfennt PHP-s taknyo... workarounddal!

Ezt most nem ertem. JOIN feltetelben gyakorlatilag TEXT tipusu mezo alapjan akarsz joinolni? Az azon kivul, hogy agyfasz, mas rendszerben sem lehetseges, mivel csak olyan mezo alapjan tudsz joinolni, ami amugy indexelheto. De kulonben is, ki a halal fasza akar 4000 karakteres stringeket hasznalni kulcsnak?

Mindegy, nekem ez az egesz zavaros. (Ugyeeee nem megint valami olyat talaltal ki, mint anno, amikor egy 256 elemu stringben akartad megoldani a kategoriakat, mert nem akartal kapcsolotablat hasznalni?)

TCH írta/wrote:
képtelenek voltunk

TCH írta/wrote:
Képes a legnagyobb ma létező winyó kapacitásának kétszeresét is eltárolni.

Oracle ala jellemzoen nem vinyot, de meg csak nem is gepen beluli RAID tombot szokas rakni, hanem mondjuk SAN-t. Egy masszivabb disk doboz megkuldve nagyobb diskekkel, azert mar igenigensokszaz tera is lehet ;)

TCH írta/wrote:
hiszen itt vannak nekünk a tárolt eljárások!

Mondjuk azok total masra vannak. A "regi" modell az, hogy barmolod be az uzleti logikat az adatbazisba (mi is tettuk egy csomot a BC-nel, ugye..), viszont ma mar inkabb tobbretegu alkalmazasban oldjak meg ezt nagyon-nagyon-nagyon sok ok miatt (kezdve a skalazodastol a tesztelhetosegig bezarolag.)

TCH írta/wrote:
Hogy a karakterkódolást képtelenek voltunk beállítani

Azert ugye nem gondolod komolyan, hogy lehetetlen beallitani az Oracleben ezt es mindenki ilyen ganyolast alkalmaz ra? :D

saxus írta/wrote:
hogy bepróbálkozzanak vele és inkább megvegyék az überdrága, seggkinyaló fejlesztőeszközöket...

Egyebkent, mivelhogy Oraclerol van szo, amely kozismerten a leglehuzosabb ceg ilyen szempontbol... Nos igen, epitenek igencsak a support bevetelekre ;) RHEL-hez sem veletlen kezdtek el supportot nyujtani. (Na meg Oracle Unbreakable Linux sem veletlen teremtmeny). Mondjuk a RHEL support az eleg logikus lepes volt, mert ugy is arra volt certifikalva altalaban az Ora, tudast begyujtottek hozza, akkor meg miert ne...?

kemi (statz)

#2, Főfasz (2970)

474 | #1c5e | ^ | Idézet | Mon, 07 May 2012 07:51:27 +02

94.21.*.*

*.pool.digikabel.hu

TCH írta/wrote:
U.I.: Mcload szerint ilyen fost véletlenül nem, csak szándékosan lehet írni, ezt készakarva basszák így el, hogy az alapfunkciók hiányát pótló, kötelező jelleggel megírandó tárolt eljárások mennyisége és komplexsége elrettentsen mindenkit attól, hogy bepróbálkozzanak vele és inkább megvegyék az überdrága, seggkinyaló fejlesztőeszközöket...

Azok után, hogy a Sunt szétkúrták, el tudom képzelni. Ritka szemét egy cég.

saxus (statz)

#9, Agyfasz (419)

847 | #1c5f | ^ | Idézet | Mon, 07 May 2012 08:50:01 +02

212.51.*.*

*.westel900.net

Szet nem kurtak a Sun-t, csak racionalizaltak :)

Valljuk be oszinten: a SUN tul sok fele forgacsolta az erejet, ha igy folytatta volna, 10 even belul belealltvolna a foldbe. Egyedul amiert igazankar az a SUN x86 vasak, onallo arusitasa, mert nem voltak rosszak. Bar mondjuk van alternativa boven, akar meg joval olcsobban. Jo, az OpenStoragenak nemannyira. Az OpenSolaris meg olyan, hogy nem lenne rossz,de hat nem jott letre igazan eros kozosseg kore.

Egyebkent logikus volt h. pont az Oracle vegye meg, leven sok Oracle futott SOlarison v RHEL alatt SUN vason allami v bankszektorban.

Az viszont h Schwarczi azzal arulta a SUN-t, hogy a Java kapcsan nekimenjen a Googlenak, az mondjuk eleg gyokerseg (=> szoval nem kell megideologizalni egyik ceget se), de azt eddig is tudni lehetett, h a SUN-ban az egyetlen ertek a Java + a szabadalmak.