Új hozzászólás Aktív témák
-
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!
[ 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
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
-
PazsitZ
addikt
Igen, mérés esetén vagy a benchmark-al futtasd le mondjuk 10000 ismétléssel így mindegyik esetén azonosan használ cache-t a későbbi requestek esetén és hamarabb kibukik.
Vagy mindkettő futtatása elé szúrd be a: RESET QUERY CACHE; parancsot.
Feltéelezve, hogy mysql-t használsz.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Speeedfire
nagyúr
Hát ez jól hangzik, ennek utána nézek, remélem menni fog nálam is. Én meg itt 50 soros php sql kódon agyaltam már.
MySql alatt vannak az adatok, de meglesem, hogy ezek ott is vannak-e.
Köszi.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
Na, a kérdés maga annyira megzavart, hogy már én is félrebeszéltem, meg pontatlanul is írtam, bocsi. A kérdező azt írta, hogy "A dátum 2003.11.26. 10:28:14 ilyen formátumban van.", én ebből úgy értelmeztem, hogy valamilyen oknál fogva string típusként van TÁROLVA az adatbázisban (most szándékosan írtam tárolást!! Mindegy, hogy varchar vagy egyéb ilyen jellegű típusról van szó, és NEM a dátumformátumok valamelyikéről, aminek nyilván megvan a maga tárolási módja, de attól még valamelyik tényleges dátumformátumról van szó), ezért kénytelen vagdosni, stb., de akkor valószínű félreértettem az eredeti felvetést.
Utána már azt is félreértettem, amit Te írtál, pedig így másodszor elolvasva elég világos, hogy itt csak dátum-megjelenítési formátumot változtatsz, attól még nem tárolod másik formában.
Akkor most megpróbálom értelmesen megfogalmazni: arra gondoltam, hogy még a megjelenítési formátumot sem biztos, hogy szerencsés, ha az ember változtatja, mert ha mondjuk egy alkalmazást megír (hogy most az asztali vagy webes, tök mindegy), ami az adatbázistól bizonyos formátumban (megjelenítési formátumban) vár adatokat, és tök más formában kapja meg, mint egy másik szerveren, akkor abból adott esetben probléma lehet - mondjuk a probléma kimerül annyiban, hogy át kell állítani a formátumot úgy, ahogy mutattad, de nem biztos, hogy azonnal leesik, mi is a gond.[ Szerkesztve ]
Sk8erPeter
-
weiss
addikt
90% üzemeltető + 10 % fejlesztés. Oracle + MS. De perpill csak nagyon alapok vannak. Nem tudom ismered-e, de CCNA vizsgára vannak szuper könyvek, amikből el lehet sajátítani nemcsak a Cisco berendezéseket, hanem a hálózatokat is. Na, szóval ilyen kellene adatbázisokra, ha létezik
I did nothing, the pavement was his enemy!
-
Lacces
őstag
Kliensekre volt felrakva, a db szerver...
Igen, ezt a leírást én is láttam, meg olyat is olvastam, hogy 1 gépen 1 adatbázis szerver legyen.
" and use one CPU on the host machine."Csak az a gondom, hogy én szeretnék VPS-t bérelni, amin futna olyan 4-6 oldal lenne rajta, 1 mongodb és egy rdbms is.
1GB ram, 2magos cpu, 50GB-ra menne, és nem tudom mennyire bírná a szerver. Esetleg ilyen tapasztalatod van ezügyben? -
Lacces
őstag
és lakisoft, köszi.
Akkor már csak annyi kérdésem lenne, hogy hogyan lehet tábla szerkezetet és adatokat egyik adatbázisból a másikba könnyen átvinni?
Elsősorban PostgreSQL-ből Oracle-be történő adat migráció érdekel. (csak az egyiknél lenne kérdéses... ha bevállik a weblap, akkor a többi weboldalhoz képest, rengeteg adat tárolódna és mozogna benne egy nap - vagy simán kudarc lesz )
De lehet akkor már lesz elég nyereség és felfogadok innen valakit a PH-ról, hogy oldja meg.
Csak nem akarom a kezdők hibáját elkövetni és már az elején elrontani.A válaszokat meg már előre köszönöm
-
csabyka666
addikt
Biztos, hogy ez egy nagyon egyszerű dolog, de pontosan hogyan kell ezt csinálni Access-ben?
Más: csak akkor kell a kapcsolótáblát "piszkálni", ha alkatrészt veszek fel? Autó felvételénél nem, ugye?
[ Szerkesztve ]
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
csabyka666
addikt
Hm, ez igaz. A lényeg, hogy én úgy akarok felvenni minden alkatrészt, hogy megadom a felvételnél, hogy melyik autótípusokba lehet beépíteni. Itt jön a következő gond, hogy például ugyanazt a féktárcsát beépíthetem 8 féle autótípusba is, akkor azt a rekordot 8x kell felvennem, csak más autókkal?
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
-
martonx
veterán
Azért a materialized view, illetve indexed view-k korántsem olyan hatékonyak, mint egy sima webszerver cache, mert ezek ha nem is olyan mértékben mintha elölről indulna mindegy egyes lekérdezés, de azért mozgatják az SQL-t. Az adatok felesleges mozgásáról, felesleges SQL-hez fordulásokról nem is beszélve. Szvsz nem is arra lettek kitalálva, hogy kvázi cache-t alkossanak bizonyos táblák felett, inkább az indexelt lekérdezéseket könnyítik meg nagyon komplex lekérdezéseknél (legalábbis MSSQL vonalon, ott használtam már indexed view-t).
Én kérek elnézést!
-
sztanozs
veterán
Bocs nem neked akartam válaszolni...
alratar: Primary ID-t nem lehet "egyszerűen" módosítani, mivel roncsolja az integritást. Ha fontos, hogy növekvő és folyamatos sorrend legyen, ikább érdemes egy generált mezőt használni (vagy egyszerűen kiiratásnál beszámozni a mezőket). AZ ID mezők nem erre valók, hanem hogy az adatkapcsolatokon keresztül az integritás (mi tartozik mihez) megmaradjon.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
alratar
addikt
Akkor leírom, hogy miért is kellene ez.
Egy olyan adatbázist szeretnék csinálni, ahol futball játékosok neveit és adatait lehet felvinni.
És mivel, ugye a játékos állomány folyamatosan változik (eladják őket stb) így az id hosszúsága előbb-utóbb több tíz hosszúságú is lehet.
És ezt szettném kibekkélni!10 féle ember van: aki ismeri a bináris számrendszert, és aki nem
-
Flashback
addikt
'Trunc' is not a recognized built-in function name.
Ilyenkor mi a helyzet?
Microsoft SQL Server Management Studio 10.50.4000.0
Microsoft Data Access Components (MDAC) 6.1.7601.17514
Microsoft MSXML 3.0 6.0
Microsoft Internet Explorer 9.0.8112.16421
Microsoft .NET Framework 2.0.50727.5466
Operating System 6.1.7601Bocs nincs hosszú ö, ü és néha az á is ä :)
-
Jim-Y
veterán
Köszi, szerintem ez jó lesz
"nem a teljes hét kell?
mezo1 >= X-1. hét első napja AND mezo1 < X. hét első napja" de, igazad van, csak elírtamköszönöm
megj: annyi kérdésem azért lenne, hogy a 5 DAY, illetve a -2 DAY az mára van optimalizálva ugye? Tehát ha holnap nézném, akkor már nem ugyanezt az eredményt adná igaz? Magyarán ki kell választanom, hogy melyik napra automatizálom az eljárást, és ezekben a sorokban ahhoz kell igazítanom az INTERVAL-t..
[ Szerkesztve ]
-
bambano
titán
"a kliens (pl. egy shell script) elkeri a futtatando query-ket es szepen beadagolja": ez egyre inkább igaznak tűnik, csak eddig volt már rá több példa is, hogy egy-két okos embernek volt jobb megoldása, mint amit én elsőre találtam, ebben bíztam most is.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- AMD GPU-k jövője - amit tudni vélünk
- TCL LCD és LED TV-k
- EAFC 24
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Luck Dragon: Asszociációs játék. :)
- Milyen okostelefont vegyek?
- Vicces képek
- Gray Zone Warfare
- Milyen belső merevlemezt vegyek?
- További aktív témák...
- Keresek - Macbook Air M3 16GB / 24 GB - 512 GB SSD - Magyarországi beszerzés, tehát kb. 3 év garit
- Tyű-ha Lenovo Thinkpad T14 G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 16GB /512GB FHD IPS
- Ej-ha Lenovo Thinkpad T14 G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 32GB /512GB FHD IPS
- Eladó Nitro Venture TLS Snowboard Bakancs 46-os
- Eladó Nitro Team 2022 162W Snowboard Deszka
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest