---
 HTTP://WWW.TVN.HU - Webhosting
 Mini csomag: 100 MB-os tárterület, Korlátlan MySQL adatbázis méret,
 PHP futtatás korlátok nélkül, .htaccess, stb.: CSAK 999 Ft + Áfa
---

T.Erdeklodok!

Reflektalok a "SkyPE telefon" irasokra, figyelembe
ajanlva a PC-World Magazin 2006. oktoberi szamat.
A 42. oldalon talalhato egy 5 oldalas, osszefoglalo
cikk, az internetes telefonalassal kapcsolatban:
"Beszelgessunk (majdnem) ingyen!"  cimmel.
Maga a cikk is erdekes, de szamomra a legfobb
informaciot a 46. oldalon ismertetett VoIP adapter
nyujtotta, amely 12.8,-eFt-os araval meg bele is fert
a csaladi koltsegvetesbe. Nem kell hozza szamito-
gep, igy barki, hozza nem erto is hasznalhatja. Csak
az UTP kabelt kell beledugni, valamint egy (akar
hagyomanyos analog) telefonkeszuleket csatlakoztatni.
(A tapellatasa 230 voltos halozati dugasztaprol tortenik.)
A cikk alapjan a "hopp.pcworld.hu/2263" webhelyre
ellatogatva, valamint a https://www.megafone.hu/
helyen, tovabbi informaciok talalhatok, mas hasonlo
eszkozokrol, valamint az eladohalozatrol. En is
ennek alapjan vettem meg a sajat kis adapteremet!
(Vigyazat, mas helyen ugyanezt 18 eFt feletti aron
vesztegetik, "de hulye azert nem vagyok!")
Segitsegevel nem kell lecserelni a jol megszokott
regi telefonkeszuleket, az eszkozhoz csatolva
ugyanugy hasznalhato, mint vezetekes koraban!
A doboz a keszuleken kivul tartalmaz egy 06-(21)
korzetszamu, egyeni telefonszamot, amely barmely
(vezetekes/mobil) szolgaltato halozatabol hivhato.
Hozza 1000,-Ft. lebeszelheto egyenleg a "Megafone"
halozataba.
Ezt  prepaid-hoz hasonloan, barmikor utan lehet
tolteni. (ha a Megafone-t akarod tovabbra is hasznalni.)
 De hasznalhato SkyPE, VoIPbuster, InternetCalls,
stb. rendszerekben is, kinek melyik az olcsobb!

          Jo beszelgetest:

                                    H.L.Sandor

Fülgy:

>Két ötletem, és hozzá két kérdésem van.

>Az egyik ötlet az, hogyha én keresek könyvet, akkor 
>behatárolok 3-4, a közelemben lévö könyvtárat, és ha ott 
>van(nak) a keresett könyv(ek), elmegyek érte(ük).
>Változik-e az adatszerkezet, vagy a séma, ha a fenti keresésnél
>nem egy, hanem legfeljebb 5 könyvtárat adhatok meg?

miert valtozna?  

>Jelenleg a nyitvatartás nincs nyilván tartva, tehát evidens, 
>hogy az adatbázis változik azzal, hogy minden könyvtár
>nyitvatartását is nyilván tartjuk. 
>(pl. h,sze, p 9-19, k, cs 10-16, szo zárva vagy 9-12)

>Ekkor viszont legalább két lépcsős keresésre van szükség, ugye?
>Először azokat a könyvtárakat választom ki, amelyek az adott
>napon (időtartamban) nyitva vannak, és utána ezeket adom
>meg a keresés szükitö feltételeiként.
>Vagy leválogatom a keresett könyveket könyvtárak szerint,
>és amelyik könyvtár nyitvatartási ideje nem felel meg a
>feltételnek, azokat eldobom.

>Melyik a jó módszer és hogyan kell megvalósitani? 
>Paraméter átadással, vagy egymásba ágyazott keresésekkel?

ha sql-t hasznalsz egyszerre is lehet - az mindegy hogy 
kered be a lekerdezesi felteteleket:
pl. kb:
select A_konyvtar_azonosito,B_konyv_azonosito ... from 
	A_konyvtar_nyitvatartas_tabla,B_konyvtar_tabla where 
	A_konyvtar_azonosito=B_konyvtar_azonosito and	
	nekem_jo_nyitvatartas=A_nyitva_van_e and ... egyeb feltetelek


>Még egy felmerült kérdés. Valamikor nagyon fontos volt, hogy
>egy mezö milyen hosszú, mert kevés volt a memória. Most
>azt hallottam, hogy már nincs tárolási probléma, mert a
>programok a "trimmelt" mezöket tárolják el, tehát csak a
>space nélküli részeket. Ha ez igaz, akkor egyszerüen minden
>szöveges mezöt 255 bájtra célszerü állitani, mert maszkolással
>úgyis leszükitem a bevihetö méretet és úgyse tárolja el a
>space-kkel teli részt és igy nem kell állitgatni a mezök
>hosszát.

>Ez valóban igy van, vagy azért nem teljesen jó igy?

tapasztalatbol tudom hogy lehet hogy sok memoria van, 
de sose eleg: egy sql szervert beallitasz 20 userhez 
nem mindegy milyen az adatbazis struktura mert a szerver
memojat eszi egy trigger vagy beepitett procedure 
(ezek a szerveren futnak altalaban)es 
esetleg tobb 100 000 vagy millios rekordszamnal pillanatok
alatt elfogyhat es akkor beindul a winyo swap ami 
ugye nem tul gyors. 
pelda: egy lekerdezes tartomanya 100 000 rekord ez 30 byte-tal 
szamolva osszesen kb 3 MByte (a resztabla merete)
(utana a eredmeny rekord-ok mezoinek 
kapcsolasa az ertektablakhoz akar ujabb select-tel)
mint 100 000 rekord X atlag 5000 byte-ot 500 Mbyte 
memoriafoglalas /select (index nelkuli karakter mezokre 
ertve) tehat 20 felhasznaloval szamolva 
60 Mbyte vagy 10 GByte memoria kellene minimum a szerverbe 
a select utasitashoz swap nelkuli gyors mukodeshez. 
Azt hiszem ez nem mindegy... 
nah meg a lekerdezo utasitas sem mindegy probalgatni kell...

Torok Istvan:-> regseeker 
hmm lehet hogy az csak registry hibakereso de nem javito?
- en a Ccleaner -t es az EasyCleaner hasznalom.

Szia!

>
>> ....es a vegeredmeny nekem mindig ugyanaz lesz, ha a teljes
>> normalizalast valasztom.

A fenti idézet tetszett nekem. Persze, hogy ua. lesz ha a koncepciod ua.. 
Pl. 
az emlitett filmes példa.
Ha filemnkent 1 rendező, tobb szereplo, a film cime az azonosito es filmközpont
u az egész, akkor valszeg ua., vagy hasonlo lesz
az adatszerkezet. De ha már nem 1 rendezős filmekről van szó akkor már 
más. 
Vagyis nem a normalizált végeredményt
kell kitalálni, hanem a dolgok belső logikáját. Ez viszont a rendelkezésre 
álló infoktól függ. Legalább kétféle infod lehet.
Az egyik maga az adat(absztrakt) mint film, rendező stb. És a másik nézet 
az 
ezen adatok közötti összefüggések, pl.
a rendező a filmhez tartozik és nem a vetitőgéphez. Ez a nehéz. Mármint 
ez 
utobbit meghatározni, kitalálni, felfedni. Ez az amit
a felhasználók általában nagyon titokban tartanak :-). Tehát ha ez az utobbi 
szerkezet, adat és összefüggések megvannak akkor már 
csak normalizálni kell és nagyjabol egyforma is lesz az adatszerkezet.. 

üdv. 

Egy nem kezi (es nem WiFi) megoldas ugyanerre a problemara: van egy Vosky
Call Centerem:
http://www.vosky.com/category.php?cid=1&cname=Products

Ebbe belemegy a rendes fali telefonvonal is, meg a geppel is ossze van 
kotve
USB-vel, a kimenete pedig egy telefonaljzat.

Ha felveszem a telefont, es tarcsazok, a rendes vonalon hiv. Ha a szam
elenyomom, hogy ##, akkor a Skype-on hiv kifele.

Hasonloan, befele a rendes vonal is csorog, meg a Skype is, de maskepp,
ugyhogy hallasra is lehet tudni. Sot, a Caller ID kijelzore kinyomja a 
hivo
Skype nevet.

Ket honapja tokeletesen mukodik. Nehany mas ceg is gyart hasonlot, de
azokrol rosszat irtak, azert valasztottam ezt. Olyan $60 korul volt.

Udv,
Jozsi.

Van egy Windows Mobile 5 Smartphone-on (T-Mobile Dash), es nem tudok
rajonni, hogy lehet ugy letolteni POP-pal a leveleket, hogy a szerverrol
egybol torolje.

