- Friss információk és képek a OnePlus új órájáról
- Nemzetközi vizekre evezett a Realme GT 7 és GT 7T
- One mobilszolgáltatások
- Honor Magic8 Pro - bevált recept kölcsönvett hozzávalókkal
- Huawei Watch Fit 5 Pro - jó forma
- Képeken a Sony WF-1000XM5
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Szaporodik és sokasodik a One UI 8.5
- Fotók, videók mobillal
- Google Pixel topik
Új hozzászólás Aktív témák
-
Köszönöm! Vállalati lehetőségeink limitáltak, de alapvetően winesek vagyunk és még egy sql szerverünk is van.
A html űrlap nekem is tetszik a form már megvan csak még nem tudom elküldeni adatbázisba az adatokat :/Az elküldés viszonylag egyszerű, kapcsolódni kell a kiválasztott adatbázishoz, és egy insertet kell (vagy egy tárolt eljárást meghívni, ami ugyanezt elvégzi) lefuttatni.
-
php és aspx (de ha már aspx, akkor inkább asp.net) között nem az a különbség, hogy melyik gyorsabb, vagy jobban tanulható, hanem az, hogy ahova tervezed, ott melyiket tudják majd kiszolgálni...
Amúgy kell egy HTML űrlap (mindegy, hogy html, php, vagy aspx-el csinálod) bevitelre (asp.net-tel simán tolható egyből adatbázisba), kell egy adatbázis alapvető táblákkal (tartalom a kitöltött mezőknek, felhasználók, esetleg log) és kell még egy statikus mezőkkel megáldott űrlap, amin van egy engedélyez és egy visszautasít gomb. Ezek megnyomásásnak eredményét is tárolni kell a tartalom táblában. KB ennyi.
AE
-
php és aspx (de ha már aspx, akkor inkább asp.net) között nem az a különbség, hogy melyik gyorsabb, vagy jobban tanulható, hanem az, hogy ahova tervezed, ott melyiket tudják majd kiszolgálni...
Amúgy kell egy HTML űrlap (mindegy, hogy html, php, vagy aspx-el csinálod) bevitelre (asp.net-tel simán tolható egyből adatbázisba), kell egy adatbázis alapvető táblákkal (tartalom a kitöltött mezőknek, felhasználók, esetleg log) és kell még egy statikus mezőkkel megáldott űrlap, amin van egy engedélyez és egy visszautasít gomb. Ezek megnyomásásnak eredményét is tárolni kell a tartalom táblában. KB ennyi.
AE
-
Sziasztok!
A következő feladat esetében tudna valaki útba igazítást adni? :
- egy html alapú (vagy aspx, vagy php amelyik jobb gyorsabb könnyebben kezelhetőbb/tanulhatóbb) űrlapon kellene felvinnie adatokat több usernek
- ez(ek) bemenne egy adatbázisba (sql-el kísérletezgetem)
- és az újonnan bekerült adatokat (mondjuk megrendeléseket) egy fogadó oldalon látnia kell a fogadónak és adatot kell hozzáadnia, nyugtáznia, visszaigazolniaEléggé az elején tartok s nagyon megköszönném ha valaki segítene kicsit (akár priviben vagy mailbe)
-
EkSYS
senior tag
Sziasztok!
A következő feladat esetében tudna valaki útba igazítást adni? :
- egy html alapú (vagy aspx, vagy php amelyik jobb gyorsabb könnyebben kezelhetőbb/tanulhatóbb) űrlapon kellene felvinnie adatokat több usernek
- ez(ek) bemenne egy adatbázisba (sql-el kísérletezgetem)
- és az újonnan bekerült adatokat (mondjuk megrendeléseket) egy fogadó oldalon látnia kell a fogadónak és adatot kell hozzáadnia, nyugtáznia, visszaigazolniaEléggé az elején tartok s nagyon megköszönném ha valaki segítene kicsit (akár priviben vagy mailbe)
-
asuspc96
őstag
-
Peter Kiss
őstag
-
Apollo17hu
őstag
Sziasztok!
Főleg iránymutatást szeretnék, nem komplett megoldást, mielőtt nekem esnétek emiatt
Szóval van ugye a bkv-nak egy nyilvánosan elérhető gtfs adatbázisa, amiből én szeretnék menetrendet készíteni, mobilra. A problémám az az, hogy ez laza ~150mb méretű, szóval ezt így 1:1 kicsit necces lenne berakni Viszont az adatbázishoz nem sokat értek, de azt már sikerült átlátnom hogy nagyjából hogyan épül fel. Van a stop_times file, ebben van kb ~3,5millió sor viszont ezek közül nagyon sok van ami szinte ugyan azt tartalmazza. Itt minden egyes sornál meg van adva, hogy az a megálló amihez az az indulási időpont tartozik az az adott járatnak hanyadik megállója. Viszont mivel ezek úgy se változtak, én úgy gondoltam, hogy azzal már le lehetne csökkenteni az adatbázist ha valahogy ezeket ki tudnám szűrni, de mivel most látok először mssql-t fogalmam sincs, hogy ezt hogyan is kéne Ha legalább néhány parancsot mondanátok, meg hogy nagyjából hogyan álljak neki azt nagyon megköszönném. -
Sziasztok!
Főleg iránymutatást szeretnék, nem komplett megoldást, mielőtt nekem esnétek emiatt
Szóval van ugye a bkv-nak egy nyilvánosan elérhető gtfs adatbázisa, amiből én szeretnék menetrendet készíteni, mobilra. A problémám az az, hogy ez laza ~150mb méretű, szóval ezt így 1:1 kicsit necces lenne berakni Viszont az adatbázishoz nem sokat értek, de azt már sikerült átlátnom hogy nagyjából hogyan épül fel. Van a stop_times file, ebben van kb ~3,5millió sor viszont ezek közül nagyon sok van ami szinte ugyan azt tartalmazza. Itt minden egyes sornál meg van adva, hogy az a megálló amihez az az indulási időpont tartozik az az adott járatnak hanyadik megállója. Viszont mivel ezek úgy se változtak, én úgy gondoltam, hogy azzal már le lehetne csökkenteni az adatbázist ha valahogy ezeket ki tudnám szűrni, de mivel most látok először mssql-t fogalmam sincs, hogy ezt hogyan is kéne Ha legalább néhány parancsot mondanátok, meg hogy nagyjából hogyan álljak neki azt nagyon megköszönném. -
Alexios
veterán
Sziasztok!
Főleg iránymutatást szeretnék, nem komplett megoldást, mielőtt nekem esnétek emiatt
Szóval van ugye a bkv-nak egy nyilvánosan elérhető gtfs adatbázisa, amiből én szeretnék menetrendet készíteni, mobilra. A problémám az az, hogy ez laza ~150mb méretű, szóval ezt így 1:1 kicsit necces lenne berakni Viszont az adatbázishoz nem sokat értek, de azt már sikerült átlátnom hogy nagyjából hogyan épül fel. Van a stop_times file, ebben van kb ~3,5millió sor viszont ezek közül nagyon sok van ami szinte ugyan azt tartalmazza. Itt minden egyes sornál meg van adva, hogy az a megálló amihez az az indulási időpont tartozik az az adott járatnak hanyadik megállója. Viszont mivel ezek úgy se változtak, én úgy gondoltam, hogy azzal már le lehetne csökkenteni az adatbázist ha valahogy ezeket ki tudnám szűrni, de mivel most látok először mssql-t fogalmam sincs, hogy ezt hogyan is kéne Ha legalább néhány parancsot mondanátok, meg hogy nagyjából hogyan álljak neki azt nagyon megköszönném. -
-
Sziasztok!
Kiderült, hogy van egy nagy hiányosságom SQL terén.
Téma, adatábázis tervezés / rendezés lenne. N ... N kapcsolat esetén, nekem új (PHP tanulásnál láttam először ) hogy vannak kapcsoló táblák (harmadik tábla). Nekem ez baromi új. SQL-t tanultam (suliban is) MSSQL / ADO.NET de így kapcsoló tábla létrehozása az még sosem.
Ebben tudtok nekem jó könyvet ajánlani, esetleg weboldalt. Én úgy gonodlom az alapok megvannak. Kivéve ez. Elmélet, normálformák is okésok.
De ez nekem kimaradt. -
Lacces
őstag
Sziasztok!
Kiderült, hogy van egy nagy hiányosságom SQL terén.
Téma, adatábázis tervezés / rendezés lenne. N ... N kapcsolat esetén, nekem új (PHP tanulásnál láttam először ) hogy vannak kapcsoló táblák (harmadik tábla). Nekem ez baromi új. SQL-t tanultam (suliban is) MSSQL / ADO.NET de így kapcsoló tábla létrehozása az még sosem.
Ebben tudtok nekem jó könyvet ajánlani, esetleg weboldalt. Én úgy gonodlom az alapok megvannak. Kivéve ez. Elmélet, normálformák is okésok.
De ez nekem kimaradt. -
hű, te aztán kevered a szezont a fazonnal.
Az alkalmazások úgy néznek ki, hogy az alkalmazások egy adatbázis usert használnak, eddig oké. Viszont szokott lenni egy user struktúra, és ebben vannak a userek bejelentkezéséhez szükséges információk, szerepkörök tárolva DB szinten.
Az alkalmazás pedig e user struktúra alapján szabja meg, hogy ki mit tud csinálni.
Mondok egy példát:
van egy db user, mondjuk pistike, ami hozzáré egy darab db-hez, ezt tudja írni olvasni.
Ebben a db-ben van egy user tábla, ebben felsorolva egy rakás user.
A felhasználó be akar lépni az alkalmazásba. Az alkalmazás pistike userrel megnézi, hogy a megadott user-pass páros megfelel-e a user táblában tároltaknak.
Ha megfelel, akkor már azt is tudja, hogy XY-nak mit szabad és mit nem csinálnia az alkalmazásban.
Amikor a feladat pedig az, hogy egy mezőt ne tudják a sima felhasználók módosítani, akkor a megoldás nem az, hogy pistike user mellé felveszek pistike2-t, meg szétbarmolom a tábla struktúrámat, hanem az alkalmazásban a user jogosultságának megfelelően letiltom/engedélyezem az adott mező módosítását.
És itt ér össze a DB és az alkalmazásszintű jogosultság kezelés. És ahogy mondtam a db szintű szinte lényegtelen, mert amikor egy programot használsz (normális, jó esetben) a fent részletezett módon dől el, hogy ki mihez fér hozzá, nem pedig db szinten.
A DB admin dolgot meg totál felesleges ide keverni, én is nagyvállalati környezetben dolgozok, tisztában vagyok a hozzáférések szigorúságával.
Nem gondoltam volna, hogy a közgondolkozásban ekkora kavar van jogosultságkezelés tekintetében.Tökéletesen ugyanarról beszélünk.
(Nem akartam túlzottan szakszavakat használni, de már látom, hogy szerencsésebb lett volna az adatbázis szintű usereket sémának hívni, így nem lett volna félreérthető.) -
Attól függ, milyen jogosultságkezelésről beszélünk. Az adatbázis szintű és alkalmazás szintű két külön dolog, én az előbbiről beszéltem. Egy több ezer felhasználós alkalmazás simán használhat egyetlen adatbázis user-t. Itt természetesen az alkalmazás oldali jogosultságok kezelésén van a hangsúly. Ma már ritka (és szerintem jócskán elavult) az olyan alkalmazás, amely minden user-t külön db user-ként kezel, itt a jogosultságkezelés egyértelműen a db-ben kell legyen.
Viszont ma már nem egyszintű rendszerekről szoktunk beszélni, hanem egymással szoros kapcsolatban lévőkről, köztes interfészekről, akár közös adatbázison osztozó rendszerekről is. Itt a rendszerek közötti jogok kezelése alkalmazás oldalról értelmetlen (nem számítva a speciális middleware és ESB-szerű termékeket). -
#65304576
törölt tag
Köszi az Oracle-lel kapcsolatos infót.
Oracle-ben simán lehet, hogy ez már jól megoldott kérdés, én mondjuk elsősorban MySQL-re szorítkoztam jelen esetben (igaz, ezt nem tettem hozzá), mivel a másik topicban a srác konkrétan MySQL-ről kérdezősködött (MySQL+PHP kérdés).
Ezt írtad: "Komoly helyeken ma már elvárás, hogy az adatbázis rendszeradminok ne férhessenek hozzá érzékeny adatokhoz"
Itt az érzékeny adatok alatt érthetünk akár jelszavakat vagy más adatokat is, amiket nyilvánvalóan egy mezei MySQL-táblában is többnyire valamilyen hash-elt formában tárolnak el, hogy akár egy adatbázis-rendszergazda se lássa ezeket nyers formában, bár önmagában még ez sem jelent komoly védelmet.
Különben úgy állítottad be, hogy az, hogy a DBA pozíció komoly bizalmon alapszik, az ellentmond annak, hogy a jogosultságkezelést elsősorban NEM adatbázisban kell megoldani - amit én és martonx állítottunk. Ezt továbbra is tartom, hogy egy normális alkalmazás esetén a jogosultságkezelés megoldása nem csak akkor dől el, amikor az adatbázissal kommunikálsz, hanem belépés után egészen a munkamenet erejéig egyértelműek a szerepkörök és a hozzájuk tartozó jogosultságok...
Másrészt már hogy ne lenne egy DBA állás egy valamit is jelentő cégnél komoly bizalmi pozíció? Teljesen nyilvánvaló, hogy az, mivel egy komplett adatbázis van a kezedben, azt megfelelő szerződéskötés híján akár nyugodtan jogszerűen ki is adhatnád más cégeknek, vagy csak szivárogtathatnál belőle adatokat, így egyértelmű, hogy egy cégnél azért meg kell fontolni, kivel, mit írnak alá - be kell biztosítaniuk magukat önmaguk védelme érdekében, ez így normális. -
Sk8erPeter
nagyúr
Ez már rég nem így van. Komoly helyeken ma már elvárás, hogy az adatbázis rendszeradminok ne férhessenek hozzá érzékeny adatokhoz, még DBA jogokkal sem. Részben törvényi előírás, részben céges policy lehet ennek az oka. Egy DBA pozíció nagyon kemény bizalmi állás, nekem is nagyon sok feltételt és kikötést kellett aláírnom és elfogadnom. Emellett a nagyobb, komolyabb rendszerek már mind rendelkeznek valamilyen védelmi eszközzel ilyen esetekre, ilyen pl. az Oracle Vault.
És Oracle DB-ben lehet oszlopra is jogosultságot definiálni, de ha nem kell, az adatbázis szintű auditálással is ellenőrizhető, hogy ki mihez fért hozzá, nem kell hozzá külön log-olást gyártani.
-
#65304576
törölt tag
Miért lenne már ez "kliensoldal"?
Egész eddig szerveroldali authentikációról és authorizációról beszéltünk - nyilván, mi másról, ha itt webes alkalmazásról van szó? -, hol van itt kliensoldali jogosultságkezelés?
Egyébként számomra sem világos, miért kellene kitekerni az adatbázist ahhoz, hogy valaki admin-jogosultságokkal bejelentkezve hozzáférjen az adatbázis bizonyos adataihoz. Ha már valaki rossz szándékkal hozzáfér az adatbázisodhoz, akkor már úgyis teljesen mindegy, nem valószínű, hogy az ilyen szintű elbonyolítással fogod hűdebiztonságossá tenni az oldalt.
Ráadásul nézd meg akár a jóféle CMS-eket is, ezek biztonsági részét is próbálják lehetőleg minél jobbá tenni az idők során (mindig van mit foltozgatni; de akár a form injectionös problémára is megoldások vannak) a hitelesítés és minden egyéb kapcsán is, de átlátható adatbázis-szerkezete van, nem adatbázisszinten akarják megoldani a jogosultságkezelést. A lényeg, én is azon az állásponton vagyok, mint martonx, hogy az alkalmazásra kellene bízni ilyen esetben (is) a jogosultságkezelést, nem pedig SQL-szintre tenni.De ha van ellenérved, írd le.
Ez már rég nem így van. Komoly helyeken ma már elvárás, hogy az adatbázis rendszeradminok ne férhessenek hozzá érzékeny adatokhoz, még DBA jogokkal sem. Részben törvényi előírás, részben céges policy lehet ennek az oka. Egy DBA pozíció nagyon kemény bizalmi állás, nekem is nagyon sok feltételt és kikötést kellett aláírnom és elfogadnom. Emellett a nagyobb, komolyabb rendszerek már mind rendelkeznek valamilyen védelmi eszközzel ilyen esetekre, ilyen pl. az Oracle Vault.
És Oracle DB-ben lehet oszlopra is jogosultságot definiálni, de ha nem kell, az adatbázis szintű auditálással is ellenőrizhető, hogy ki mihez fért hozzá, nem kell hozzá külön log-olást gyártani.
-
Sk8erPeter
nagyúr
Miért lenne már ez "kliensoldal"?
Egész eddig szerveroldali authentikációról és authorizációról beszéltünk - nyilván, mi másról, ha itt webes alkalmazásról van szó? -, hol van itt kliensoldali jogosultságkezelés?
Egyébként számomra sem világos, miért kellene kitekerni az adatbázist ahhoz, hogy valaki admin-jogosultságokkal bejelentkezve hozzáférjen az adatbázis bizonyos adataihoz. Ha már valaki rossz szándékkal hozzáfér az adatbázisodhoz, akkor már úgyis teljesen mindegy, nem valószínű, hogy az ilyen szintű elbonyolítással fogod hűdebiztonságossá tenni az oldalt.
Ráadásul nézd meg akár a jóféle CMS-eket is, ezek biztonsági részét is próbálják lehetőleg minél jobbá tenni az idők során (mindig van mit foltozgatni; de akár a form injectionös problémára is megoldások vannak) a hitelesítés és minden egyéb kapcsán is, de átlátható adatbázis-szerkezete van, nem adatbázisszinten akarják megoldani a jogosultságkezelést. A lényeg, én is azon az állásponton vagyok, mint martonx, hogy az alkalmazásra kellene bízni ilyen esetben (is) a jogosultságkezelést, nem pedig SQL-szintre tenni.De ha van ellenérved, írd le.
-
Így van, de ez jogosultság kérdés. Az adattárolás nem kérdés (a mezőt tárolod valahol). Csak az a kérdés, hogy bizonyos jogosultsággal bíró felhasználók tudjanak egy adott mezőn módosítani. Ez pedig szvsz szoftver UI szinten kellene, hogy eldőljön, nem pedig SQL szinten (röhejes is lenne).
Másik lehetőség, hogy rosszul tetted fel a kérdést, és totál félreértettelek.
-
Félreértettél, de a kérdés egyértelműen a tárolásra vonatkozott, hogy hogyan.
Azóta már annyiban változott a terv, hogy nem egysoros tábla lesz, hanem
CalendarYear(year,current) tábla, aminek a sorai egy évszámot és egy logikai értéket fognak tartalmazni, ezt szintén az admin tölti fel és utána ő választja ki a current értéket.
Lehet, hogy lesz még egy külön tábla is, ami logolja az eseményeket, de az egyáltalán nem biztos, hogy kelleni fog -
Így van, de ez jogosultság kérdés. Az adattárolás nem kérdés (a mezőt tárolod valahol). Csak az a kérdés, hogy bizonyos jogosultsággal bíró felhasználók tudjanak egy adott mezőn módosítani. Ez pedig szvsz szoftver UI szinten kellene, hogy eldőljön, nem pedig SQL szinten (röhejes is lenne).
Másik lehetőség, hogy rosszul tetted fel a kérdést, és totál félreértettelek.
Félreértettél, de a kérdés egyértelműen a tárolásra vonatkozott, hogy hogyan.
Azóta már annyiban változott a terv, hogy nem egysoros tábla lesz, hanem
CalendarYear(year,current) tábla, aminek a sorai egy évszámot és egy logikai értéket fognak tartalmazni, ezt szintén az admin tölti fel és utána ő választja ki a current értéket.
Lehet, hogy lesz még egy külön tábla is, ami logolja az eseményeket, de az egyáltalán nem biztos, hogy kelleni fog -
Sziasztok,
Az adatbázisomban el kell mentenem a jövőben egy évszámot, amelyet majd az admin jogú felhasználók tudnak megváltoztatni, és a lekérdezések meg annak megfelelő évszámmal ellátorr adatokat fognak visszadni.
Ezért egy olyan speciális tábla létrehozására gondoltam, ami egy soros, és egy attribútuma van, az évszám, amit majd az adminok írhatnak felül. Admin(year)
Mi a véleményetek?
Köszönettel,
W. -
A return-nek fontos szerepe lehet, pl. elágazásoknál, hibakezeléseknél.
A példakódban így ebben a formájában semmi értelme nincs, bár ártani nem árt legalábbÉrtem, köszi.Igen, én is azt olvastam mint te. Hibakódoknál, egyszerű értéknél. De így simában nem értettem miért van ott. Nem is nagyon találtam leírást sem így egyszerű Return-re.
-
Sziasztok,
Az adatbázisomban el kell mentenem a jövőben egy évszámot, amelyet majd az admin jogú felhasználók tudnak megváltoztatni, és a lekérdezések meg annak megfelelő évszámmal ellátorr adatokat fognak visszadni.
Ezért egy olyan speciális tábla létrehozására gondoltam, ami egy soros, és egy attribútuma van, az évszám, amit majd az adminok írhatnak felül. Admin(year)
Mi a véleményetek?
Köszönettel,
W. -
Tárolt eljárások.
A Return-t nem értem benne. Okés, hogy egyszerű értéket adok vissza (return a value) meg az output, de amikor egy select lekérdezést (tábla lekérdezést) és látok a végén egy Return-t akkor nem már nem értem.
Példa kódban láttam (platform mssql)Return-os példa:
PROCEDURE [dbo].[spGetVendorAddress]
(@VendorID int)
AS
SELECT VendorID, Name, Address1, Address2, City, State, ZipCode
FROM Vendors
WHERE VendorID = @VendorID
RETURNÉs ez:
PROCEDURE [dbo].[spGetVendorByID]
(
@VendorID int
)
AS
SET NOCOUNT ON;
SELECT VendorID, Name, Address1, Address2, City, State, ZipCode FROM dbo.Vendors
WHERE VendorID = @VendorIDA return-nek fontos szerepe lehet, pl. elágazásoknál, hibakezeléseknél.
A példakódban így ebben a formájában semmi értelme nincs, bár ártani nem árt legalább -
Lacces
őstag
Nem benned van a hiba, örülj neki, hogy normális lekérdezéseket jobban átlátsz.
Amúgy az is kérdés, milyen "alselectekre" gondolsz: van, amikor igazából nem is nagyon lehet másképp megoldani egy ilyet, vagy nehézkes, és most ne kérd, hogy azonnal mondjak neked ilyen példát, mert nem jut eszembe.
Gyakorlatban jönne elő.Más: úgy tudom, MySQL-t használsz, ebben az esetben ezt ajánlom az egyszerűbbek közt viszonylag összetettebb (na, szóval érted
) lekérdezések elkészítésére: dbForge Studio for MySQL. Szerintem nagyon hasznos tud lenni, amikor az embernek hirtelen a fáradtságtól vagy a pillanatnyi elmezavartól a neve sem jut eszébe, nem hogy egy picit is összetettebb query. 
Van ilyen, ilyenkor jól jön egy grafikus alapú query-összedobálós program, ami meglepő módon egyáltalán nem gyárt gány kódot. Most ez persze elsősorban a JOIN-okra vonatkozik, nem arra, amikor mondjuk durvább query-d van, meg temporary táblák sora van több "alselectben", stb., tehát azért még mindig a viszonylag egyszerű query-k összerakására kell gondolni. -
Sk8erPeter
nagyúr
akkor mégiscsak rá kell feküdnöm az alselectekre
. Annyi baj legyen. (lehet bennem volt a hiba, a join-okat jobban átláttam mindig mint a beágyazott selecteket) és kösz! Nem benned van a hiba, örülj neki, hogy normális lekérdezéseket jobban átlátsz.
Amúgy az is kérdés, milyen "alselectekre" gondolsz: van, amikor igazából nem is nagyon lehet másképp megoldani egy ilyet, vagy nehézkes, és most ne kérd, hogy azonnal mondjak neked ilyen példát, mert nem jut eszembe. Gyakorlatban jönne elő.Más: úgy tudom, MySQL-t használsz, ebben az esetben ezt ajánlom az egyszerűbbek közt viszonylag összetettebb (na, szóval érted
) lekérdezések elkészítésére: dbForge Studio for MySQL. Szerintem nagyon hasznos tud lenni, amikor az embernek hirtelen a fáradtságtól vagy a pillanatnyi elmezavartól a neve sem jut eszébe, nem hogy egy picit is összetettebb query. Van ilyen, ilyenkor jól jön egy grafikus alapú query-összedobálós program, ami meglepő módon egyáltalán nem gyárt gány kódot. Most ez persze elsősorban a JOIN-okra vonatkozik, nem arra, amikor mondjuk durvább query-d van, meg temporary táblák sora van több "alselectben", stb., tehát azért még mindig a viszonylag egyszerű query-k összerakására kell gondolni. -
Lehet picivel több gyakorlatom van MSSQL-ben, mint a tanárodnak. Másrészt oktatási szempontból a beágyazott select jobb, mert átláthatóbb, párszáz adatsornál a rosszabb futásidők nem is jönnek ki igazán. Viszont több tízmillió soros táblákat próbálj meg alselectekkel lekérdezni
akkor mégiscsak rá kell feküdnöm az alselectekre
. Annyi baj legyen. (lehet bennem volt a hiba, a join-okat jobban átláttam mindig mint a beágyazott selecteket) és kösz! -
Most egy Isten vagy a szememben!
Suliban a tanár folyton a beágyazott selecteket erőltette... Most meg majd dörgölhetem az orra alá, hogy JOIN hatékonyabbLehet picivel több gyakorlatom van MSSQL-ben, mint a tanárodnak. Másrészt oktatási szempontból a beágyazott select jobb, mert átláthatóbb, párszáz adatsornál a rosszabb futásidők nem is jönnek ki igazán. Viszont több tízmillió soros táblákat próbálj meg alselectekkel lekérdezni
-
Apollo17hu
őstag
hmmmm...
hát ebbe a szutyok access-be nekem ez sem futott le csak union-nal így:select nev
from tanulo
where nev like 'a*'
union
select nev
from tanulo
where nev like 'k*'
union
select nev
from tanulo
where nev like 's*'
union
select nev
from tanulo
where nev like 'b*' ;nah de a lényeg hogy megvan, köszönöm a helpet.
szörnyű hogy egy egyszerű lekérdezéshez is regényt kell írni, mert alig ismeri a fügvényeket... 
no comment... -
miért nem engedi? azért mert nem tudja/nem így ismeri
Accessben
% helyett *-ot kell használni
_ helyett #-t
[..] pedig egyszerűen nincs (ilyen egyként is csak MS SQL Serverben van)select *
from tanulo
where
nev like 'a*'
or nev like 'k*'
or nev like 's*
or nev like 'b*';persze mindezt csak egy 1 perces google keresésre alapozom, és lehet tévedek...
hmmmm...
hát ebbe a szutyok access-be nekem ez sem futott le csak union-nal így:select nev
from tanulo
where nev like 'a*'
union
select nev
from tanulo
where nev like 'k*'
union
select nev
from tanulo
where nev like 's*'
union
select nev
from tanulo
where nev like 'b*' ;nah de a lényeg hogy megvan, köszönöm a helpet.
szörnyű hogy egy egyszerű lekérdezéshez is regényt kell írni, mert alig ismeri a fügvényeket... no comment... -
sziasztok!
egy kis segítségre volna szükségem, jövőhéten vizsgázom sql-ből Access 2010-ben. a kérdésem csupán annyi lenne hogy miért nem engedi a legtöbb maszkolási karaktert használni?? Adott egy marha egyszerű lekérdezés pl:
SELECT *
FROM tanulo
WHERE nev LIKE '[aksb]%';de a válsz egy üres etábla.
A * fut, na de az édes kevés egy jól megfogalmazott lekérdezéshez....
Valakinek esetleg lenne valami ötlete hogyan bírhatnám rá a "Microsoft nevű állatját" hogy működjenek a lekérdezéseim?? Nagyon megköszönném -
Sziszmisz
csendes tag
sziasztok!
egy kis segítségre volna szükségem, jövőhéten vizsgázom sql-ből Access 2010-ben. a kérdésem csupán annyi lenne hogy miért nem engedi a legtöbb maszkolási karaktert használni?? Adott egy marha egyszerű lekérdezés pl:
SELECT *
FROM tanulo
WHERE nev LIKE '[aksb]%';de a válsz egy üres etábla.
A * fut, na de az édes kevés egy jól megfogalmazott lekérdezéshez....
Valakinek esetleg lenne valami ötlete hogyan bírhatnám rá a "Microsoft nevű állatját" hogy működjenek a lekérdezéseim?? Nagyon megköszönném -
ezt úgy értsd, mintha egy join lenne, csak csúnyább, futásidőben rosszabb, viszont sokszor kényelmesebb, és néha tényleg pont erre van szükség.
Igen, látok most már JOIN-os átírásokat rá... csak, fúúúj
Illetve megkérdezhetem, hogy milyen esetekben van erre szükség?
Lehet erre a részre akkor jobban rá kell feküdnöm
-
Egy magyarázatot kérnék. A correlated subquery, vagy összefüggő select (talán így van magyarul) elmagyarázását szeretném valakitől megkapni
Beágyazott Select-eket értem. De itt a WHERE feltétel rész miatt elakadok, hogy mi hogy van...
Nem igazán fogtam fel a működését.SELECT VendorID, InvoiceTotal
FROM Invoices AS inv_main
WHERE InvoiceTotal >
(SELECT AVG(InvoiceTotal)
FROM Invoices AS inv_sub
WHERE inv_sub.VendorID = inv_main.VendorID)
ORDER BY VendorID, InvoiceTotal
Látom a leírást is hogy ciklusként működik, látom is a végeredményt.
Örülnék egy egyszerű példának magyarázatnak. -
Lacces
őstag
Egy magyarázatot kérnék. A correlated subquery, vagy összefüggő select (talán így van magyarul) elmagyarázását szeretném valakitől megkapni
Beágyazott Select-eket értem. De itt a WHERE feltétel rész miatt elakadok, hogy mi hogy van...
Nem igazán fogtam fel a működését.SELECT VendorID, InvoiceTotal
FROM Invoices AS inv_main
WHERE InvoiceTotal >
(SELECT AVG(InvoiceTotal)
FROM Invoices AS inv_sub
WHERE inv_sub.VendorID = inv_main.VendorID)
ORDER BY VendorID, InvoiceTotal
Látom a leírást is hogy ciklusként működik, látom is a végeredményt.
Örülnék egy egyszerű példának magyarázatnak. -
kezdjük azzal, hogy mit szeretnél lekérdezni
folytassuk azzal, hogy a SUM az oszlopfüggvény, tehát nem tudsz olyat mondani, hogyselect oszlop1, sum(oszlop2) from tabla1
mert a select oszlop1 több 'sort' ad vissza, a sum(oszlop2) viszont 1 darab értéket, és ez a kettő nem fér össze
a hibaüzenet mondja is a megoldást, ilyen esetben group by-olni kell
Aham, köszönöm, pont azt akartam kérdezni amit te írtál, vagy is ahogy írtad az úgy jó
A GROUP BY-t melyik oszlopra kell kiadnom? Ezt próbáltam. De ugyanúgy jött a hiba. Hmm..
Jó meg van, működik, egyszerű példára megnéztem! És jó! A nem SUM-ra kell, okés. Tegnap próbálkoztam vele de akkor valamiért nem jött össze, lehet az álmosság
Köszönöm így felfogtam ezt a rejtélyt!
-
Ilyen parancsot sem tud lefutatni... Már amit tegnap tudott, azt már nem tudja...
A SUM-os résszel van a baj... A feladat azt írja, hogy írja, hogy InvoiceTotal minus Sum of PaymentTotal and CreditTotal
A SUMos részen kívül a többi jó!
SELECT v.VendorName, i.InvoiceNumber, i.InvoiceDate,
i.InvoiceTotal-SUM(i.PaymentTotal)+SUM(i.CreditTotal)As BalanceDue
FROM Vendors as v Join Invoices as i on
v.VendorID= i.VendorID
ORDER BY VendorNameHoppá! Most nézem csak... A fent említett 3 oszlop nem is int, hanem money típus!
Hogy kellene a SUM-os részt átírnom?
SZERK: Lehet én értelmezem félre az egész angol szöveget és valójában erre gondolhattak volna: invoiceTotal -- (PaymentTotal + CreditTotal)
-
Ilyen parancsot sem tud lefutatni... Már amit tegnap tudott, azt már nem tudja...
A SUM-os résszel van a baj... A feladat azt írja, hogy írja, hogy InvoiceTotal minus Sum of PaymentTotal and CreditTotal
A SUMos részen kívül a többi jó!
SELECT v.VendorName, i.InvoiceNumber, i.InvoiceDate,
i.InvoiceTotal-SUM(i.PaymentTotal)+SUM(i.CreditTotal)As BalanceDue
FROM Vendors as v Join Invoices as i on
v.VendorID= i.VendorID
ORDER BY VendorNameHoppá! Most nézem csak... A fent említett 3 oszlop nem is int, hanem money típus!
Hogy kellene a SUM-os részt átírnom?
SZERK: Lehet én értelmezem félre az egész angol szöveget és valójában erre gondolhattak volna: invoiceTotal -- (PaymentTotal + CreditTotal)
-
Sk8erPeter
nagyúr
Tudom,hogy igazatok van,csak ez egy kész cms.Minden php-val van megcsinálva(ahhoz nem értek) úgyhogy nem szívesen piszkálnék bele.Talán kaphatnék egy egyszerű php kódot,amita cms-től függetlenül a feladatütemezővel naponta lefuttathatok.
Az adatbázis neve e107
a tábla neve: e107_user_extended
A mező neve:user_kora
Felhasználó név: e107
Jelszó:e107
Host:localhost"csak ez egy kész cms.Minden php-val van megcsinálva"
És akkor mi van?
A Drupal is egy kész CMS, attól még modulokat lehet írni hozzá, ami a saját céljaidnak megfelelően jelenít meg adatokat.
Egyébként meg egyáltalán nem értem, hogy Te ezek szerint egy plusz lekérdezéssel, UPDATE-tel ki tudtad egészíteni az e107 működését, akkor miért ne tudnád annyival is, hogy miután már a felhasználó születési dátuma el van tárolva, ebből egy egyszerű lekérdezéssel megjeleníted az aktuális korát? Így legalább ütemezett update-ekre sem lenne szükség...
Szerintem valamit félreértesz az itt javasoltakból. A lényege, hogy ugye a születési dátumod nem túl sokszor változik jó esetben - ebből az adatból pedig "on-the-fly" bármikor ki lehet számolni az aktuális életkort, nem kell hozzá még PHP sem, elég MySQL-ből kiszámolni.Egyébként meg martonx már mondta, de az e107 már régóta elavult, azóta más felhasználóbarát CMS-ek is bőven vannak.
Én mondjuk a Drupalt ajánlanám, bár azt hallottam, hogy a Wordpress kezdőknek ideális választás (vagy azoknak, akik haladók, és ezt jobban ismerik). Haladók a Drupal moduljaival is gyorsan elboldogulnak némi help olvasgatása után. -
Sk8erPeter
nagyúr
Anno én is egy OKJs suliba jártam. 1-2 tantárgy volt, amit normálisan oktattak. Az oktatás minősége, meg szerintem azért is rossz, mert az osztály 10%-20% százaléka, akit tényleg érdekel az oktatás, ezáltal előbb-utóbb a tanárok is így állnak az oktatáshoz.
Ezért, ha csak annyit tanultam volna meg, amit ott leadnak, sose jutottam volna semmire.
Volt bizonyos fokú előképzettségem, oracle és java plusz órákra jártam, egyetemi online ingyenes kurzusokon vettem részt és otthon is foglalkoztam a dolgokkal: netes anyagokból mysql-php kombóval képeztem magam.
Így jutottam valamire. -
Lacces
őstag
Ilyen parancsot sem tud lefutatni... Már amit tegnap tudott, azt már nem tudja...
A SUM-os résszel van a baj... A feladat azt írja, hogy írja, hogy InvoiceTotal minus Sum of PaymentTotal and CreditTotal
A SUMos részen kívül a többi jó!
SELECT v.VendorName, i.InvoiceNumber, i.InvoiceDate,
i.InvoiceTotal-SUM(i.PaymentTotal)+SUM(i.CreditTotal)As BalanceDue
FROM Vendors as v Join Invoices as i on
v.VendorID= i.VendorID
ORDER BY VendorNameHoppá! Most nézem csak... A fent említett 3 oszlop nem is int, hanem money típus!
Hogy kellene a SUM-os részt átírnom?
SZERK: Lehet én értelmezem félre az egész angol szöveget és valójában erre gondolhattak volna: invoiceTotal -- (PaymentTotal + CreditTotal)
-
Pedig ez nálam simán működik (MSSQL 2008R2 Express):
create table #t (ertek1 int, ertek2 int)
insert into #t values (1,1)
insert into #t values (3,1)
insert into #t values (1,3)
insert into #t values (2,4)select SUM(ertek1 + ertek2) from #t
Inkább olyanra tudok gondolni, hogy szemetesek az adataid (mondjuk null van köztük), és ez okozza a problémát.
Én is ugyanezt a rendszert használom
2008R2, meg intes táblák...
Furcsa, majd ahogy haladok a tanulásával meglátom.
Kívonás működik... csak az összeadás nem. (nincsenek benne nullák).-Zeratul- Köszönöm neked is mennie kéne de mindegy, csak a könyv feladatsor részében volt ilyen, hogy adjak össze 2 oszlopot. Tanulmányaim során sem találkoztam ilyennel, hogy két oszlopot összeadni
Köszönöm a válaszokat!
-
Sziasztok!
Most tanulom az MSSql-t ez egy fantasztikus. Lennem kérdésem a Sum függvénnyel kapcsolatban, hogy ez tényleg nem támogatja az összeadást?
pl.: SUM( oszlop1+ oszlop2) -> nem fordul le, nem támogatja, nekem ezt írja ki.
de SUM(oszlop1- oszlop2) -> lefordul... Harmadiknak még én fordulok le a székről...Mert elég érdekes ezt használni-> SUM(oszlop1) + SUM(oszlop2) + SUM(oszlop3) -> így okés neki.
-
Sziasztok!
Most tanulom az MSSql-t ez egy fantasztikus. Lennem kérdésem a Sum függvénnyel kapcsolatban, hogy ez tényleg nem támogatja az összeadást?
pl.: SUM( oszlop1+ oszlop2) -> nem fordul le, nem támogatja, nekem ezt írja ki.
de SUM(oszlop1- oszlop2) -> lefordul... Harmadiknak még én fordulok le a székről...Mert elég érdekes ezt használni-> SUM(oszlop1) + SUM(oszlop2) + SUM(oszlop3) -> így okés neki.
-
Lacces
őstag
Sziasztok!
Most tanulom az MSSql-t ez egy fantasztikus. Lennem kérdésem a Sum függvénnyel kapcsolatban, hogy ez tényleg nem támogatja az összeadást?
pl.: SUM( oszlop1+ oszlop2) -> nem fordul le, nem támogatja, nekem ezt írja ki.
de SUM(oszlop1- oszlop2) -> lefordul... Harmadiknak még én fordulok le a székről...Mert elég érdekes ezt használni-> SUM(oszlop1) + SUM(oszlop2) + SUM(oszlop3) -> így okés neki.
-
postgresql dump-jat ra tudom-e venni valahogy, hogy rendezve mentse a tablaban levo adatokat?
van egy tablam, amiben egy fat tarolok, s a szulo mezo foreign key a tabla id mezojere
a gond az, hogy a dump random (ha minden igaz, akkor aszerint, ahogyan a lemezen fizikailag tarolva van az adat) sorrendben menti a sorokat, es igy elofordul (eleg sokszor), hogy a mentett adatokat csak kezi rendezes utan tudom importalni az adatbazisba (mert olyan sort akar beszurni, ahol a szulohoz tartozo id-ju sor meg nincs az adatbazisban) -
Ember, te háttal ülsz a lovon. Ha a PHP-be nem piszkálsz bele, lehet neked akárhány extra oszlopod, a jóisten se fogja azt megjeleníteni.
Javaslatom:
Dobd ki az e107-et. CMS-ből drupal, joomla, de leginkább a wordpress a nyerő. Ha nem vagy nagy php guru,akkor pláne a wordpresst javaslom. Csúnya, egyszerű kódja van, nagyon jó dokumentációkkal, ergo baromi könnyű plugint fejleszteni hozzá.Ettől még kelleni fog az SQL módosítás, de az majdcsak a PHP pluginnel együtt fog bármit érni. Mysql topikba beleírtam a megoldást (ha már CMS, akkor a triggeres megoldást preferálnám az általam felvetett javaslatok közül).
Megvan a helyes kód:
<?php
$db_host = "localhost";
$db_username = "e107";
$db_pass = "e107";
$db_name = "e107";mysql_connect($db_host, $db_username, $db_pass);
mysql_select_db($db_name);
mysql_query("UPDATE e107_user_extended SET user_kora=floor(DATEDIFF(now(),user_birthday)/365.2425)");
?>
Kösönöm mindenkinek a segítséget.A feladat ütemezve,így naponta frissíti a kor mezőt. -
Ember, te háttal ülsz a lovon. Ha a PHP-be nem piszkálsz bele, lehet neked akárhány extra oszlopod, a jóisten se fogja azt megjeleníteni.
Javaslatom:
Dobd ki az e107-et. CMS-ből drupal, joomla, de leginkább a wordpress a nyerő. Ha nem vagy nagy php guru,akkor pláne a wordpresst javaslom. Csúnya, egyszerű kódja van, nagyon jó dokumentációkkal, ergo baromi könnyű plugint fejleszteni hozzá.Ettől még kelleni fog az SQL módosítás, de az majdcsak a PHP pluginnel együtt fog bármit érni. Mysql topikba beleírtam a megoldást (ha már CMS, akkor a triggeres megoldást preferálnám az általam felvetett javaslatok közül).
-
Tudom,hogy igazatok van,csak ez egy kész cms.Minden php-val van megcsinálva(ahhoz nem értek) úgyhogy nem szívesen piszkálnék bele.Talán kaphatnék egy egyszerű php kódot,amita cms-től függetlenül a feladatütemezővel naponta lefuttathatok.
Az adatbázis neve e107
a tábla neve: e107_user_extended
A mező neve:user_kora
Felhasználó név: e107
Jelszó:e107
Host:localhost -
Tudom,hogy igazatok van,csak ez egy kész cms.Minden php-val van megcsinálva(ahhoz nem értek) úgyhogy nem szívesen piszkálnék bele.Talán kaphatnék egy egyszerű php kódot,amita cms-től függetlenül a feladatütemezővel naponta lefuttathatok.
Az adatbázis neve e107
a tábla neve: e107_user_extended
A mező neve:user_kora
Felhasználó név: e107
Jelszó:e107
Host:localhost -
-
Megnéztem az általad ajánlottakat:
Az első megoldásra te is írtad,hogy miért nem jó.Sajnos a második sem: e107 cms-el dolgozok,ez php alapokon működik,amihez még nem nagyon értek,de úgy gondolom,mivel az eredeti táblát használja a rendszer(regisztráció,belépés,keresés,adatváltozás) így minden feltöltés és lekérdezés onnan történik.így egy másolat táblának egy plussz oszloppal(amire kell,azt megcsinálja) nem sok hasznát veszem. Olyan megoldás kell,ami az eredeti táblába szúr egy mezőt,ami a születési dátum alapján automatikusan beirja a felhasználó korát.Esetleg ezt a selectes vértékmegadást mező létrehozásnál nem lehet valahogy használni? -
ALTER TABLE user ADD user_kor INT;
UPDATE user SET user_kor = floor(DATEDIFF(now(), birthdate)/365.2425);De ez tök fölösleges, mert egyszer feltöltöd, és aztán frissítheted folyamatosan. Inkább csinálj egy view-t amiben ez az plusz számolt oszlop van:
CREATE VIEW user_korral AS SELECT *, floor(DATEDIFF(now(), birthdate)/365.2425) AS user_kor FROM user;AE
-
Sziasztok.Mysql-es probléma:új oszlopot akarok beszúrni,ami egy meghatározás alapján feltöltődik rekordokkal. Pontosabban:Van egy user táblám,benne egy születési dátum mező.Az új oszlop amit létrehoznék az 'user_kor' mező.A cél az,hogy a születési dátumból kiszámolva automatikusan kitöltődjön a mező.A függvény megvan:
floor(DATEDIFF(now(), birthdate)/365.2425)
Akkor:
ALTER TABLE user ADD user_kor INT 'hogyan tovább?'
A segítségeteket előre is köszi. -
Anno én is egy OKJs suliba jártam. 1-2 tantárgy volt, amit normálisan oktattak. Az oktatás minősége, meg szerintem azért is rossz, mert az osztály 10%-20% százaléka, akit tényleg érdekel az oktatás, ezáltal előbb-utóbb a tanárok is így állnak az oktatáshoz.
Ezért, ha csak annyit tanultam volna meg, amit ott leadnak, sose jutottam volna semmire.
Volt bizonyos fokú előképzettségem, oracle és java plusz órákra jártam, egyetemi online ingyenes kurzusokon vettem részt és otthon is foglalkoztam a dolgokkal: netes anyagokból mysql-php kombóval képeztem magam.
Így jutottam valamire. -
ArchElf
addikt
Ezt bírom egyébként az ilyen sulis "webmester"-kurzusokban - legalábbis az alapján, amiket eddig hallottam, illetve olvastam (és ez is megerősíti) -, hogy mindenen átrohannak, mint egy őrült, az alapok normális lefektetése nélkül, hogy ebből is, abból is legyen egy kicsi, mindenből csipegetünk valamennyit, de pont annyit, hogy lehetőleg a diák egy árva szót ne értsen az egészből, és ne tudja összerakni, hogy most akkor mi a szar is ez az egész, ha önszorgalomból nem fekszik rá keményen.
Azt nem értem, miért nem építenek fel egy logikus struktúrát (nyilván naiv felvetés, de annyira azért nem földtől elrugaszkodott elképzelés). Legyenek ezek a nyelvek elkülönítve, ne ömlesztve tanuljanak mindent, hanem tematikusan, de akkor már legalább az alapok normális lefektetése után. Az még mindig többet ér, ha valaki kevesebb nyelvbe kóstol bele, de legalább azt biztosan tudja. Így a későbbi nyelveknél is esélyes, hogy jobban át fogja látni a logikáját az egésznek. Ha kevés az idő, akkor egyszerű a megoldás: kevesebb dolgot kell jobban átvenni, nem minden-mindegy alapon ömleszteni a trágyát a diák fejére.Szerk.: OFF.
Szerintem 20-30 óra alatt így lehet leadni (főleg olyanoknak, akiknek semmilyen tematikus előképzettségük nincs). Sokat gondolkodtam egy-két ilyen kurzuson, de mindig lemondtam róla amiatt, hogy a hallgatóság nagy része csak lelkes szerencsevadász lesz, tárgyi tudás nélkül. Ilyen körülmények között semmi tisztességes tudát nem lehet átadni/átvenni
AE
-
PazsitZ
addikt
Ezt bírom egyébként az ilyen sulis "webmester"-kurzusokban - legalábbis az alapján, amiket eddig hallottam, illetve olvastam (és ez is megerősíti) -, hogy mindenen átrohannak, mint egy őrült, az alapok normális lefektetése nélkül, hogy ebből is, abból is legyen egy kicsi, mindenből csipegetünk valamennyit, de pont annyit, hogy lehetőleg a diák egy árva szót ne értsen az egészből, és ne tudja összerakni, hogy most akkor mi a szar is ez az egész, ha önszorgalomból nem fekszik rá keményen.
Azt nem értem, miért nem építenek fel egy logikus struktúrát (nyilván naiv felvetés, de annyira azért nem földtől elrugaszkodott elképzelés). Legyenek ezek a nyelvek elkülönítve, ne ömlesztve tanuljanak mindent, hanem tematikusan, de akkor már legalább az alapok normális lefektetése után. Az még mindig többet ér, ha valaki kevesebb nyelvbe kóstol bele, de legalább azt biztosan tudja. Így a későbbi nyelveknél is esélyes, hogy jobban át fogja látni a logikáját az egésznek. Ha kevés az idő, akkor egyszerű a megoldás: kevesebb dolgot kell jobban átvenni, nem minden-mindegy alapon ömleszteni a trágyát a diák fejére.Szerk.: OFF.
Anno én is egy OKJs suliba jártam. 1-2 tantárgy volt, amit normálisan oktattak. Az oktatás minősége, meg szerintem azért is rossz, mert az osztály 10%-20% százaléka, akit tényleg érdekel az oktatás, ezáltal előbb-utóbb a tanárok is így állnak az oktatáshoz.
Ezért, ha csak annyit tanultam volna meg, amit ott leadnak, sose jutottam volna semmire.
Volt bizonyos fokú előképzettségem, oracle és java plusz órákra jártam, egyetemi online ingyenes kurzusokon vettem részt és otthon is foglalkoztam a dolgokkal: netes anyagokból mysql-php kombóval képeztem magam.
Így jutottam valamire. -
martonx
veterán
Ezt bírom egyébként az ilyen sulis "webmester"-kurzusokban - legalábbis az alapján, amiket eddig hallottam, illetve olvastam (és ez is megerősíti) -, hogy mindenen átrohannak, mint egy őrült, az alapok normális lefektetése nélkül, hogy ebből is, abból is legyen egy kicsi, mindenből csipegetünk valamennyit, de pont annyit, hogy lehetőleg a diák egy árva szót ne értsen az egészből, és ne tudja összerakni, hogy most akkor mi a szar is ez az egész, ha önszorgalomból nem fekszik rá keményen.
Azt nem értem, miért nem építenek fel egy logikus struktúrát (nyilván naiv felvetés, de annyira azért nem földtől elrugaszkodott elképzelés). Legyenek ezek a nyelvek elkülönítve, ne ömlesztve tanuljanak mindent, hanem tematikusan, de akkor már legalább az alapok normális lefektetése után. Az még mindig többet ér, ha valaki kevesebb nyelvbe kóstol bele, de legalább azt biztosan tudja. Így a későbbi nyelveknél is esélyes, hogy jobban át fogja látni a logikáját az egésznek. Ha kevés az idő, akkor egyszerű a megoldás: kevesebb dolgot kell jobban átvenni, nem minden-mindegy alapon ömleszteni a trágyát a diák fejére.Szerk.: OFF.
-
Sk8erPeter
nagyúr
-
Miért lenne komolyabb?
Eddig az adatbázisban lévő adatokat maga az access "mutogatta". Ezután meg készítesz egy webes felületet, és az mutogatja az adatbázisban lévő adatokat.
Sarkítva annyi a különbség, hogy itt nem lesz lekérdezés varázsló, meg űrlapkészítő segéd -
A PHP-nak és az SQL-nek az ég világon semmi köze nincs egymáshoz. Lehet együtt alkalmazni őket, meg vannak kész modulok sql kezeléshez a php-ban, de a kettő teljesen külön világ.
Feküldj rá először azSQL-readatbáziskezelésre:
- Relációs adatbázis-modell alapok
- Adatbázis, tábla, mező, rekord, adat-kapcsolat
- Normalizálás
- Adatbázis műveletek (adat lekérdezés, adat módosítás, struktúra szerkesztés)
- SQL alap szintaktika (ansi sql)
Ha mindezekkel megvagy, akkor kezdjél el foglalkozni a php-s sql modulokkal és szerver-típus specifikus sql utasítások megértésével.Ha nem találsz a fentiekhez könyvet (bár könyvtárban biztos van adatbáziskezelés alapjaival foglalkozó könyv), akkor is a net tele van ezekkel, csak írd be az összes fenti témakört a google-ba...
AE
-
Szia!
Szerintem ha ennyire nem tudod miről van szó, akkor ideje lenne talán egy könyvet elolvasni.
A fórumok nem arra valóak, hogy megtanulják helyetted a cuccot.
Ha van konkrét kérdésed, akkor arra biztos szívesen válaszol valaki, de most kb azt kéred, hogy magyarázzuk el neked, amit eddig magyaráztak neked a tanfolyamon. -
Sziasztok!
Járok egy felnőtt suliba ahol már megszereztem két rendszergazdai szakmát és most készülünk a harmadikra aminek a neve webmester. Csináltunk weboldalt HTML-ben az még ment is de most elérkeztünk az SQL-hez és a PHP-hoz ahol teljes mértékben elvesztettem a fonalat és 1 hét múlva dolgozatot írunk belőle.
Igazából még kérdezni sem tudok, mert az egészről fogalmam nincs hogy melyiket mikor és miért használjuk, hogy függ össze, egy weboldalnál miért jó stb.Tudna nekem segíteni valaki?
Annyi még, hogy a suliban az Xampp-ot használjuk, de rről is csak annyit tudok, hogy egy virtuális server.
Köszi.
-
Oracle-ül nem tudok, de a megvalósítás elvi alapja bármilyen SQL-en (már amelyik ismeri a join-t):
1. csinálsz egy táblát, amibe belerakod 3 évre visszamenőleg az összes napot. Ha már csinálsz egy ilyen táblát, pár évre előre sem árt belerakni a napokat. Esetedben nem kell a munkanapokkal, hétvégékkel, munkaszüneti napokkal foglalkozni, én ettől függetlenül javasolnám, hogy ezeket is kezeld le benne. Ha már rászánod az időt, a későbbiekben még jól jöhet. A szökőévekre azért figyelj oda mindenképpen.
A táblát én úgy csinálnám, hogy beállítok egy kezdő évet, majd while ciklusokkal léptetve az évet, és a napokat, szépen teleinsertálnám a napokkal.
2. A létrejött naptár táblát joinolod a lekérdezendő táblához, mégpedig az alapján, hogy az adott nap közé esik-e az intervallumodnak. Ha több esik közé az is jó (Descarte-szorzat ugye). Az így kapott selectet countozod, groupolod a napokra és voilá.Az 1-es pont szép, elegáns megvalósítása eltarthat egy darabig (SQL guruságtól függően több perctől több óráig), de megéri a fáradtságot, mert utána mindenféle a 2-eshez hasonló okosságra fel tudod használni a naptár tábládat.
Egy trükk Oracle-hez, máshol nem valószínű, hogy működik:
Az alapprobléma az, hogy tulajdonképpen egy folyamatos sorszám halmazt kellene előállítanunk, ami 1-től indul és valameddig tart. Naptár esetén értelemszerűen napokkal, de bármire jó lenne egy ilyen.
Nos, ezt így kell megoldani:SELECT LEVEL cnt FROM dual CONNECT BY LEVEL <= 100;
Ez visszaad egy táblát, amelyben minden rekord egymás után következik és csak sorszám (konkrétan 1-től 100-ig). Ha ezt összekötjük azzal, hogy Oracle-ben (is) a dátumtípus és a numerikus értékek között lehetségesek műveletek és az 1 (egy) pontosan egy napot jelent, már készen is van egy táblánk, ami tetszőleges dátumsort képes megjeleníteni. A tábla csak a memóriában létezik, nem kell tárolni, nagyon gyorsan képezhető, beágyazható, kaphat alias-t, stb., mindent lehet vele csinálni. Pl.:
select
days.next_days,
to_char(days.next_days, 'DAY') name_of_day,
to_char(days.next_days, 'D') day_of_week
from
(SELECT trunc(sysdate) + LEVEL next_days
FROM dual CONNECT BY LEVEL <= 7) days;Kisebb intervallumokra sokkal gyorsabb megoldás, mint a több táblás join.
-
Sk8erPeter
nagyúr
a valaszok stilusa a magyaros.
de ez mar tenyleg ertelmetlen offtopic...
amit en irtam, arra bocsanatot kertem, tema lezarva reszemrol.Nem tudom, te mit értesz "magyaros" alatt.
Saját hülyeségünk miatt másokat okolni (segítek: amit épp csinálsz), na, az lehet, hogy már inkább magyaros. Részemről is lezárva, peace! -
Azazello-
senior tag
"elszoktam a magyar reakcioktol"
Te miről beszélsz?
Milyen érdekes, rajtad kívül más tudott normálisan kérdezni, és kapott is segítséget ebben a topicban és máshol is a PH! fórumain.
Talán mielőtt ujjal mutogatsz másokra, másban keresed a hibát, egy kicsit fordulj magadba, értelmezd (!), amiket írtunk, és gondolkozz el azon, hogy valószínűleg nem véletlenül írtunk annyian egybehangzó véleményt arról, amit kérdeztél (ti. hogy túl nagy téma ahhoz, hogy ezt csak úgy iderittyentsük neked). Elég szomorú, hogy erre így reagáltál, de legalább ezzel bebizonyítottad, hogy semmiféle segítséget nem érdemelsz meg, amíg nem veszel vissza az arcodból. Tudod, ez úgy van, hogy ha én kérek tanácsot, akkor nem nekem nagy a pofám.a valaszok stilusa a magyaros.
de ez mar tenyleg ertelmetlen offtopic...
amit en irtam, arra bocsanatot kertem, tema lezarva reszemrol.
Egész eddig szerveroldali authentikációról és authorizációról beszéltünk - nyilván, mi másról, ha itt webes alkalmazásról van szó? -, hol van itt kliensoldali jogosultságkezelés?
Van ilyen, ilyenkor jól jön egy grafikus alapú query-összedobálós program, ami meglepő módon egyáltalán nem gyárt gány kódot. Most ez persze elsősorban a JOIN-okra vonatkozik, nem arra, amikor mondjuk durvább query-d van, meg temporary táblák sora van több "alselectben", stb., tehát azért még mindig a viszonylag egyszerű query-k összerakására kell gondolni.
. Annyi baj legyen. (lehet bennem volt a hiba, a join-okat jobban átláttam mindig mint a beágyazott selecteket) és kösz! 
szörnyű hogy egy egyszerű lekérdezéshez is regényt kell írni, mert alig ismeri a fügvényeket... 
no comment...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Milyen érdekes, rajtad kívül más tudott normálisan kérdezni, és kapott is segítséget ebben a topicban és máshol is a PH! fórumain.
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- Elképesztő rajt a Forza Horizon 6-nál - Steamen már most népszerűbb elődjénél
- Autós kamerák
- Friss információk és képek a OnePlus új órájáról
- Parci: Milyen mosógépet vegyek?
- Hogy is néznek ki a gépeink?
- BestBuy topik
- Kamionok, fuvarozás, logisztika topik
- Projektor topic
- Óra topik
- További aktív témák...
- GYÖNYÖRŰ MacBook Pro 14" M2 Pro 16 GB - 512 GB GAR ÉS jótállás!
- Intel Core ULTRA 9 285K +32GB 7600MHz Patriot Viper XTREME 5 DDR5 kit! (Bolti ár: kb 600ezer Ft!)
- Lenovo Legion Pro 5 - 16IRX10 - i9 14900HX - RTX 5070 - 32GB - 1TB
- 2000GB Gen5x4 NVMe SSD, 1 év gar GEN V!!! SK Hynix 2048GB PCB01 kb. 14GB/s / 12GB/s
- Lenovo Thinkcentre M710Q MINI PC,i3-7100T,8GB DDR4,256GB SSD,WIN11
- Samsung Galaxy Watch 6 Classic 47mm / e-sim / 16GB / 1Hó garancia
- BESZÁMÍTÁS! Apple iPad Mini 6TH GEN Wifi + cellular 64GB tablet garanciával hibátlan működéssel
- Honor Magic5 Lite / 6/128GB / Kártyafüggetlen / 12Hó Garancia
- Csak kipróbált!!! JONR X1 Max 20000 Pa Automata állomás LiDAR + AI
- Samsung Galaxy S23+ 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest