>Milyen Mo-n a helyzet programozas, informatika >teren?
Itt is kell a 200-as IQ, csak neheziteskent itt egy profi informatikus kevesebbet keres mint kint egy takaritono.:) Teher alatt no a palma:)
Kosz szepen, megkaptam. At kell neznem, es majd e-mailben valaszolok.
Hogy lettél Cobol programozó? Akartam szakmai gyakorlatra menni, es ez a lehetoseg volt (en is inkabb C++-t valasztottam volna, de nem volt lehetoseg. Meg most lattam be, hogy mennyire majdnem 0 szintu volt a tudasom akkor. Most sem valami magasszintu, most vesszuk a link listet, es meg van 2 ora, es that's it. A tanar meg azt mondta, hogy a linked listnel kezdodik a programozas). Es a szakmai gyakorlat alatt felajanlottak, hogy maradjak itt dolgozni.
Szvsz itthon nem nagyon tanítják (persze én még tanultam az egyetemen, de meg kell mondanom, nem keltette fel az érdeklődésemet). En most Amerikaban vagyok. Az egyetemek itt is egyre inkabb leveszik a kovetelmeny listarol. Hogy ezen az egyetemen eddig is volt, az azert van, mert ez business school, es a Cobol business application-okra van. De most mar itt is mindenkinek C++-t kell venni.
Te pedig fiatal lehetsz, én pedig azt hittem, hogy csak a kiöregedett, régi nagygépes programozók használják. Azt hallottam, hogy Amerikaban a programozok fele meg Cobol programozo. Talan azert van ez, mert a nagycegek megvettek a mainframe gepeket, sok ezer programot irtak ra. Es sok penz es ido ezeket atirni.
Ha Téged is érdekel, akkor Halassy Béla könyveit tudom ajánlani. Koszi szepen, mindenkeppen megnezem a vizsgak utan, mert ez engem erdekel. Bar mostanaban gondolkodom, hogy szakmat kellene valtani, mert nem sok elorelepest latok benne. Illetve akkor van elorelepes, ha valakinek 200-as IQ-ja van, es kepes ejjel-nappal tanulni, programozni.
Milyen Mo-n a helyzet programozas, informatika teren?
Hello, gondolom már nem nagyon aktuális, de azért leírom, hogy én hogyan csináltam volna meg:
SzemélyID
SZEMÉLY Név
… (ami még kell)
AdományID
ADOMÁNY SzemélyID
Dátum
BefizÖsszeg (a befizetett teljes összeg, ha kp akkor a „BANKJEGY”-ben részletezve) FizTipus (kp, kártya, átutalás, stb.)
AdományID
Bankjegy
BANKJEGY Darab
Strasszer: Halassy könyvei tényleg nagyon jók, azt hiszem a “kék” könyvben említi, hogy lesz egy
könyve a rendszertervezésről. Nem tudsz erről valamit?
Kedves Györgyi!
Megcsináltam az Access táblákat, meg egy lekérdezést is. A kapcsolatok is benne vannak. Szerintem egyébként ez a programozás egyszerűbb része, én pl a formokkal nem szeretek kínlódni, de sajnos azt is muszáj. Elküldöm mélben, hátha tudsz vele valamit kezdeni.
Hogy lettél Cobol programozó? Szvsz itthon nem nagyon tanítják (persze én még tanultam az egyetemen, de meg kell mondanom, nem keltette fel az érdeklődésemet). Úgy tudom, itthon is csak a nagy német cégek alkalmazzák nagygépeken. Te pedig fiatal lehetsz, én pedig azt hittem, hogy csak a kiöregedett, régi nagygépes programozók használják.
Az meg szép egy iskola lehet, ahol ennyi dolgozatot kell egyszerre beadni, ráadásul Bill Gates kötelező tananyad ;-))).
És akkor még valamit az E-R modell-hez. Valóban a rendszertervezés a legszebb feladat a programozásban. Én is ezt szeretem a legjobban. A többi már csak favágás. Ha Téged is érdekel, akkor Halassy Béla könyveit tudom ajánlani. Most gyorsan rákerestem a google.hu-n, és előjött két másik szakirodalom. Nem tudom, mennyire jó, de ha érdekel, akkor olvasgasd (majd a vizsgák után :))) ).
Kovács László: Adatbázisrendszerek Sík Zoltán: Adatbáziskezelés és tervezés A
Tulajdonkeppen teljesen igazad van. De ez az adatbazis csak resze a projectnek, es eddig a tobbi reszevel kinlodtam (pl. ilyenekkel, hogy a project management tablazatot megszerkesszem Exelben, a data flow diagramot smardraw-val, a Powerpointon megirjam az elodadast stb.) Es jovo het szerdaig mindennek kesz kell lenni. Raadasul addig el kell olvasnom egy konyvet (Bill Gates: Business at the speed of though), arrol is irnom, hogy hogyan kapcsolodik ez az en projectemhez.
Es meg egy masik orara be kell adnom egy fogalmazast a 30-as evek banki valsagarol.
Igazabol otleteket vartam az E-R modellhez. Mert szerintem ez a legnehezebb resze. A tanarom annak idejen azt mondta, hogy ez muveszet, utana a tobbi mar mechanikus. Es sajnos, csak kb. 3 egyszeru adatbazist csinaltam eddig. (azt is regebben). Ez az ora nem is adatbazis kezeles, hanem Information Development Project, amit senki sem ert, hogy miert van. Mert csinalni kell egy projectet, es a tanar mindig elmondja, hogy mi mindent kellene tudnunk. (amit persze, nem tanitanak)
Egyebkent, en Cobol programozo vagyok (tudom, minket nem is hivnak programozonak :)). Szeretnek uj dolgokat tanulni, es tovabb lepni, de ugy latom, hogy egyre nehezebb. Mert 50 fele dolgot kell tudni, es mindig valtozik. Engem a logika erdekel (programozas, leginkabb C++), az html/javascript, stb. egyaltalan nem. Arrol mar nem is beszelve, hogy egy nonek csalad mellett (plane, kisgyerek mellett) nehez ez a szakma.
és abban az igen-igen szerencsés helyzetben vagy, hogy külföldön tanulhatod a szakmánkat Nem biztos, hogy kulfoldon tanulni elonyt jelent (a nyelv miatt biztos). Otthon viszont szakmailag sokkal alaposabbak. Es mivel vannak vizsgak, az emberben jobban megmarad az anyag. Itt viszont a vizsga kb. olyan, mint Mo-n egy kozepiskolai dolgozat. Az elmeletet is jobban megtanitjak. (persze, iskola valogatja, ez business school, a technika nem elsodleges)
Én igazán nem akarok okoskodni, kedves Györgyi, de ha már van férjed és lányod, mégis tanulsz valamiért, és abban az igen-igen szerencsés helyzetben vagy, hogy külföldön tanulhatod a szakmánkat, akkor igazán vehetnél annyi fáradtságot, hogy megnézed az Access súgóját és példaadatbázisait, és a neten keresel kifejezetten kezdő programozók számára készített weboldalakat. Biztos vagyok benne, hogy sokkal hamarabb el tudod készíteni magad is a feladatot, mint itt megpróbálgatni írogatni és ismeretlenektől szedni valami információt (mert ebből úgysem lesz program sosem), ráadásul sikerélményed is lehetne.
=======================
Data Dictionary
=======================
Payee:
----------
-Payee_ID: Int // autoincrement
-Name: VarChar // pl. John Holmes
PK: Payee_ID
Index: Payee_ID, Name
DailyPayment:
----------------
-Day: Date // date of payment
-Payee_ID : Int // id of payee
-Denomination_ID : Int // id of denom. (címlet)
-CountOf: Int // Number of coins or sheets of that denomination
PK: Day, Payee_ID, Denomination_ID
Denomination:
------------------
-Denomination_ID : Int // identifier
-Title : String // name of coin or sheet, eg. $10, c5, $5 etc
-Amount : Float // Value of the coin/sheet, e.g. 1 for $1, 0.1 for cent 1, 10 for $10
Monthly income:
------------------
SELECT DailyPayment.denomination_id, sum(DailyPayment.CountOf*Denomination.value)
FROM DailyPayment,Denomination
WHERE
(Month(Day) = Month($monthInIssue)) AND
(Denomination.denomination_id = DailyPayment.denomination_id)
GROUP BY denomination_id;
Payment total by payee:
--------------------------
SELECT Payee.name, sum(DailyPayment.CountOf*Denomination.value)
FROM Payee,DailyPayment,Denomination
WHERE
(Payee.Payee_ID = DailyPayment.Payee_ID) AND
(Denomination.denomination_id = DailyPayment.denomination_id)
GROUP BY Payee.id;
Number of $10 sheets payed on a given day:
---------------------------------------------
SELECT Denomination.Title, Count(DailyPayment.CountOf)
FROM DailyPayment, Denomination
WHERE DailyPayment.Day = $dayInIssue AND
Denomination.Title = "$10"
GROUP BY Denomination_ID
Azt hiszem, hogy az E-R modell az az, amit te kapcsolatnak nevezel. E-R modell = Entity-Relations Modell (tabla-kapcsolat?). Ezt nekunk eloszor papiron le kell rajzolni. Semmi mas, mint a tablakat felirni, felsorolni a hozza tartozo attributumokat, kijeloni a PK-t, es osszekotni a tablakat (1:1, 1:N)
Ha tudsz angolul, es erdekel, itt van egy weboldal errol a temarol:
http://cisnet.baruch.cuny.edu/holowczak/classes/9440/entityrelationship/
A data dictionary pedig csak annyi, hogy a tablak es a hozza tartozo attributumok fel vannak sorolva. Ezt az Access megcsinalja az adatbazisbol.
Ha megcsinalod nekem ezt, akarmennyi sort meger (10-20-50 stb). De az a helyzet, hogy nem vagyok Mo-n. De par heten belul megyek haza a csaladommal (ferjem + pici lanyom), es akkor akar a legjobb helyre is meghivunk vacsorara, vagy amit akarsz. (Ha budapesti vagy, akkor Budapesten).
A formokat, lekérdezéseket már csak meg tudod írni a táblák alapján. Igen, ez a konnyebb resze. Meg elegendo mennyisegu adatot is kell bevinnem. Ezek nem nehezek, de itt most versenyt futok az idovel. Meg a powerpointot is meg kell csinalnom, es meg a azon a napon 4 dolgozatot kell beadnom.
Tenyleg nem akarlak megterhelni, csak akkor csinald, ha ugy erzed, ez igy OK neked. Ha ugy dontesz, hogy igen, akkor csinald ugy, ahogy eddig is szoktad. (hagyd az E-R modellt, az a lenyeg, hogy legyen egy mukodo adatbazis).
Húú miket kérdezel! Mi az az E-R modell? Meg a data dictionary?
Ha jól tudom Access-ben is sql lekérdezéseket kell eszközölni, tehát csak ezzel tudod megcsinálni. A hitelkártya-elfogadás pedig már komolyabb dolog.
Hány sört ér meg neked, ha úgy nagyjából összerakom Access-ben a táblákat, kapcsolatokat? A formokat, lekérdezéseket már csak meg tudod írni a táblák alapján.
Tudnal segiteni megrajzolni az E-R modellt? Ezzel kellene kezdeni. Mert a tanarnak el kellene kuldenem a data dictionaryt. (az Accessbol, miutan beirtam a tablakat)
Koszi a lekerdezest, ez sokat segit. De Accessben nem lehet enelkul is lekerdezeseket megcsinalni? (mar regen vettem, akkor is csak egy altalanos adatbaziskezeles volt, es Access-sel foglalkoztunk vagy 2 orat). Mondjuk, en is jokor kerdezek ilyen primitiveket, mikor 4 nap mulva konkretan kesz kell lenni.
A tanar azt is akarja, hogy a rendszer kepes legyen hitelkartyat is elfogadni (szemelyesen, vagy web lapon keresztul), de ezt mar tenyleg nem tudom, hogy hogy kell. Arrol nem is beszelve, hogy ennel az egyhaznal egyaltalan nem szokas hitekartyat elfogadni. Sot, a legtobb egyhaznal igy van.
Pedig ha bankjegyeket kell számolni, akkor bizony kell ez a két tábla is.
Irsz egy lekérdezést:
select BankoName, sum(Osszeg), Datum, SzemelyNev
from tBefizetesReszletezo
inner join tBefizetes on tBefizetes.BefiztesID = tBefizetesReszleteso.BefizetesFK
inner join tSzemely on tSzemely.SzemelyID = tBefizetes.SzemelyFK
inner join tBanko on tBanko.BankoID = tBefizetesreszletezo.BankoFK
group by BankoName, Datum, SzemelyNev
Remélem jól írtam a lekérdezást. Ha hozzáírsz egy where-t a dátumra, akkor tetszőleges időintervallumra megkapod a névérték szerinti részletezést.
Itt templomi gyujtesrol van szo. Tehat nincs visszajaro penz. Azert kell kulon a bankjegyeket megszamolni (1,5,10, stb.), mert a gyujtes megszamolasa vegen igy kell a bankba vinni. Eddig ugy csinaltak, hogy egy embernek megszamoltak, ezt feljegyeztek, majd kulon raktak a bankjegyeket, es meg egyszer megszamoltak. Az adatbazis abban segitene, hogy nem kellene 2x szamolni, plusz lehetne mindenfele reportot lekerni (bizonyos datumra mennyi a befizetes, bizonyos embernek mennyi az evi befizetese, stb.)
Ezt elég lenne egy formon belül, nem adatbázis szinten megoldani. Ezt nem teljesen ertem, hogy mit jelent. Mindenesetre, nem akarom a feladatot tovabb egyszerusiteni, mert mar igy is egyszeru. Ezt az egyik orara kell csinalni, es a tanar kikototte, ogy olyan project kell, amiben van Access database.
Ez az otlet egyebkent onnan jott, hogy egyik munkatarsam tenyleg meg akarja ezt csinalni a templomnak, ahova jar, de nincs ideje. Eloszor azt mondta, hogy akkor legyen ez a projectem, de utana visszakozott (Mert a templomban nem engedtek meg, hogy mas csinalja), es most mar semmmit sem segit. De mar tul keso volt visszamondani a tanarnak. Egyebkent sem lett volna mas otletem, mert a tanar ragaszkodott, hogy "igazi" project legyen. De nekem az ilyen project otletek nem tetszettek, hogy "e-learning". Ez azt jelenti, hogy a beteg gyerekekhez nem megy ki a tanar (erre itt torveny van, hogy ki kell menni), hanem interneten keresztul adja le az orat tobb gyereknek. De ez most mellekes.
A lenyeg az, hogy nekem ezt le kell adnom minel hamarabb. Es raadasul jovo heten szerdan meg eloadast is kell tartanom ebbol Powerpoint segitsegevel.
Az Osszeget mindenkeppen szet kell bontani bankjegyekre.
Es azt hogy lehet megcsinalni Accessen, hogy a gyujtes napjan beirom a formba 1x a datumot, es az minden sorba belemegy automatikusan?
Kell-e, hogy egy személy egy nap többször is befizethessen? Nem, mivel gyujtesrol van szo.
Ebben segitene a szamitogep. Amikor X.Y-nak szamoljuk, hogy 1 db 5 dollaros + 2 db 10 dollaros, akkor ezt egybol beirhatnank a szamitogepbe (vagyis a szemelyt, es a bankjegyeket), es mikor kesz vagyunk, a gep osszegezne. Ezt elég lenne egy formon belül, nem adatbázis szinten megoldani.
Üdv
József
Az, hogy miért kellene nyilvántartani a bankókat,számomra sem világos, ez alapján akartok elszámolni a pénztárral? Ha igen, akkor a felmerülhet több probléma is, pl. vissza kell adni, $5 akar fizetni valaki, és csak $10 bankó van nála, akkor +1*$10+ -1*$5-ként tartanád nyilván?
Kell-e, hogy egy személy egy nap többször is befizethessen?
Szerintem, a feladathoz amit leírtál, elég lenne két entity (egyed vagy entitás magyarul):
SZEMÉLY
Szemely_ID(PrimaryKey)
Személynév
...stb
BEFIZETÉS
Befizetés_ID(PK)
Szemely_ID
Dátum
Összeg
Megjegyzés
Ebben segitene a szamitogep. Amikor X.Y-nak szamoljuk, hogy 1 db 5 dollaros + 2 db 10 dollaros, akkor ezt egybol beirhatnank a szamitogepbe (vagyis a szemelyt, es a bankjegyeket), es mikor kesz vagyunk, a gep osszegezne. Ezt elég lenne egy formon belül, nem adatbázis szinten megoldani.
Üdv
József
Egy dolog nem világos: évek múlva is tudni akarjátok, hogy ki milyen címletű bankjegyekkel fizetett, vagy ez csak abban a pillanatban érdekes? (BTW csekkel vagy banki átutalással nem szoktak fizetni?)
Itt olyan profi programozok vannak, hogy valszeg tul primitivet kerdezek.
Egy olyan rendszert akarok megcsinalni Access-ben, amely segiteni a penz szamlalast egy templomban. Most kezzel szamoljak, es mindenki penzet kulon megszamoljak, majd feljegyzik az illetohoz (itt boritekba adjak, es ra van irva a neve). Utana meg egyszer megszamoljak, mert szet kell szedni kulonbozo bankjegyekre.
Ebben segitene a szamitogep. Amikor X.Y-nak szamoljuk, hogy 1 db 5 dollaros + 2 db 10 dollaros, akkor ezt egybol beirhatnank a szamitogepbe (vagyis a szemelyt, es a bankjegyeket), es mikor kesz vagyunk, a gep osszegezne. Ja, es a datum is fontos. Es mindenfele reportokat le lehetne kerni a rendszerbol (egy illeto mennyit fizetett, mennyi volt a havi bevetel, stb.)
Ti hogy latjatok, hogy kellene ezt megtervezni? 3 entity van: datum, penz, szemely. De azt hiszem, hogy a datumot/penzt egybe lehetne rakni. A szemely lenne a 2. entity, es a szemely azonositoja foreign key lenne a datum/penz entityben. De mi lenne ott a primary key?
Elnezest az angolert, de ezeket angolul tanultam, es nem tudom a szakkifejezeseket magyarul.