A Google-ben mar probalkoztam, de semmi talalat.

Tenyleg nem lehet, vagy csak vak vagyok?

Koszonom,
Jozsi.

> >Például egyszerübb folyamatot, mint bejön egy hibaüzenet,
> >a felelös megkapja, megválaszolja - ez workflow ? - hogyan
> >lehet 
> >sql-ben megvalósitani?
> 
> pl.: +hibakod mezo es akkor mehet a select ...

Bocs, nem vagyok képben, részleteznéd, mire gondolsz?

> >Vagy, amikor késöbb változnak az adatok, azt hogyan lehet
> >nyomon követni? (például emberkének van állandó lakcime
> >meg ideiglenes lakcime meg tartózkodási helye, ezek közül
> >bármelyik lehet az aktuális cime.)
> 
> amire itt gondolsz az egy logikai mezo beiktatasaval 
> a legegyszerubb: erteke true ha aktualis,
> jah es esetleg egy datum mezo beiktatasaval pedig hogy
mikortol.
> 
> zfox

Eddig négyféle olyan problémát találtam, amire még ötletem
sincs, hogyan lehetne megoldani.

Az elsö kettö idötényezöhöz kapcsolható.
A fenti példa alapján, ugye, a "hagyományos" tárolás eddig
úgy nézett ki, hogy felülirjuk az adatot, mindig csak a
legújabbat
tároljuk, az illetöhöz csak egy cim, telefon, stb. tartozik,
és az
mindig a legújabb, a korábbi törlésre kerül.
Amikor kell az idörend, akkor már bonyolultabb a megoldás, de
elvileg kezelhetö, pl. két dátum/idö mezövel, az egyik a kezdö
dátum, a másik a befejezö, és ha a befejezö is ki van töltve,
akkor lezárható, "archiválható", akkor biztos, hogy már nem
aktuális.
Ugyanakkor lehet egynél több adat, aminél nincs befejezö
dátum, ezek elvileg mind aktuálisak, de nyilván ezek közül
egy lehet a "legaktuálisabb".
Például egy ingázó esetében van két városbeli cim, csak a
"menetrend" ismeretében lehet tudni, hogy adott napon 
melyik cimen tartózkodik, de mind a két cim "aktuális".

A harmadik tipus a fentebb emlitett "workflow", amikor
valamilyen feltételvizsgálatot kell végezni, hogy ki lehessen
deriteni, hogy hol tart egy folyamat. Valószinüleg logikai
mezökkel lehet ezt jól megoldani, de nagyon vigyázni kell,
hogy ne lehessen ellentmondás, vagy hibás jelzés, különben
borul az egész.

A negyedik tipust nem tudom definiálni se, "függöségnek"
nevezném. Ilyenkor azt is meg kell nézni, hogy mihez
kapcsolható az adat. Megpróbálom érzékeltetni az ingázós
példa alapján. 
Tehát van egy személy, akinek van két lakcime, és tudjuk,
hogy valamelyik cimen található, tehát a "menetrend" alapján
tudjuk, hogy melyik cimen kell keresni.
Igenám, de bejön a telefon problémája. Ha az illetöt telefonon
akarom hivni, már sokféle telefont kell nyilvántartani. 
Elöször is van legalább két lakástelefon, tehát a telefonszám
fixen a lakáshoz van kapcsolva. Azután jöhet egy mobiltelefon,
és ekkor rögtön bejön két altipus. A mobiltelefon lehet a
személyé, ekkor a személyhez kapcsolódik, és lehet a cégé,
ahol dolgozik.
Tehát már most van 4 telefonszámom, és kell egy tipus mezö,
ami nyilván tartja a telefon tipusát. 
Ez eddig érthetö, de ott akadok el, hogy hogyan tudom a
telefonszámot 3 különbözö táblához kapcsolni, ráadásul
váltakozva? Egyszer személy, egyszek lakás, egyszer cég
táblához tartozik a telefonszám. Persze, egy telefonszám
közvetlenül csak egy tipusú lehet, tehát csak egyetlen másik
táblához lehet kapcsolni, igy egyszerübb a helyzet. 
De itt elakadtam.

fülgy

Sziasztok!
Informatikust, webmestert keresünk, fo- v. reszmunkaidoben 
(elonyben: multimedia, php, (mysql), html) Kelet-Magyarorszagrol 
elonyben. Reszletek: redboss.hu/munka
Sziasztok, legyen sze'p napotok !
Andrea