- Megjelentek az első HMD okostelefonok, ezek a magyar áraik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Itt az első kép a 2024-es Nokia 3210-ről
- Készülőben a Xiaomi 2021-es csúcsmodelljeinek HyperOS frissítése
- Redmi Note 13 Pro+ - a fejlődés íve
- Samsung Galaxy A54 - türelemjáték
- Yettel topik
- Oppo Find X5 Pro - megtalálták
- iPhone topik
- Honor Magic6 Pro - kör közepén számok
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Az Apple iPadOS-t is megrendszabályozza az EU
it Az EB közölte: az Apple iPad táblagépekre írt iPadOS rendszere is kapuőrnek számít, az üzleti felhasználókra gyakorolt fontossága miatt.
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
Új hozzászólás Aktív témák
-
cucka
addikt
válasz Blackmate #173 üzenetére
pontosan mit is keresel?
ha oracle alá írt sql és pl/sql scripteket akarsz írni, akkor szükséged lesz egy oracle szerverre (ez lehet távoli gép) és egy oracle kliensre a saját gépeden. oracle kliens nélkül nem tudsz csatlakozni a szerverhez.
ezen túl lehet mindenféle kulturált adatbázis-kezelő programot feltelepíteni, pl. TOAD, TORA, PL/SQL Developer, ízlés szerint. -
cucka
addikt
Az SQL szerver törölve lett és a számlázó nem indul.
minden bizonnyal hiányzik neki az adatbázis, amin dolgozik.
Ha föltelepítik az SQL-t akkor azt állítják a forgalmazónál, hogy üres adatbázissal fog működni.
igen, mert az sql szerverben nincsenek benne gyárilag a cég számlázási adatai, mint ahogy a word újratelepítésével sem fogod visszakapni a régebben letörölt dokumentumokat.
magyarul szívás.. -
cucka
addikt
válasz aton-hawk #190 üzenetére
nem igazán egyértelműek a tábláid jelölései, de leírom, én hogyan csinálnám, aztán hátha ki tudsz belőle bogarászni valami hasznosat:
ezek a táblák vannak: termek(id, nev, akt_ar) és arvalt(id, termek_id, datum, ar). az id mindenhol elsődleges kulcs, a termek_id pedig külső kulcs, ami a termek táblára mutat. ekkor:
select termek.nev, termek.akt_ar, arvalt.ar from termek left join arvalt on (termek.id=arvalt.termek_id) where arvalt.datum<'2006-05-04' order by arvalt.datum desc limit 1;
ezt kipróbálás nélkül írtam, szóval jó eséllyel lesz benne hiba, de talán segít valamit -
cucka
addikt
természetesen elrontottam
szóval a lenti az elvileg arra jó, hogy egy adott termék adott dátumhoz kapcsolódó régi árát kiírja. ehhez a where részbe bele kell tenni egy szűrést a termek.id-ra, mondjuk termek.id=5
az összes ilyet kilistázni elég necces, legalábbis nem igazán van ötletem, mi lehetne a helyes megoldás. ha az árváltozások helyett azt tárolnád, hogy egy adott ár milyen dátumok között volt érvényes, akkor viszont a lentihez hasonlóan meg lehetne oldani. -
cucka
addikt
válasz vakondka #469 üzenetére
1. Ha egyszerűen csak át akarod pakolni az adatokat, akkor használd a phpmyadmin beépített export/import funkcióját. (Amennyiben nem túl nagy az adatbázis az import-hoz)
2. Ha feltétlenül programot akarsz rá írni, akkor jó tudni, hogy egy táblára úgy is hivatkozhatsz, hogy adatbázisnév.táblanév. Ekkor ugye nem kell a mysql_select_db, mert anélkül is meg fogja találni az adatbázis szerver a táblákat.
A másik lehetőség, hogy két adatbázis kapcsolattal oldod meg a problémát, ez pl. sokkal rugalmasabb, mert akár két teljesen különböző adatbázis szerverrel is működik a dolog.. -
cucka
addikt
MySQL támogatja a reguláris kifejezéseket, de valószínűleg más, elterjedt adatbázisok szintén. Nézz utána. Komolyan, legyél már annyira igényes legalább magaddal szemben, hogy nem elégszel meg ilyen hányadék megoldásokkal, mint amit mutattál.
Vagy esetleg hogy kéne php-val megoldani?
Mysql-re:
//kapcsolodsz az adatbazishoz
$res=mysql_query("select id, mezo from tablanev order by id asc");
while ($row=mysql_fetch_assoc($res)){
mysql_query("update tablanev set mezo='".str_repeat('1',strlen($row['mezo'])).'" where id='{$row['id']}'";
}[ Szerkesztve ]
-
cucka
addikt
válasz sztanozs #1551 üzenetére
Egyszerűen csak a szöveg alapú reprezentációt kell frissíteni és verziónként új adatbázist készíteni - nem pedig az aktuálist hozzáhegeszteni a fejlesztői verzióhoz. Ilyen módon az adatbázis felépítés (és a tárolt eljárásoik is) is egyszerűen verziókövethetővé válik.
Igen, ez így van. Lehet adatbázis deploy scripteket írni, nincs ezzel semmi gond. Az eredeti kérdésfelvetés viszont a php topikban volt, méghozzá azzal kapcsolatban, hogy a php kódban implementált alkalmazáslogikát megérné tárolt eljárásként megírni. Na ezzel így már problémák vannak:
- A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz. Tárolt eljárásokkal elvesződik az előny.
- A legtöbb php-s projekt olyan kis léptékű, amin már egy adatbázis deploy script elkészítése és karbantartása is túlmutat.Nem azt mondom, hogy a tárolt eljárások ne lennének alkalmanként hasznosak, de abban a kontextusban, ahol felmerült a kérdés, egyáltalán nem tartom jó ötletnek.
A második szerintem csak sírás. Adatbázis oldalon bőven elég szerintem az a WSWG megoldás, ami a piacon elérhető - ha az nem felelne meg, amit a motorhoz adnak.
Mi az a WSWG?(#1555) martonx
Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn)...
Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van.A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást.
[ Szerkesztve ]
-
cucka
addikt
válasz martonx #1563 üzenetére
Ez miért előnye a php-nak? Miért más nyelveken mit tárolnak a verziókövetőben? Szerelmes verseket?
Annyi előny, hogy nem kell lefordítani, megszabadulsz a Make/Ant szkriptektől, vagy az xml-ek turkálásától Mavenben, stb. . (Meg persze bizonyos szempontból ez hátrány is, tudom jól, ne akadj fenn ezen)A relációs SQL az egy rohadt nagy halmaz, rengeteg alhalmazzal, amik között halmaz műveleteket tudsz elvégezni rohadtul gyorsan. Hol akarsz ebben fejlődést? Legyenek örökölhetőek, interfészelhetőek a tárolt eljárások?
Ha alkalmazáslogikára szeretnéd használni, akkor szélesebb körű beépített libeket, és igen, több nyelvi eszközt.Ráadásul vicces pont PHP oldalról fanyalogni az SQL nyelv egyszerűsége miatt...
Az egy dolog, hogy a php egy nem túl jól kitalált nyelv, csomó furcsasággal, viszont a beépített eszközkészlete (magyarul a standard lib) igencsak jól használható és jól dokumentált.De hidd el, amikor komoly adatlogikákat kell kivitelezni, és komoly algoritmusokat kell kivitelezni, akkor azt próbáld már meg webszerver oldalon kivitelezni.
Emlékeztetlek, az eredeti hozzászólás a php topikban keletkezett, arra a felvetésre, hogy a php kódba nem kéne egyáltalán sql-t beágyazni/összerakni, hanem minden hasonló feladatot tárolt eljárással kéne megoldani. A php topikban pedig jellemzően nem a szakma krémje szokott kérdéseket feltenni, hanem kezdők.
Szóval igyekezz ennek tükrében értelmezni, amiket írtam. Én is pontosan jól tudom, hogy komplex projekteknél és nagy adatmennyiségnél az adatbázis szerver és kliens közötti kapcsolat overhead-je elszaladhat. Ennek ellenére nem fogom egyik kezdő php fejlesztőnek sem tanácsolni, hogy dobja ki a php-vel legyártott dinamikus sql-t és kezdjen inkább tárolt eljárásokat írni ezek kiváltására.[ Szerkesztve ]
Új hozzászólás Aktív témák
- Napelem
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Vezetékes FEJhallgatók
- Xbox tulajok OFF topicja
- Windows 10
- Asztrofotózás
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Skoda, VW, Audi, Seat topik
- eBay-es kütyük kis pénzért
- Veszprém és környéke adok-veszek-beszélgetek
- További aktív témák...