BGAFC Vendégkönyv

Σ: 1 post

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