Új hozzászólás Aktív témák
-
EkSYS
senior tag
úgy néz ki az adatbázis kapocs megvan

-
martonx
veterán
azért szerintem tanulhatóság, fejlesztői hatékonyság szemszögéből nézve van köztük sok különbség. A gyorsaságuk infrastruktúra, illetve framework függő.
Másrészt valóban, ha adott helyen csak PHP-re vannak felkészülve (linux infrastruktúra), akkor ott kár is az ASP.NET-et erőltetni. -
ArchElf
addikt
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
-
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
senior tag
-
Peter Kiss
őstag
Hibrid megoldást kell választani: felhőben fut, de az, amit egyszer lekért a user, már a telefonon lesz cache-elve, nem fog változni. Utána csak az időnkénti frissítést kell megoldani. (Van kapcsolat, elmegy az alkalmazás a felhőjébe, megkérdezi, van-e update, ha igen, update-eli a letöltött cuccot, ha nincs, akkor szuszá.)
-
martonx
veterán
iránymutatást kértél én nulla időráfordítással adtam. Azt ne kérd, hogy bárki bármennyi időt is elkezdjen rászánni az adatbázis optimalizálásra.
Az teljesen biztos, akár mérget is vennék rá, hogy 500Kb-ba nem fog beleférni 3,5 millió adatbázis sor, bárhogy tömöríted is.
Inkább úgy sejtem, hogy ahhoz, hogy két célpont között javasolj valamit, a meglévő db 90%-át simán ki lehet dobni, és 1-2 db pár száz soros táblára szűkíteni a lényeget. -
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. -
Lacces
őstag
Egy jó kis link a problémámra, és amúgy is nagyon jónak látom
Ez csak berakom ide, mint tudásbázis. Ha esetleg más is jön ilyen dologgal (szerintem angol nyelven ez egy remek tutorial, a tervezéssel és elmélettel kapcsolatban!) 15 részt megéri átnézni ahogy nézegettem.
Sőt konkrét példákkal magyaráz el. A sörös tábla az jó, így értettem. Sec-perc alatt értettem innen.
Másik gépen van adatbázis tervezési példák (bankos, webshop, közösségi oldal stb). Ha nem felejtem azt is lehet belinkelem.
-
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.
-
martonx
veterán
válasz
#65304576
#977
üzenetére
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. -
#65304576
törölt tag
válasz
Sk8erPeter
#976
üzenetére
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). -
Sk8erPeter
nagyúr
válasz
#65304576
#975
üzenetére
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. -
#65304576
törölt tag
válasz
Sk8erPeter
#974
üzenetére
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.
-
martonx
veterán
vegyünk egy táblát, aminek van 10 mezője. De ebből az átlag user csak 9-et tudjon módosítani, a 10-diket ne.
Namost ezt meg lehet úgy oldani, hogy a programba/weboldalra belépéskor be kell jelentkezni, és ennek függvényében az átlag user 9 mezőt lát, az admin 10-et. Vagy az átlag user is 10-et lát, de a 10-ediket az UI nem engedni neki módosítani. Szép, elegáns könnyű megoldás, egy darab táblával néhány sor kóddal.
És meg lehet valósítani úgy is, hogy ugyanígy be kell jelentkezni, mindenki lát mindent, az UI enged mindenkinek mindent, csak éppen hátulról az adatbázis szét van hekkelve, azért hogy a 10-edik mezőt csak az admin userek tudják módosítani. UI szinten kb. nem nyersz semmit (1-2 sor kódot) ezzel a megoldással, DB szinten meg a fentebb vázolt megoldáshoz képest agyonszívatod magad. Szvsz röhejes, így megoldani valamit. Viszont lehet van olyan együttállása a környezeteknek, amikor erre a második esetre van szükség, csak én nem tudom elképzelni. Ezért is bátorkodtam megkérdezni, hogy mi visz rá valakit erre a megoldásra? -
wolandino
tag
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
-
martonx
veterán
válasz
wolandino
#968
üzenetére
Í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.
-
wolandino
tag
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. -
Lacces
őstag
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 = @VendorID -
Lacces
őstag
válasz
Sk8erPeter
#960
üzenetére
Köszi. Alselect az correlated subquery angolul
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, InvoiceTotalDe amíg a tanár azt mondja, hogy beágyazott select, addig az angol könyv subquery-nek írja...
MySQL-t is használok, de ilyen bonyolultan nem. Meg most egy picit a php+mysql kombót is hanyagolom. De blog oldal létrehozva, csak így magamnak értem is, hogy mi merre van. Azt majd folytatom. Csak a helyi cégek hát mit ne mondjak, inkább kizsákmányolásra megy rá. Így elkezdtem az MSSQL-t is tanulni, meg hát hosszútávon jobban megéri a Java/.Net vonal.
-
Sk8erPeter
nagyúr
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. -
martonx
veterán
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

-
Sziszmisz
csendes tag
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... -
bpx
őstag
válasz
Sziszmisz
#953
üzenetére
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...
-
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
-
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.
-
Lacces
őstag
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!

-
bpx
őstag
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
-
Sk8erPeter
nagyúr
"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
Ja, hát a diák szempontjából ez a lelkesedés és szorgalom a jó hozzáállás ahhoz, hogy sikeres legyél abban, ami érdekel, a másik oldalról viszont az is tény, hogy ezt az érdeklődést akár meg is lehet teremteni azoknál is, akik korábban nem érdeklődtek az adott témakör iránt, csak ehhez ugye jó tanítási módszerek is kellenek.
Tipikusan a legrosszabb módszer az, hogy rábízzuk a diákra a piszkos melót, tanulja meg ő magától, rengeteg utánanézés és sikertelenség árán, aztán mi meg jól számonkérjük a tudását, és mossuk kezeinket. Az meg a tanár részéről nem mentség, hogy "dehát a diákok többsége úgyis leszarja", mert az ő dolga az, hogy megtanítsa az anyagot, lehetőleg minőségi formában...és erre nem lehet az sem válasz, hogy "dehát a tanár helyetted nem tanulhatja meg az anyagot" (sokszor ilyenkor ez a reflexszerű reakció) - valóban nem, de legalább kedvet és alapot adhat ahhoz, hogy foglalkozz vele, sokan épp az ellenkezőjét teszik ezzel a rohanással.(#919) ArchElf : jaja, egyetértek, sajnos így van. Túl kevés az idő ahhoz, hogy stabil tudást átadjanak. De azzal a módszerrel, hogy tényleg mindent rázúdítanak a diákra, ami nagyjából a webfejlesztés kapcsán első körben igazán fontos lehet, csak rontanak a helyzeten, mert akkor tényleg semmit nem fog átlátni normálisan, amennyiben nem szán a saját idejéből rengeteget arra, hogy megtanulja az anyagot.
-
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)
-
Lacces
őstag
É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!

-
martonx
veterán
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.
-
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.
-
retrox
csendes tag
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. -
retrox
csendes tag
Azért e107,mert sokkal bővebb és felhasználó barát a modulkészlete,s az admin felülete. A skinekről nem is beszélve.Tudom,a legjobb a saját szerkesztés lenne,de még csak első éves webprogos vagyok.Még nincs php,nincsennek scriptek,viszont van html,css,cms,mysql és ey kis c# alap.Ebből kell gazdálkodnom.
-
rt06
veterán
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) -
martonx
veterán
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).
-
rt06
veterán
ha uj adatot akarsz megjeleniteni (marpedig lathatoan azt szeretnel), akkor vagy mindenkepp bele kell piszkalnod a php kodba, vagy ha az e107 ezt lekezeli, egyik esetben sem kell hozzanyulnod
a kulonbseg annyi, hogy egyik esetben (uj mezo, es update), megvaltozik az adattabla, ezert van a lekerdezes eredmwenyeben egy plusz mezo, mig masik esetben (select modositasa) a plusz adat a lekerdezeskor jon letre
ezt a plusz adatot mindenkeppen le kell kezelned, hogy hol, mikent jelenjen meg, fuggetlenul attol, hogy tarolva van-e az adat, vagy on-the-fly szamolod ki -
retrox
csendes tag
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 -
retrox
csendes tag
OK.Elfogadom.Csak azt mondjátok meg nekem,hogy érem el,hogy mondjuk óránként frissíti a mysql ezt:
UPDATE e107_user_extended SET user_kora=floor(DATEDIFF(now(),user_birthday)/365.2425);
vagy hogy kapcsolhatom egy meglévő php fájlhoz(ami sokszor kapcsolódik az adatbázishoz) -
retrox
csendes tag
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? -
ArchElf
addikt
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
-
retrox
csendes tag
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. -
ArchElf
addikt
válasz
Sk8erPeter
#916
üzenetére
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
válasz
Sk8erPeter
#916
üzenetére
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
válasz
Sk8erPeter
#916
üzenetére
Én lassan már válaszolni sem merek, mert folyamatosan megkapom, hogy egy öntelt, bunkó vagyok. Ilyen dolgokon busongani, filózni, amit egyesek - ha nagyon betegek/rosszindulatúak - akár magukra is vehetnek, hogy rosszat mondtam rájuk, már végképp nem merek.
-
Sk8erPeter
nagyúr
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.
-
martonx
veterán
-
ArchElf
addikt
válasz
Octopus21
#911
üzenetére
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
-
rum-cajsz
őstag
válasz
Octopus21
#907
üzenetére
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. -
Octopus21
aktív tag
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.
-
#65304576
törölt tag
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.

-
Azazello-
senior tag
válasz
Sk8erPeter
#900
üzenetére
a valaszok stilusa a magyaros.

de ez mar tenyleg ertelmetlen offtopic...
amit en irtam, arra bocsanatot kertem, tema lezarva reszemrol. -
D@ni88
addikt
Sziasztok.
update article set round(price) where id=254
Ez az update mért fut "ORA-00927: missing equal sign" hibára?
Új hozzászólás Aktív témák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Házimozi belépő szinten
- CADA, Polymobil, és más építőkockák
- iPhone topik
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- exHWSW - Értünk mindenhez IS
- Kritikát kapott a Nintendo konzolgyilkos felhasználói szerződése
- Milyen routert?
- Battlefield 6
- További aktív témák...
- Ritkaság! 17" Dell XPS 9720 - i7 12th gen 27% Áfás
- Apple iPhone SE 2020 64GB független, fekete
- Thermal Grizzly Aeronaut paszta 3,9g /BONTATLAN/Több darab/Számlával/
- Samsung Galaxy S21 FE / 6/128GB / Kártyafüggetlen / 12Hó Garancia
- DELL PowerEdge R630 rack szerver - 2xE5-2650v3 (20 mag / 40 szál, 2.3/3.0GHz), 32GB RAM, 55992Ft+ÁFA
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest



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)


