Új hozzászólás Aktív témák
-
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.
Én kérek elnézést!
-
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.Én kérek elnézést!
-
martonx
veterán
válasz Octopus21 #913 üzenetére
Miért lenne komolyabb?
Eddig az adatbázisban lévő adatokat maga az access "mutogatta". Ezután meg készítesz egy webes felületet, és az mutogatja az adatbázisban lévő adatokat.
Sarkítva annyi a különbség, hogy itt nem lesz lekérdezés varázsló, meg űrlapkészítő segédÉn kérek elnézést!
-
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.
Én kérek elnézést!
-
-
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).
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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!
-
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!
-
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!
-
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!
-
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!
-
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!
-
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.
Én kérek elnézést!
-
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.Én kérek elnézést!
-
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.Én kérek elnézést!
-
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ú.Én kérek elnézést!
-
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.Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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?
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
martonx
veterán
válasz B-L-A-C-K #1088 üzenetére
full text search van az express-ben is. Replikáció természetesen nincs, de mit akarsz 10Gb-s vicc DB-ken replikálni?
Ha már szerverek között replikálsz, akkor az a pár millió Ft egy rendes SQL szerverért aprópénz.Remélem érted az iróniát.
[ Szerkesztve ]
Én kérek elnézést!
-
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.Én kérek elnézést!
-
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.
Én kérek elnézést!
-
martonx
veterán
válasz Speeedfire #1128 üzenetére
Meg mondjuk ott egy DB szerver akkora, mint egy szoba.
Én kérek elnézést!
-
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.
Én kérek elnézést!
-
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.Én kérek elnézést!
Új hozzászólás Aktív témák
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Királyi menetben érkeznek a G.Skill új DDR5 memóriái
- Óra topik
- Redmi Note 12 Pro - nem tolták túl
- Samsung Galaxy S23 Ultra - non plus ultra
- Bestbuy játékok
- Skoda, VW, Audi, Seat topik
- Touroll J1 - amikor az átlagos is elég
- Feketelista, avagy a rossz boltok topicja
- Gitáros topic
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen