> >és ez sajnos már minimális méretu problémá knál is szóba kerül - pl egy
> >szimpla web-es adatkarbantartás is legalább fél tucat t áblánál kezdodik,
> >ha tiszta, átgondolt adatbázis modellrol van szó.
>Fel tucat tablahoz meg szvsz. boven nem kell egy adatbazis motor.

Itt vagyok konkretan en. Most csinaltunk egy ujsagnak a webes kiadasat (nem
tudom hogy kell szepen mondani), arrol volna szo, hogy amikor kiadjak az
ujsag legujabb szamat, akkor az ujsagiro (vagy az adminisztrator) hozzaadja
a bazishoz a legujabb cikkeket, megadja a kepeket, es minden mukodik.
Adatbazishoz MySQL-t hasznalunk. Es van 2 db (igen, ketto) tablank. De
mivel _nem_ tudjuk maskepp megcsinalni, PHPhez is alig ertunk, a megbizo
ceg pedig nem bovelkedik penzben, ezert meg se fordult a fejunkben, hogy
esetleg maskepp is lehetne. Nem kell rogton letamadnotok, hogy az ilyen
buta ember ne csinaljon webes adatbazis kezelest, de mi meg csak tanulok
vagyunk, most kezdtuk az ilyen dolgokat... Ha nekem gyorsan kell valami, es
nem fontos annyira a gyorsasag, akkor miert ne hasznaljam ki az ilyen
osszedrotozos lehetosegeket? Persze majd ha jon egy ceg, akinek tenyleg
kelleni fog komoly adatbazis-kezeles, es meg is fizeti azt, akkor persze
hogy elgondolkozunk rajta...


> >A tapasztalat egy igen drága jószág, és ha lehet, innen térjünk át a
> >költség al apú vizsgálatra.
>Terjunk! Egy webes, fel tucat tablaval rendelkezo adatbazishoz kell -e
>berelni olyan tarhelyet, ahol meg kell fizetni az adatbazis szerver
>hozzaferest, vagy feltehetem barhova ahol Perl v. PHP van (a ketto kozul
>valamelyik felar nelkul rendelkezesre all). Sot a megrendelo a
>szolgaltatonak fizet v. nekem fizeti azt a penzt, amiert megirtam
>hordozhatora az egeszet (ez ugye nem mindegy).

Ez persze igaz

 >Vagyis semmi kivetnivaló
> >nincs a jó Delphi programozóban, ha elég hatékony leké rdezo programot
> >csinál. A magasszintu eszköz nem hordozza magában azt, hogy rosszabb
> >program születik - azt bizony a programozó trehánysága hozza. Sot,
> >általában üzembiztosabb program az eredmény (lásd C - C++). Lehet, hogy az
> >a bajod, hogy úgymond boldog-boldogtalan képes összedrótozni egy
> >nyilvántartó programot, és nem marad meg a szakma olyan
> >arisztokratikusnak, titokzatosnak, mint volt régebben? ;)
>Na igen azt hiszem az egesz vita forrasa ebben gyokeredzik!
>Az egyik problema a Delphi-vel es minden rokonaval pont az, hogy 10 honapos
>tanfolyamrol kiesett ifjoncok Delphi programozonak hiszik magukat. En
>szemely szerint kb. 13-14 eve programozgatok, de nem vallom magam
>programozonak a szo igazi ertelmeben, mert ugy erzem, hogy bovan van mit meg
>ahhoz tanulnom (ugya az okos azt tudja, hogy mit nem tud :-). Ez nem
>arisztokratikussag es titokzatosag, bar ugy tunhet egy kivulallonak ez csak
>azert van, mert ez a szakma sokkal atfogobb es komplexebb, minthogy par
>honap (vagy akar ev) alatt valaki profiva valhasson benne (nezd meg pl. az
>igazan profi, megfizetett programozokat, szinte mind 40 folott jarnak).
>Ja es amin latszik a tapasztalatlansagod: nincs olyan, hogy Delphi
>programozo, nincs olyan, hogy Java programozo, nincs olyan, hogy Perl
>programozo. A programozas szemleletet, logikat, egyfajta gondolkodasmodot
>jelent. Es, ha az ember tud programozni, akkor megtanulja alapusan a
>kivalasztott nyelv szintaktikajat es abban programoz. Es szepen evek alatt
>akar tobb nyelvet is. Es ha ez a programozo ir egy algoritmust, akkor neki
>tokmindegy, hogy milyen nyelven kodolja.

Ez igy mind szep es jo, dehat azert a vilagnak szuksege a van az
"ifjoncokra". Mert:
1) ezekbol lesznek majd a jol megfizetett programozok
2) egyes cegek nem kepesek megfizetni a profi munkat, de azert kellene egy
s mas dolog, amit a fiatalok is meg tudnak irni - sokkal olcsobban, es az
ar neha fontosabb, mint a hatekonysag
3) valahol kezdeni kell!

Az persze nem jo, ha az ujoncok azt hiszik magukrol, hogy mindent tudnak...

>(Sajat agressziv velemenyem egybkent, hogy delphi-ben lekerdezoprogramot
>irni nem programozas, hanem egyszeru szoftverkezeles :-(

Ez szerintem is igaz, epp ezert miert fizetne meg egy ceg egy profit 100
DM-s oraberrel, mikor egy ujonc is megcsinalja tized annyi penzert?

Ezzel nem azt akarom mondani, hogy mindenkinek a felautomata programokat
kellene hasznalni, hanem azt, hogy mindenhol azt kell hasznalni, ami a
legoptimalisabb. Ha raketa celzorendszert fejlesztunk, arra ott az ASM,
Fortran, Eiffel, stb, ha meg kiskaliberu dolgokat, arra ott van a Pascal,
C, stb. A Delphi a gyors fejlesztesre jatszik, neha a hatekonysag (hogy
mondjak magyarul azt, hogy efficient?) szamlajara. Kulonben miert lenne ott
a RAD (Rapid Application Development) jelzes?

elnezest kerek mindazoktol, akik sertve erzik magukat, de szerintem a masik
felerol is meg kell nezni a dolgokat...

Gergo

, Fri Mar  2 10:23:07 CET 2001 CODER #1105:

> >Hmmm... hát nem hinném, hogy a többség egy abszolút profi,
> Ha nem profi, akkor miert fog hozza. Szerintem van eleg profi, akiknek a nem
> profik csak szukitik a lehetosegeiket (es a szakma megiteleset romboljak).
> Nem akarok senkit bantani, mert valahogy meg kell tanulni, ez igaz, de miert
> elesben kell barmolni?
1) Ha bevallottan nem a legprofibb módon írod meg kedvenc adatbáziskezelődet
Perl-ben, akkor hol is van a "profizmus"?
2) Ugye ez teljesen ellentmond annak, hogy
>(Sajat agressziv velemenyem egybkent, hogy delphi-ben lekerdezoprogramot
>irni nem programozas, hanem egyszeru szoftverkezeles :-(

vagyis ugyanarról beszélsz mint én: van egy ifjonc havi 100-ért, aki
megírja Delphi-ben a lekérdező programot 10 nap alatt. Ha egy profi havi
400-ért nekiáll Perl-ben adatbáziskezelőt lekódolni, akkor az sokkal-sokka
l többe van. Szép általánosra kell megcsinálni, ugye, INNER és LEFT/RIGHT
OUTER + FULL OUTER joinokkal ugye, közben persze WHERE, COUNT, HAVING
ugyanolyan egyszerűre kell mint 1 soros SQL parancs kiadása, teljesítmény
szempontok - a szerveren script értelmező fut tízezer soros Perl
rendszerre minden egyes lekérdezés feldolgozásához...ssssz.. .  a
szolgáltatótok szeret titeket?

>Fel tucat tablahoz meg szvsz. boven nem kell egy adatbazis motor.

A fenti tetszőleges lekérdezést óhajtó user igény esetén? Rekord beszúrás,
gyors keresés stb minden egyes esetre külön megírva? A munkáltatód tudja
ezt? Mert ha én lennék, rég leállítottalak volna erről ;)

>Egy webes, fel tucat tablaval rendelkezo adatbazishoz kell -e
>berelni olyan tarhelyet, ahol meg kell fizetni az adatbazis szerver
>hozzaferest, vagy feltehetem barhova ahol Perl v. PHP van (a ketto kozul
>valamelyik felar nelkul rendelkezesre all).

Nem kell misztifikálni: pilátus compnál kb havi 5 rugó PHP rendszer
mysql-lel. No comment.

>Sot a megrendelo a szolgaltatonak fizet v. nekem fizeti azt a penzt,
>amiert megirtam hordozhatora az egeszet (ez ugye nem mindegy).

Melyik megoldás a hordozhatóbb? Az, amelyik kevesebb programsort
tartalmaz. Az SQL adatbázisos megoldás ebből a szempontból is kenterbe
veri a kézzel gányolást. Ha pedig a másik "érvet" nézzük, az még csak elmegy,
hogy nem ismered fel a jobb megoldást, és a megrendelőnek azért adsz
rosszabbat. De most már hogy tudod az ellenérveket, innentől átverés.

>>nekik sokkal inkább egy MEGBÍZHATÓ rendszer kell -
>>nem kifinomult.
>Nalam a ketto valahogy kolcsonos fuggosegben van.

A kifinomultat abban az értelemben értettem, hogy "az adott problémára
optimali zált teljesítmény szempontból". Így már pont egymásnak
ellentmondóak lesznek a kritériumok.

>>- minél magasabb szintu, letesztelt (vagyis ismert hibájú) eszközöket kell
>>  alkalmazni
>Terjunk vissza a koltseg elemzesre: mennyibe kerul egy Delphi v. egy Oracle?
>Egyebkent sajat peldambol mondom, hogy rengeteget szivtam ezeknek a
>letesztelt programoknak a hibaival mar!

Azt hiszem, még egyszer el kell mondani: a programozó a legdrágább
erőforrás. Tehát ha egy programozó Delphiben dolgozik, az év végén a
munkaadónak rengeteg megtakarítást - az ügyfél felé pedig a bizalom
megmaradását eredményezheti egy Perl-ben dolgozó emberkéhez képest! Ne
felejtsd el, hogy ha a Te Perl rendszered bedöglik, ahhoz jószerivel csak
Te fogsz érteni, Téged kell előkaparni, addig is áll egy cég miattad...
melyik is az olcsóbb? Egyébként itt elsősorban adatbáziskezelőkre
gondoltam. De ha az adatbiztonság nem mindenek felett álló szempont, akkor
mondjuk egy mysql ingyen van. Egy MSDE, ami rendkívül megbízható,
gyakorlatilag bugmentes, és elég gyors, kb 100 rugó, korlátlan példányban
telepítve. Akkor most mi a drága? Te csak rosszabb paraméterekkel
rendelkező rendszert tudsz megírni, és azt sem tíz nap alatt! Akkor rossz
is, és drága is, de a MIÉNK?  Nem itt van a probléma szive gyökere?

>>- ahol szuk keresztmetszet van, ott használni a csúnyább, de hatékonyabb
>> eszközöket
>A hatekonysaggal nem jar egyutt a csunyasag. Pl. a kedves Koszorus kollega
>programjai eleg hatekonyak, viszont soha nem lattam szebb, strukturaltabb
>alaposabban kommentezett forrast mint az ove (bar en ebben pont az
>ellenkezoje vagyok), na nem akarom, hogy itt egymast dicsoitsuk, de ez
>programozoi igenyeseg, es a profizmushoz (meg ugy altalaban a programozoi
>munkahoz) hozzatartozik!

[ugyenezt írta egy kolléga rövidebben:] Ismét mintha az
assembly-magasszintű nyelv vitát hallanám... Nagyon jó cég lehet a Tiétek,
ha hagyják, hogy az emberek újra megírjanak mindent kézzel, gondosan
kikommentezzék, cizellálják... nekem is ide kéne menni dolgozni... Hát ez
egyáltalán nem tipikus. Ami viszont sokkal többször előfordul, hogy X
munkatárs csiszolgatja, babusgatja kedvenc rendszerét 5 évig, majd amikor
más munkahelyre megy, ott áll a cég megfürödve, és egy embernek vagy 1
évébe kerül a non-standard rendszer kiismerése, vagy el kell dobni, és
újraírni az eg észet... Szerintem a programozói igényeseg a
céltudatosságnál kezdődik: mit kell megcsin álni, mi a határidő, mi a
legmagasabb szintű eszköz, amivel hatékonyan meg lehet olda ni a problémát
és hajrá, van rá 1-2 nap.

>egy min. par szazezres rekordszamu, tobb tiz tablas komplex adatbazis[-nál
érdemes használni adatbáziskezelőt - by ostor]
>kulonbozo hozzaferesi jogosultsagokkal (mert, ha megnezed a
>dokumentacioikat, akkor elolvashatod, hogy erre (es tobbre) is
>optimalizaltak oket, es kisebb adatallomany eseten nem biztos, hogy hozza a
>megfelelo hatekonysagot).

Hát ezt nem igazán értem: nagy feladatra jó, kis feladatra nem jó? Nekem
semmilyen ilyen irányú tapasztalatom nincs. Egy adatbázist megtervezni
2 óra, létrehozni, adatokkal feltölteni, használatba venni 10 perc. Utána megy
mint golyó. 1 új constraint hozzáadása a rendszerhez semmilyen programozást
nem igényel, csak 1 perces gépelés.

>>"A fekete dobozokat nem szabad feltörni, amíg jól muködnek."
>Aha, csak az a baj, hogy ritkan mukodnek jol. (ez sajat velemeny, ami
>tapasztalatbol keletkezett)

Mi egy saját, 10 ezer soros rendszer és egy több éve a nagyközönség által
tesztelt adatbáziskezelő meghibásodási rátája? SZámold hozzá a saját
Perl értelmező rendszered instabilitását is! Szerintem ha kiismered egy
nagy program pár gyengéjét, jobban jársz...

>Az egyik problema a Delphi-vel es minden rokonaval pont az, hogy 10 honapos
>tanfolyamrol kiesett ifjoncok Delphi programozonak hiszik magukat.
lásd fent.

>Ja es amin latszik a tapasztalatlansagod: nincs olyan, hogy Delphi
>programozo, nincs olyan, hogy Java programozo, nincs olyan, hogy Perl
>programozo. A programozas szemleletet, logikat, egyfajta gondolkodasmodot
>jelent. Es, ha az ember tud programozni, akkor megtanulja alapusan a
>kivalasztott nyelv szintaktikajat es abban programoz. Es szepen evek alatt
>akar tobb nyelvet is. Es ha ez a programozo ir egy algoritmust, akkor neki
>tokmindegy, hogy milyen nyelven kodolja.

Stb stb - a személyeskedést hagyjuk, de ha a tekintélyelvet kapjuk elő, akkor
paramétereim: én 16 éve programozom, és C++-ban egyedül most raktam
össze egy 145 ezer soros rendszert kb 120 táblás adatbázissal.
"Delphi programozo:" pár coder-rel előbb ugyanezt mondtam mint Te. De a
szövegkörnyezetben más az értelme: igenis jó egy "csak" Delphi, kezdő
programozó, ha határidőre elég jó hatékonysággal elvégzi a feladatot. Ez az
ami leginkább számít, és nem az hogy ki "AZ IGAZI PROGRAMOZÓ".
A többi személyeskedést hagyjuk.

>Egyebkent ugy kell megirni a fuggvenyt, hogy a JOIN (es barmilyen egyebb)
>feltetelek bemeno parameterek legyenek, es akkor egy egyszeru HTML designer
>is tud barmilyen barmilyen lekerdezest modositani egy interface leiras
>alapjan.
Aha... persze a LEFT JOIN table2 ON table2.id = table3.id is megy, ugye?
Ezt írja majd be a HTML designer?

>>[bajtárs írja:]az iroja evekkel ezelott elhagyta a ceget, dokume ntacio nincs
, tehat
>>aprankent ujra lesz irva.
>Ez megint a programozoi profizmussag es igenyesseg kerdese.
Csak nehogy utánatok kerüljek a cégetekhez, mert az olyan igényesek, akik
nem tudják megállni, hogy ne turkáljanak bele a fekete dobozokba...
hmmm...  sok fejfájást okoznak.

//bocsesz, csak azért nem magánba írok, mert az ifjú "Delphi programozók"
//ne higgyék azt, hogy az általad vázolt "hülyeség amit más csinált, majd
//én újra megírom, jobban" szemlélet a követendő - munkánál! Ismerkedésre,
//tanulásra jó.

-- 
Józsi a hegyről

>Felado : Selmeci Tamas
>Temakor: gyors rendezes ( 10 sor )

>Szoval a ket kod tok ugyan az. Tudja valaki, hogy miert engedelyezett a s[i]
>es a i[s] forma is???
Mert C. Ezzel az erovel azt is kerdezhetned miert
engedelyezett az alabbi assembly:

org 100h
mov bx,[bx+si+1234]
int 20h
Attol, hogy nem inicializalod a valtozokat, meg van
bennuk ertek, foleg, hogy a stacken vannak.
--
koka. icq#98705990

Szevasztok!

> Felado : Selmeci Tamas
> Temakor: gyors rendezes ( 10 sor )

Ha mar itt tartunk. Ugy remlik, mintha vki emlitett volna a qsortnal is
joval hatekonyabb rendezesi algoritmust. Van ilyen? Ha igen mi az alapja?

Udv!
Sipi