A JOIN általában hatékonyabb futásidőben, mint az ide oda beágyazott alselectek.

Én kérek elnézést!

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

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 ]

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...

OR operátorral:

SELECT nev
FROM tanulo
WHERE nev LIKE 'a*' OR nev LIKE 'k*' OR nev LIKE 's*' OR nev LIKE 'b*';

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!

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

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

Én kérek elnézést!

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.

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=======

ezt én nem sql szinten, hanem a programomban oldanám meg, jogosultság kezeléssel.

Én kérek elnézést!

ezt nem egészen értem.
Adattárolási kérdést csak adatbázis szinten érdemes kezelni.

Í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!

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

És azt megkérdezhetem, hogy mire lesz jó ez az egész? Miért jó ennyire nyakatekerten megoldani egy adat DB jogosultsághoz kötését?

Én kérek elnézést!

miért lenne röhejes?
mitől lenne jobb kliens oldalra tenni a jogosultságkezelést?

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!

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

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.

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

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).

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!

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ő.)

nem a jogosultság, hanem az adattárolás a fontos, el kell tárolni egy évet az AB-ben, de már másként csinálom. Több év lesz és mindig egy current. Az az adattárolás szempontjából lényegtelen, hogy ezt kik fogják elérni.

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 -

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.

Én a helyedben elfelejteném azt a megoldást, hogy a mobilra pakolom a komplett DB-t. Felhőbe rakd a DB-t, és onnan hívogasd célzottan.

Én kérek elnézést!

de mindenképp offline akarom megoldani az egészet. androidon már láttam olyan programot ami ebből csinált adatbázist(és kemény 500kb az egész program). Ezért is akarom kiszűrni a fölösleges dolgokat, hogy minnél kissebb legyen az adatbázis

Duplikálódások kiszűrésére a DISTINCT utasítás használható. Nem értem pontosan, hogy írod, de ha rekordonként csak a megálló száma változik, akkor hagyd el a megálló számát tartalmazó mezőt, a maradékra meg nyomj DISTINCT-et!

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á.)

Szerbusztok !

Erre Valaki ?

asuspc96

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, visszaigazolnia

Eléggé az elején tartok s nagyon megköszönném ha valaki segítene kicsit (akár priviben vagy mailbe)

Eki - az eredeti

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]

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 :/

Eki - az eredeti

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.

=Kilroy was here============================ooO=*(_)*=Ooo=======

Tárolt eljárás +1

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]

Tárolt eljárás +2