Új hozzászólás Aktív témák
-
#1378
martonx
veterán
Apollo17hu
#1377
martonx
veterán
válasz
Apollo17hu
#1377
üzenetére
Segítek. Next - next - finish. Közben mindent default-on hagysz. Nem bonyolult ez.
-
#1376
martonx
veterán
Apollo17hu
#1375
martonx
veterán
válasz
Apollo17hu
#1375
üzenetére
ez most komoly kérdés volt?
Például a Dreamcoder for MySQL-hez na vajon mi kell? Segítek kell egy Dreamcoder, meg egy MySQL.
Töltsd le őket, és hajrá
-
#1374
martonx
veterán
Sk8erPeter
#1373
martonx
veterán
válasz
Sk8erPeter
#1373
üzenetére
Én 3 cégre látok rá, ezekből kettő az igazán nagyok között játszik (vagy legnagyobb? hm...) A harmadik is komoly tényező. Őszintén meglepődnék ha a többiek nagy részénél nem fordulna elő MS Access.
-
martonx
veterán
válasz
PazsitZ
#1366
üzenetére
Az SQL tudás mindennél többet ér (bár kitudja pár év múlva a NoSQL-ek felfutásával mire lesz jó a mostani SQL tudásunk
![;]](//cdn.rios.hu/dl/s/v1.gif)
), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
A fentebb hozott Access-es példámhoz egyébként SQL tudás kell. A kattitngatást nem arra értettem, hogy az Access designerével join-olod a táblákat, hanem az adatforrások Access-be behúzására. Személy szerint Access-ben is mindig kézzel írom az SQL kódot, a kód designert kb. soha nem használtam még benne.
És nehogy Access pártinak gondoljatok, csak próbáltam rávilágítani, hogy a világ nem szimplán fekete és fehér. -
martonx
veterán
Egy eset van, amikor az Access tényleg hasznos. Mindenhonnan magába tud fogadni adatokat, és ezekkel SQL szinten tudsz dolgozni.
Van pl. néhány klasszikus SQL szerveren futó táblád, meg van néhány rendszeresen frissülő TXT file-od, meg pár excel táblázatod. Ezeket SQL szerűen együtt kezelni, joinolni stb. MS Access-ben pár kattintás.
Nagyvállalati környezetben számtalan ilyen eset előfordul.
Persze meg lehet ezer más módon is oldani a fentebb vázolt problémát, de az MS Access-es megoldás a létező leggyorsabb, legegyszerűbb. -
#1364
martonx
veterán
Sk8erPeter
#1362
martonx
veterán
válasz
Sk8erPeter
#1362
üzenetére
Tudok több olyan nagy pénzintézetet mondani Magyarországon, ahol jelentős programok MS Access-ben vannak megvalósítva.
-
martonx
veterán
válasz
rum-cajsz
#1323
üzenetére
mondjuk elnézve a problémákat (amellett, hogy access ellenes vagyok), pont nem az access maga a probléma, hanem egyrészt szarul lett felépítve a használt adatbázis, másrészt a program is szarul lett megírva ami ilyen duplikációkat hoz létre bele.
Ezek a hibák, ha béna a programozó, pont ugyanígy megmaradnak, bármilyen db motort is használjon az ember. -
#1298
martonx
veterán
Sk8erPeter
#1297
martonx
veterán
válasz
Sk8erPeter
#1297
üzenetére
és ez még csak a PHP. Van még néhány nyelv, ahol nem is prepared statement-nek hívják
A lényeg azonban ugyanaz, kerülendő a konkatenálás. -
martonx
veterán
válasz
sanzi89
#1278
üzenetére
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)
1. próbáld ki kapcsos zárójellel a log-ot [log]-ként, lehet hogy az access a log-ot valami parancsszóként értelmezné tábla név helyett
2. { ts '1990-12-31 00:00:00' } - ez mi??? Valami ilyesmit próbálnék meg helyette: #2009-04-21 14:25:53# esetleg #'2009-04-21 14:25:53'#
3. Access-be belépve kapod ezt, vagy delphi-ből futtatva? Mert ha delphi-ből, akkor én megpróbálnám a helyedben access query-ből közvetlenül.Remélem segítettem, nagyon igyekszek távol tartani magam az access-től.
-
#1272
martonx
veterán
Yushchenko
#1271
martonx
veterán
válasz
Yushchenko
#1271
üzenetére
Ha a saját mezőid, akkor talán nem char-t, hanem varchar-t kellene használni.
Másrészt meglepő módon Trim-el tudod a szóközöket csonkolni. -
martonx
veterán
válasz
wolandino
#1259
üzenetére
Én folyamatosan hasonló cipőben járok, nem győzzük kidobálni a régi szarokat. Mostanában ha minden igaz végre a PHP-s szutykok lesznek soron. Az access-es fosok kidobálása meg már több, mint egy éve tart.
Én csak azon mosolyogtam nagyon jót, hogy amikor az ember fejleszt, óhatatlanul is felteszi a kérdést, hogy mire akarom ezt a rendszert használni, milyen más rendszerekhez kell (majd) kapcsolódnia, milyen platformon, milyen nyelven érdemes nekiállni a fejlesztésnek, milyen régi szart tudok esetleg kiváltani vele stb...
Ha egyszer windows vonal, akkor legyen windows vonal. Ha linux, akkor legyen linux. Nincsen annál nagyobb szopás, mint amikor az ember linux-os PHP-ról próbál meg MS SQL-el kommunikálni (lehet persze, ahogy az mdb-vel is).
Én napi szinten párhuzamosan programozok PHP-ben, .Net-ben, és Vbscriptben (beleértve mindenféle makrót is). Ezek mellett linuxon van PostgreSQL-ünk, windowsokon van MS SQL-ünk, és Oracle-ünk. Szóval tudom, hogy milyen az amikor régi megörökölt szarokat kell párosítani. Manapság már meg se próbálom (ha nem muszáj), eleve úgy futok neki bárminek, hogy mit lehet egy közös modern techonlógiával kiváltani, ha már egyszer hozzá kell nyúlni. Vagy minden közé webservice-eket írok, kommunikáljanak azok egymással a megfelelő platformokon (lásd SOA).
És nem ezzel van bajom, hanem ismétlem azon mosolyogtam, hogy hogy lehet ennyire öncélúan, önszopató módon új rendszert fejlesztened, ahelyett hogy kiváltottál volna vele egy régi rendszert. -
martonx
veterán
válasz
wolandino
#1257
üzenetére
"párhuzamosan kellene futnia az én alkalmazásomnak" - ezek szerint a linux-on futó PHP-s részt te csináltad. mdb mellé, linux-os PHP, meg valaki által házilag gányolt spanyol/olasz/portugál mdb odbc driver. Gratulálok
A kókányolás mintapéldája. Ha van rá lehetőség tényleg dobjátok ki az egész hóbelevancot, és csináljátok meg rendesen, konzisztensen. -
martonx
veterán
válasz
wolandino
#1249
üzenetére
úristen, a linux coderek mindig meg tudnak lepni. Valaki képes volt ms access odbc drivert barkácsolni???
Mondjuk a cégünknél láttam olyan linux guru-t, aki magától írt drivert a megvásárolt faxcenterhez. Igaz az óradíja alapján annyit fizettünk érte, mintha vettünk volna egy elve rendes linux driverrel szállított faxcentert -
martonx
veterán
válasz
wolandino
#1246
üzenetére
Nem ismerem a lehetőségeidet, csak jeleztem, hogy amit szeretnél nem fog menni. Mindegy, hogy neten mit találtál, amíg az MS nem írja meg az Access ODBC-t linux alá, addig nem fog működni amit szeretnél. Márpedig az MS soha nem fogja az Access-t linux alá megírni.
És az MS Access akkor sem egyenlő MS SQL-el, ez olyan mintha egy Skoda Fabia-ra meg egy Porsche-ra mondanád, hogy de mindkettőt a VW cég gyártja. -
martonx
veterán
válasz
wolandino
#1244
üzenetére
Te kevered a szerzont a fazonnal. MS SQL-ről beszélsz, mikor a connection stringet MS Access-re mutat.
Ráadásul mindezt Linuxon???
Nem fog menni. Megoldási lehetőségek:
1. Miért ragaszkodsz a Linux-hoz, ha már MS alapú az adatbázisod? Futtasd windows-on a PHP-t.
2. Elfelejted az mdb-det, és használsz helyette valami más SQL-t, mondjuk sqlite, mysql, postgresql. Ezek mind futnak linux-on is. -
#1225
martonx
veterán
SektorFlop
#1224
martonx
veterán
válasz
SektorFlop
#1224
üzenetére
join-os update-nek annyira más minden SQL nyelvjárásban a szintaktikája, hogy ajánlom a guglit. MSSQL-ben kapásból megmondtam volna.
Mondjuk ilyen triviális kérdésnél egyébként is elsőre guglizni illene... -
martonx
veterán
válasz
WolfLenny
#1199
üzenetére
Egyrészt a PHP mint interpreter nyelv az ilyen műveletekre alapvetően kb. 100X lassabb (lehet, hogy cak 10-szer, erről ne nyissunk vitát), mint egy compiled (pl. java, .net) nyelv.
Másrészt ha ezen a szerencsétlen P4-esen még emellett egy MySQL-t is futtatsz, és mindehhez egy ősrégi lassú vinyú kerreg alatta, akkor nem csoda ez a futásidő. -
#1191
martonx
veterán
SektorFlop
#1190
martonx
veterán
válasz
SektorFlop
#1190
üzenetére
le kell kérdezni. Csodák nincsenek.
-
#1183
martonx
veterán
Sk8erPeter
#1182
martonx
veterán
válasz
Sk8erPeter
#1182
üzenetére
Nincs itt nagyon mit megbeszélni. Az 5.1-es MySQL verzióban volt a legtöbb innováció. Ez pedig 2008 November 27-én jelent meg. Ez lassan 4 év távlatot jelent. lakisoft által jelzett újdonságok is ekkor kerültek bele. Azóta csak csiszolgatják.
Az Oracle pedig 2010 január 27-én vette meg a Sun-t, ami birtokolta a MySQL-t.
De ez részemről nagyon off topik, és nem vagyok egy nagy MySQL szakértő. -
#1180
martonx
veterán
Sk8erPeter
#1179
martonx
veterán
válasz
Sk8erPeter
#1179
üzenetére
Én inkább úgy mondanám, hogy mióta az Oracle kezében van, nem olyan a fejlődési üteme, mint régen. Az Oracle bolond lenne saját magának konkurenciát állítani.
-
#1172
martonx
veterán
kisbandima
#1163
martonx
veterán
válasz
kisbandima
#1163
üzenetére
Ha már Silverlight, akkor gondolnám, hogy WCF RIA Services-el adod az adatokat, ez esetben LINQ-val simán meg lehet oldani az egészet.
Ha meg nem több millió adatsorról van szó, C#-al, XAML-lel elég szépen lehet memóriában szűrni az adathalmazt. -
#1151
martonx
veterán
Speeedfire
#1150
martonx
veterán
válasz
Speeedfire
#1150
üzenetére
Szvsz nem ajánlott keverni, legalábbis vagy RDBMS-t, vagy dokumentum alapú NoSQL-t érdemes használni. És e mellé persze könnyen lehet gráf tárolót, vagy kulcs-érték tárolót használni (lásd pl. Facebook, ami MySQL alapú, de a kapcsolatokat gráf tároló NoSQL-ben tartja).
-
martonx
veterán
válasz
WolfLenny
#1148
üzenetére
ez esetben abszolút nem kell erős hardver a mysql alá. Egy mai bármilyen alap szerver megteszi (kettő mag, pár guriga memória, egy kis raid tömb mondjuk 3 vinyóból, ha fontos a redundancia). Azért ha nem egy 10 éves egy magos xeon-on futtatnátok, az nem lenne hátrány.
-
martonx
veterán
válasz
WolfLenny
#1146
üzenetére
MySQL 5.1-től fölfelé 64Tb-os 1-1 adatbázis méretkorlátja. Szerintem ennek a közelében sem lesztek.
Vasat nehéz javasolni, pláne, hogy eddig csak a havi bejövő adatmennyiségről volt szó. Tudni kellene, hogy a bejövő adatok írása mennyire oszlik szét időben, a lekérdezések mennyire történnek időben szétszórtan, illetve hány konkurens felhasználóra számítotok.
Általános tapasztalat, hogy legtöbbször a lemezműveletek viszik el a sok időt, még akkor is ha az adott DB szervernek sok memória áll a rendelkezésére. Manapság a sokmagos processzorok korában a processzor egyre kevésbé a szűk keresztmetszet. -
#1144
martonx
veterán
Speeedfire
#1137
martonx
veterán
válasz
Speeedfire
#1137
üzenetére
Pont a múltkor kezdtem el noSQL-ezni, pont a mongoDB-vel. Én is még csak kostólgatom. Viszont ahhoz, hogy dönteni tudjak közülük (mármint RDBMS - noSQL közül, és ha noSQL, akkor melyik), bele kellett mélyednem az előny-hátrányaikba.
Még annyit tennék hozzá a fentebbi irományomhoz, hogy amit írtam, az a dokumentum alapú NoSQL-ekre vonatkozik. A kulcs-érték, gráf stb... típusú NoSQL-eknek értelemszerűen teljesen más előnyei lehetnek. RDBMS kiváltásához nyilván a dokumentum alapú NoSQL-eket szokták használni. -
martonx
veterán
válasz
WolfLenny
#1138
üzenetére
1 táblába raknám az adatokat. Aztán ha mégis lassú a dolog, akkor lehet indexekkel játszani, táblát particionálni stb...
Illetve ha évenkénti lekérdezéseitek vannak, egy év múlva megnézve az SQL teljesítményt, elgondolkodnék azon, hogy érdemes-e az adatokat évenként archiválni.
Nagyon fontos lenne mindehhez tudni, hogy milyen a vas a MySQL szerveretek alatt. Mivel totál kezdő vagy, erős a gyanúm, hogy ti egy szimpla hoszting cég amúgy is gyengécske MySQL szerverén fogtok osztozni sokadmagatokkal. Ebben az esetben, bármit is javasolnánk elégtelen lesz az SQL teljesítmény, sőt az első adatbetöltés után maga a hoszting cég fog nyakon vágni titeket, amiért fél órára legyilkoltátok a szerverüket. -
#1134
martonx
veterán
Speeedfire
#1132
martonx
veterán
válasz
Speeedfire
#1132
üzenetére
A noSQL sem csodaszer. Select-ek futtatásában pláne nem.
Bonyolult adatstruktúrák írásakor sokszorosa, akár százszorosa a sebessége a hagyományos RDBMS-ekhez képest.
Bonyolult adatstruktúrák olvasásakor van olyan eset, amikor jóval gyorsabb (néhány szoros) a sebessége a hagyományos RDBMS-ekhez képest.
Full-text search-ben sokkal rugalmasabbak, gyorsabbak a noSQL-ek, különösen azok, amelyek magukba intergálják a Lucene-t is, ilyen pl. a ravenDB
Viszont ha van egy komolyabb adatstruktúrád, de annak csak bizonyos elemeit akarod lekérdezni (mintha több táblád lenne hagyományos sql-ben, de éppen csak egyet akarsz lekérdezni, vagy csak 1-2-t), nos egy ilyen triviális feladat noSQL-ben már korántsem triviális.Ebben az esetben a webszerver, hogy Apache, vagy nginx, vagy IIS, vagy Tomcat vagy bármi totál lényegtelen. Nem az lesz a szük keresztmetszet.
-
#1129
martonx
veterán
Speeedfire
#1128
martonx
veterán
válasz
Speeedfire
#1128
üzenetére
Meg mondjuk ott egy DB szerver akkora, mint egy szoba.
-
martonx
veterán
válasz
WolfLenny
#1126
üzenetére
Egy SQL tábla kb. bármennyi adatot elbír. Távközlésben DB admin ismerős mesélte, hogy van olyan táblájuk, amibe napi 130 millió sor kerül bele.
Nálunk is vannak szép nagy táblák.
Másrészt úgy látom, hogy ti PHP + MySQL-t akartok használni, ahol gondolom a MySQL ingyenes, nem Enterprise verzió, és nincsenek fürtözött SQL szervereitek a MySQL mögött. Ilyenkor szép hosszú keresési időkkel számolhattok, egy - egy lekérdezésnél. De file-ában letárolni az adatokat, és abban keresni, az még rosszabb.A jogosultságos kérdésben kevered a szezont a fazonnal. Az SQL szintű user jogosultságok általában köszönő viszonyban sincsenek az alkalmazás szintű user jogosultságokkal. Általában 1-2 SQL usert szoktak létrehozni, 1-et a DB adminnak full jogkörrel, és 1-et az alkalmazásnak csak a szükséges jogkörrel. Utána minden más jogisultságot az alkalmazáson belül szoktak intézni.
-
martonx
veterán
válasz
B-L-A-C-K
#1102
üzenetére
A baj csak az, hogy nem jó helyen kérdezted meg.
Ez itt egy SQL szakmai topic. Te pedig egy E-learning CMS-t akarsz beüzemelni, aminek nulla köze van az SQL szakmaisághoz. Na jó SQL-en fut a DB része, de ezzel az erővel mindennek köze van az SQL-hez Pl. a facebook is SQL-en fut, mégsem itt kell megkérdezni, hogy hogyan kell ismerősnek jelölni rajta valakit.
Privátban továbbra is segítek szívesen. -
-
martonx
veterán
válasz
B-L-A-C-K
#1085
üzenetére
Nem tudhatjuk, hogy mire kell neked.
Egyébként három fő limitációja van az ingyenesnek:
1. Csak 1 db processzor magot használ ki
2. Csak 1 Gbyte memóriát használ ki
3. 10Gb-nál nem lehet rajta nagyobb az egyes DB-k méreteHa nincsenek nagy DB-id, és nem több száz párhuzamos felhasználóra akarsz felkészülni (hanem csak néhányra), akkor ezen limitációkkal simán együtt lehet élni.
-
martonx
veterán
Nem értelek. Minden adott a problémád megoldásához, a megoldásokat leírtam/leírtuk, de te nem csinálod meg. Mit vársz tőlünk? Menjünk át hozzád, és helyetted rakjunk fel egy Toad for Mysql-t, majd rakjuk fel az sql dumpot a lokális gépedre, és szépen nézegessük át veled az egészet? Majd magyarázzuk el, és simogassuk meg a buksidat?
-
martonx
veterán
"a gépemen xampp van csak" - ezek szerint saját gépen fut a mysql??? Ez esetben kérlek, a saját érdekedben tegyél fel egy Toad for MySql-t, a phpmyadmin-t meg hagyd meg a vérpistikéknek, vagy azoknak a szerencsétleneknek, akiknek nincs elérésük a hosting környezet mysql-éhez, mégis éles környezetben kell mókolniuk az sql-ben.
-
martonx
veterán
válasz
wolandino
#1043
üzenetére
megismerve a feladatot, ez egy darab táblával kényelmesen megoldható.
Oszlopok:
azonosító, szülő, értékÉs pl. így nézne ki egy-egy sor:
1, 0, élőlény
2, 1, állat
3, 1, növény
4, 2, tigris
5, 2, krokodil
6, 3, pálma
7, 3, ibolyaAz első legördülő mezőben megmutatod az élőlényt
A másodikban állat, vagy növény.
Ez alapján a harmadikat feltöltöd az 2-es vagy a 3-as szülőjű tételekkel.
Ráadásul elég csak a legutolsó választást letárolnod pl. 6. Ebből visszakereshető, hogy a választott érték pálma, ennek a szülője a növény, ami pedig az élőlényekből származik. -
#1050
martonx
veterán
InfiniteReality
#1045
martonx
veterán
válasz
InfiniteReality
#1045
üzenetére
miért ne lehetne az union-t group by-olni?
Másrészt 428 ezer sor miatt szedted szét?
Majd ha sok millió sor lesz benne. Talán inkább rendesen indexelni kellene, ha a 428 ezer sor lassú. -
martonx
veterán
válasz
wolandino
#1037
üzenetére
"Arra gondoltam, hogy két táblára lenne szükségem
az egyik mondjuk table_connect(melyik_táblát, melyikkel)
a másik pedig a data_tree( melyik_tábla, melyik_adata_id, melyik_táblával, melyik_adatával_id)"Erre. Javaslom, hogy ez a koncepció helyett minden tábla között, ami között sok-sok kapcsolat lehet, vegyél fel külön kapcsolótáblákat. Ettől még a te ötleted is működik.
Ha pedig 10 tábla közül minden kapcsolódhat mindennel, akkor ott valami alapvetően félre van tervezve. -
martonx
veterán
válasz
wolandino
#1035
üzenetére
mivel nulla konkrétumot árultál el...
Általánosságban:
Kapcsoló tábla jellemzően a sok a sokhoz esetben kell, a többi esetet sima foreign key-ekkel meg tudod oldani.
Ha már kapcsoló táblád van, érdemes tábla-tábla közé létrehozni egy-egy kapcsoló táblát, legalábbis az ORM-ek ezeket tudják értelmesen feldolgozni, és itt már csak felesleges túlbonyolításnak érzem, egy nagy kapcsoló táblát létrehozni.
De te tudod. -
martonx
veterán
Én valahogy idegenkedek a NoSQL-től. Jóllehet bizonyos esetekben kiválthatnak hagyományos funkciókat pl. cookie-kat, session-öket, illetve ezek közötti kommunikációt könnyű NoSQL-lel, szépen adminisztrálható, áttekinthető módon megoldani.
Jól jöhetnek akkor is, ha abszolút változó oszlopszámú rekordokat kell tárolni.
Illetve előnyük még, hogy a szöveg alapú keresésben hatékonyabbak (ez azért relatív), mint a hagyományos relációs adatbázisok.
Hátrányuk, hogy egy szépen felépített adatbázissal, ahol minden mindennel relációban van, egyszerűen nem vehetik fel a versenyt.
És itt jegyezném meg, hogy az ilyen "vannak oszlopok is, értékek, amelyek mindig tetszőleges számúak! Az egyik diagramnak 4 oszlopa van, míg a másiknak 8 oszlopa van." esetek meglátásom szerint túlnyomórészt adatbázis, program rendszer tervezési hibák miatt születő megoldások, ahol a tervezés butaságait a NoSQL sem fogja megoldani, maximum elfedi, sőt a kötetlensége miatt akár fel is erősítheti ezt a jelenséget.
A kétféle SQL használata abszolút nem zárja ki egymást, párhuzamosan is lehet használni őket.
-
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. -
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. -
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. -
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? -
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.
-
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
-
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.
-
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).
-
-
#917
martonx
veterán
Sk8erPeter
#916
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.
-
martonx
veterán
-
martonx
veterán
válasz
Azazello-
#893
üzenetére
"se nem ertek hozza, se nem erdekel igazan a dolog"
Tudod ilyenkor szoktak szétnézni a munkaerőpiacon, és felvenni egy kompetens embert, vagy megbízni egy kompetens alvállalkozót. Ráadásul röhej, de pont ezzel foglalkoztok, a leírásod alapján.
A fórumok nem erre valók.
Viszont esetleg néz szét a prog.hu-n. Ott meglepődve látom néha, hogy egy-két hülye / tengernyi idővel rendelkező lelkes amatőr (nézőpont kérdése), milyen komoly, több órás melót belerak egy-egy válaszba. -
martonx
veterán
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.
-
#870
martonx
veterán
Sk8erPeter
#867
martonx
veterán
válasz
Sk8erPeter
#867
üzenetére
Maximálisan szívemből szóltál
annyi különbséggel, hogy én már mindenre wordpresst használok, a drupal-t, joomla-t egyre inkább hanyagolom.
És amikor a noname CMS-ekkel való szívásokat látom, csak mosolygok, és azért megpróbálok segíteni.
Ettől függetlenül mindenki azzal szívatja magát, amivel akarja. -
martonx
veterán
3-as tényleg lemaradt
És az ismerősnél, akinél hiba nélkül lement a telepítő rendben működik? Vagy nála is ugyanez a hiba.A helyedben nyitnék egy külön topikot (ahogy látatlanban bizotsan van Drupal, Joomla stb. topik is itt a PH-n), vagy szétnéznék a CMS honlapján, hivatalos fórumában. Ha 2-nél kettő esetben nem működik telepítés után, akkor elég nyilvánvaló, hogy itt nem fogjuk tudni megoldani neked.
Nekem édes mindegy melyik CMS-t használod, csak a nagyokkal garantáltan nincs ilyen probléma. A kicsiket pedig nem véletlenül nem használja két tucat lelkes amatőrön kívül senki. De ízlések és pofonok.
Biztos nem mond neked sokat az SQL, elvégre nem itt kezdtél volna el kérdezősködni, de hidd el, az SQL egy gyűjtő fogalom, ahol SQL-es alap problémákkal szoktunk foglalkozni, nem pedig egyes adatbázisok telepítési hiányosságaival. Olyan ez, mintha vennél egy Trabantot, és egy autóelektronikai fórumban megkérdezed, hogy a te autódban miért nincs pótkerék.
-
martonx
veterán
Kérdéseim:
1. Ha ez egy szűz install, akkor miért pont egy noname CMS-re esett a választásod? Mivel jobb ez, mint egy garantáltan működő Drupal, Joomla, Wordpress CMS?
2. Próbáltad újra installálni?
4. Hibanélkül lementek a telepítések?
5. A legfrissebb verziót telepítetted?
6. Használsz hozzá plugineket, vagy rögtön installálás után, első működéskor írja ezt a hibát?Másrészt baromira semmi köze a problémának az SQL-hez, szvsz nem itt kéne vesződni egy noname CMS telepítési nyűgjeivel.
-
martonx
veterán
válasz
rum-cajsz
#815
üzenetére
Az volt a javaslat, hogy temp tábla helyett hozzunk létre minden esetben igazi táblákat. Belegondolni is nonszensz...
Megdöbbentő, hogy néha magukat szakértőnek kiadó emberek, cégek mennyire nem értenek az adott témához.
Azt mondták azért jobb a minden esetben fizikai tábla, mert azt jobban lehet optimalizálni. Ez akár igaz is lehetne, node legyen több száz, több ezer fizikai táblánk? Ki fogja ezt karbantartani, átlátni? Hülyék.... -
martonx
veterán
válasz
rum-cajsz
#813
üzenetére
Nem gondoltam, hogy lehet olyan eset, ahol az alselect gyorsabb lehet, de végülis mittudomén talán előfordulhat ilyen.
Éppen a héten optimalizáltam egy kolléga kódját, aki szerette az alselecteket (mondjuk régivágású programozók még emlékeznek az SQL-ek hőskorára, amikor NEM is létezett inner join - 2000-es évek előtt). Mit ne mondjak százezres tételszámoknál (mind főselect, mind alselect több százezer sor) perceket lehetett nyerni, hogy 4-5 inner joinba rendeztem át a cuccot.Tényleg és ti mit szóltok a temp táblákhoz? Múltkor ledöbbenve hallottam, hogy nem kellene használni őket. Szerintem ez hülyeség. Szerintetek? MSSQL alatt eléggé furcsállom, hogy ne kellene temp táblákat használni. Én még PostgreSQL, MySQL-ben is használok temp táblákat (8.0 felett, az ennél régebbiekben inkább csak elméleti lehetőség, mintsem gyakorlati).
-
#810
martonx
veterán
Sk8erPeter
#809
martonx
veterán
válasz
Sk8erPeter
#809
üzenetére
MS SQL-nél az inner join nagyságrendekkel gyorsabb, mint a beágyazott selectek. Oracle-lel nincs tapasztalatom.
Mondjuk amíg nem több százezres táblákon használsz ilyen alselectes beágyazásokat, addig szinte mindegy.
ez most komoly kérdés volt?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
Kb. úgyis ugyanazt kell letárolni mindkét csoportról.
Új hozzászólás Aktív témák
- Lexus, Toyota topik
- LEGO klub
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Mesterséges intelligencia topik
- Kerékpárosok, bringások ide!
- Sokkal jobb ajánlat lett elődjénél az iPhone 17e
- BestBuy topik
- Mikrotik routerek
- Mibe tegyem a megtakarításaimat?
- Formula-1
- További aktív témák...
- GIGA AKCIÓ!!! 450.000Ft HELYETT szinteÚJ OnePlus 15 egyenlő 16 ami 2 a 4.-en Sand Storm 16GB / 512GB
- Apple iPhone 17 Pro Max 256GB Deep Blue használt, karcmentes 100% akku (52 ciklus) Apple garan
- HP Victus 16 i5-11400H 16 GB RAM 512SSD RTX 3050 4 GB FHD 144Hz
- iKing.hu Apple iPhone 14 Pro Deep Purple 128GB használt megkímélt 100% akku 6 hónap garancia
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest