Új hozzászólás Aktív témák
-
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 -
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...
[ Szerkesztve ]
-
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...
-
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
Én kérek elnézést!
-
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.
Sk8erPeter
-
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.
-
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 -
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. -
rum-cajsz
őstag
válasz wolandino #964 üzenetére
Ha ennyire fontos ez az évszám, én biztos ellátnám tranzakciós adatokkal. A minimum, hogy ki, mikor változtatta. A legjobb, ha van érvényességi ideje a soroknak, és csak az az érvényes év, ahol az érvényesség dátuma üres.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
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.
Én kérek elnézést!
-
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
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?Én kérek elnézést!
-
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.
Sk8erPeter
-
#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
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.[ Szerkesztve ]
Sk8erPeter
-
#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). -
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.Én kérek elnézést!
-
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. -
PazsitZ
addikt
Szerintem teljesen intuitív dolog felismerni a NxM-es táblák kezelését.
Pedig a normalizáláshoz is kapcsolódik; ennek hiányában masszív adatduplikációval oldható fel bizonyos kapcsolatábrázolás probléma.
google gyorskeresés 1 eredménye: [link][ Szerkesztve ]
- http://pazsitz.hu -
-
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.
[ Szerkesztve ]
-
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. -
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.Én kérek elnézést!
-
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á.)
-
asuspc96
senior tag
-
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)
Eki - az eredeti
-
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
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
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.Én kérek elnézést!
-
EkSYS
senior tag
úgy néz ki az adatbázis kapocs megvan
Eki - az eredeti