Hirdetés
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- eBay-es kütyük kis pénzért
- Brogyi: CTEK akkumulátor töltő és másolatai
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- icemad: Melyik vpn-t? Help please...
- sh4d0w: Én és a számítógép
- Viber: ingyen telefonálás a mobilodon
Új hozzászólás Aktív témák
-
Taci
addikt
Lehet, ez buta kérdés, de ma valahogy eszembe jutott, hogy van a MySQL-felhasználó, amit az adatbázishoz "kapok" a szolgáltatótól.
Van értelme annak, hogy a weblappal kapcsolatos műveletekhez (rekordok felvétele, lekérdezése és frissítése) létrehozzak egy másik felhasználót, aminek csak a valóban elengedhetetlen jogokat adom meg?
Mert most a tesztkörnyezetben a "fő felhasználót" állítottam be, de szerintem az úgy nem lesz az igazi (főleg biztonsági szempontból talán).Pl. nem kell, hogy tudjon rekordot/táblát/mezőt/bármit törölni, így nem kap Delete-jogosultságot. Csak mondjuk Select, Insert, Update. (Data)
A Structure-nál kell gondolom a táblákkal kapcsolatos funkciókat beállítani, szóval ott pl. nem kellene semmi.
Az Administration rész még nem tiszta, annak utána olvasok.
Ti használtok külön felhasználót ezekre a feladatokra?
Ha igen, milyen jogosultságokkal bír, milyen feladatokhoz?Köszi.
-
nyugis21
kezdő
válasz
martonx
#5292
üzenetére
Pedig csak egy mondat volt.
1. Csak éppen értelmezhetetlen, mert az Acces nem enged két kapcsolatot két tábla között, lásd lentebb.
2. Nekem már papírom van róla, hogy nem vagyok aktív, felesleges emlékeztetned rá.
A tények:
Láthatod, hogy ott van az új feladat tábla, de vagy ezt a kapcsolatot hozom létre, ami a képen látható, vagy a másikat, az Eset táblából a feladat-ot kötöm össze a Feladat tábla ID_feladat-tal.A kettő egyszerre nem megy, ezért nem értem, amit írtál.
-
martonx
veterán
válasz
nyugis21
#5291
üzenetére
Pedig csak egy mondat volt.
Csinálsz egy új táblát, amit mondjuk hívj Feladat-nak. Eddig meg van ugye?
A táblának két mezője lesz:
SzülőEsetID
FeladatEsetIDEz a tábla fogja megmondani, hogy egy Esethez milyen más esetek, a te értelmezésedben ekkor már Feladatok tartoznak.
-
nyugis21
kezdő
válasz
nyugis21
#5286
üzenetére
Na tessék, itt van, eddig jutottam:
Egy ügy elindul, annak sok eseménye (eset) lehet, vannak résztvevők és esetleg van helyszíne, van típusa, amit listával meg lehet oldani.
Ez eddig szép és jó.Az ügy táblát az access sablonbol vettem át, érdekes, hogy csak egy csatolás volt, itt pedig három sor jelenik meg, a "fontosság-állapot-készültség" sorokra talán nem lesz szükség, egyenlőre benne hagytam.
Ott vagyok elakadva, hogy bizonyos eseteknél feladatokat kell meghatározni, amelyek újabb eseményeket várnak el, vagyis szükség lenne egy újabb eset táblára.
Az a kérdés, hogy ezt hogyan lehet megoldani?
-
nyugis21
kezdő
válasz
martonx
#5284
üzenetére
OK,megpróbálok gyorsan áttekintést adni, de most estem vissza, megint ezernyi dolgot varrtak a nyakamba, hogy "neked úgyis mindenre van időd."
Nos, a táblákkal elakadtam, igen, amiket írtam, az megvan, és talán első lépésben annál nem kell több adat, ha igen, talán egyszerű lesz hozzáírni.
Elolvastam pár leírást, és volt egy nagyon jó javaslat, hogy mindent a legvégső lekérdezés alapján kell megtervezni, de itt elakadtam, mert többféle módon kell majd látni az adatokat.
Tehát az alapsor adott, dátum és idő, ha egyszeri dologról van szó (levél, telefon) és idősáv, ha esemény (pl. hosszú beszélgetés) kell.
Azaz itt már bejön egy kódmező, ahova az esemény formáját lehet kiválasztani.
Azután az adott esemény valamilyen ügyhöz tartozik, valamint vannak résztvevő személyek (aki levelet írt, vagy aki(kk)el beszéltem, utóbbi esetben van helyszín is.Azután jön a nagy dilemmám, hogy a kapcsolatokat hogyan tegyem bele, mert a fentiekből következik, hogy egy ügyhöz sok esemény kapcsolódik, de az egyszer dátum szerinti sorrendben van, másodszor van bizonyos események között logikai kapcsolat van (pl. megbeszélés után van több feladat, levelet írni, telefonálni, vagy következő megbeszélésre iratot beszerezni), és emellett bejön még a határidő és feltétel, hogy a következő megbeszélés csak akkor lehetséges, ha azok teljesültek.
Ezért talán az "ügy" és az "események" között kell egy újabb kódmező, ami azt jelzi, hogy teljesültek a feltételek, és tovább lehet lépni.
A végső megjelenítés történhet az adott ügy szerint, hogy mikor és mi történt, kik vettek rész és hol voltak az események - itt megint bejön a dilemma, hogy időbeli vagy logikai sorrend legyen.
Valamint kell olyan megjelenítés is, hogy adott személlyel milyen ügyeim voltak, ami sokkal bonyolultabb lesz, hiszen az adott személyről van szó, de az ügy listájában ott lesz, hogy az adott személy az ügynek csak bizonyos eseményeiben vett részt.
Nost így ennyi van a fejemben, két napja nem voltam pc előtt, majd talán holnap tudok egy képernyőképet feltenni, hogy a három táblával eddig mire jutottam.
-
DeFranco
nagyúr
válasz
nyugis21
#5283
üzenetére
nézd, ezt így nem igazán lehet, fejjel rohansz a falnak. tulajdonképpen te sem tudod hogy pontosan milyen eszközt akarsz használni, csak összeraksz apró részletekből valamit ami szerinted jó lesz. nem lesz jó.
jelenleg az a helyzet, hogy egy SQL topicban kérdezel accessről (ami itt erősen témán kívüli) egy olyan feladatra amihez excel is bőven elég (ami megint csak messze van az accesstől hát még az SQL-től) és amihez a tudásod még alapfogalmak szintjén sincs meg (ami nem feltétlenül baj, sőt... ezért vagyunk itt, csak éppen kicsit lassabban kellene haladni neked is.)
ahhoz, hogy tényeket rögzíts kb. idősorosan arra egy excel bőven több, mint elég, ahogy olvastam a feladatot, abból azt, ami reális cél (mások által nem módosítható módon rögzíteni tények X darab részletét, pl. téma, ügy, időpont, esemény típus, esemény tartalma, van-e határidő) tudja, és viszonylag könnyen tanulható autodidakta módon.
erre rá kellene szánnod önállóan pár hetet, egy hónapot, és csak utána a tapasztalatokkal felvértezve, valós problémákon alapuló kérdésekkel megkeresni a releváns szaktopicot. idő közben kiderül, ha valamiért van olyan funkció amire szükséged van, de az excel nem tudja, viszont az access igen (meglepődnék) utána viszont az adatokat könnyű lesz már átvnni accessbe igény esetén.
minden tiszteletem a kollégáké, hogy ilyen türelemmel próbálnak segíteni de úgy gondolom hogy ebből eredmény akkor lesz ha a fentieket megfontolod.
-
nyugis21
kezdő
válasz
martonx
#5282
üzenetére
Értelemszerűen csak az adatbevitelre vonatkozott.
sztanozs
Dehogynem, a lekérdezéseknél az adatokat csak megjeleníti, átírásuk nem lehetséges, vagy csak előre tervezetten.Még mindig várom a választ a kérdésemre, hogy hogyan lehetséges-e a táblák átmásolása különböző adatbázisok között, mert láttam, hogy a sokféle különböző minta adatbáziban lényegében ugyan azok a táblák voltak alapként.
(furcsa, hogy csak egy választ engedélyez a fórum, akkor így írom, hátha így elfogadja.)
-
martonx
veterán
válasz
nyugis21
#5280
üzenetére
"Az egyik program az legyen, ahova minden este beírom, hogy aznap mi történt, dátum és óra szerint, hogy mi volt az ügy, mi történt, levél vagy telefon, vagy cselekedet, és ki hívott vagy írt levelet. Esetleg legyen megjegyzés, vagy figyelmeztetés, hogy ott valamire várni kell, vagy határidő van"
Ezt írtad, és igen, ezt egy excel sorba elég felvinned
-
-
nyugis21
kezdő
válasz
sztanozs
#5272
üzenetére
Helyes,akkor ez nekem való, a bíróságot meg nem akarom többet látni.
Sejtettem, amint a Northwin-det megnyitottam, hogy amit akarok, az jóval egyszerűbb, majd átnéztem a többit is, azt hiszem, a task és projekt ami részben kell nekem, de sok velük a gond.
Az első kérdésem:
Azt látom, hogy kis különbséggel azonos táblák vannak különböző fájlokban.Hogyan lehet a táblákat átmásolni másik access fájlba, vagy több access fájlból egyet csinálni, és a fölösleges táblákat törölni?
-
bambano
titán
"Kérdés, hogy a bíróság elfogadja-e ezt hitelesnek.": nem és nem.
tehát nem kérdés, nem fogadja el.
az elektronikus személyire pakolható elektronikus aláírás kettő évig érvényes, ezért az aláírás csak akkor érvényes, ha a dokumentumon olyan, magas biztonságú időbélyeg is van, amelyik az aláírás érvényességi idejébe beleesik. -
Szmeby
tag
válasz
nyugis21
#5271
üzenetére
Az alapvető probléma, hogy magyar "igazság"szolgáltatás tele van technológiai analfabétákkal, tisztelet a kivételnek. Ebből fakadóan a bíróság semmilyen mai szemmel nézve modern megoldást sem fogad el bizonyító erejűnek, mert nem ért hozzá. Nem érti, hogyan működnek a kriptogáfiai eljárások, hol vannak a gyenge pontjai, mely részei számítanak hitelesnek és melyek nem. Ezért aztán le van ragadva úgy a 19. századi technológia környékén, a közjegyző által hitelesített dokumentumok és tértivevényes levelek világában. Esetleg a telefonhívásokat még vissza lehet kerestetni... a telkók megőrzik elég részletesen a hívás adatokat sok évre visszamenőleg. Nem látnám akadályát, hogy ezeket egy bíróság kikérheti.
A saját magam által karbantartott adatbázist pedig ott hamisítom meg, ahol csak jólesik, ez alól az access sem kivétel. Ha a jogászok értenének hozzá, akkor emiatt sem fogadnák el bizonyítékként.
Vagyis maradnak a rendszeresen auditált, hiteles adatkezelési jogosítványokkal ellátott természetes és jogi személyek, akiket a társadalom, a bíróság hitelesnek ismer el, és ők nyilvánvalóan megkérik a szolgáltatásuk árát. Még a blockchainben való adattárolásért is kell fizetni, amit meg aztán végképp nem várom el a bíróságtól, hogy elismerjen, mert segghülye hozzá. Talán majd néhány évszázad múlva sikerül felnőniük a feladathoz, ki tudja.Persze ettől még vezethetsz naplót, van esély rá, hogy valaki jófej lesz és hisz neki. De arra mindenképp számíts, hogy a bíróság valószínűleg nem fogja elfogadni bizonyító erejűnek.
Idézetek gyűjtésére viszont jó megoldás a napló. Egy adatbázis erre a feladatra lehet, hogy ágyúval verébre kategória, de ki tudja, lehet később hasznos lesz majd, hogy gyorsan tudod szűrögetni a 26 millió soros tábládat... egy excel nem feltétlenül alkalmas ilyesmire. Vagy mit tudom én, egy új dolog megtanulásának öröme is lehet cél, az idézetgyűjtemény meg csak a bónusz.
---
Habár! Most eszembe jutott valami. Elvileg van egy személyi igazolványunk, amihez a drága magyar állam ingyen nyújt digitális aláírás szolgáltatást, hiteles időbélyegzővel, meg minden. Életembe nem használtam még, de talán ebből lehetne faragni egy talán a bíróság által is elfogadható megoldást. Ami hirtelen eszembe jutott, hogy csinálnék egy email fiókot egy megbízható szolgáltatónál, és a nekem fontos adatokat a saját email fiókomból a saját digitális aláírásommal aláírva elküldeném arra a címre. Kérdés, hogy a bíróság elfogadja-e ezt hitelesnek. Ingyen van, lehet benne keresni. Persze ez is csak az elküldés tényét és a hamisítatlanságot bizonyítja, az információtartalom helyességéről nem mond semmit. Na jó ez már nagyon offtopic.
-
martonx
veterán
válasz
nyugis21
#5271
üzenetére
Szia!
Ezekhez nem kell access. Amire te gondolsz az az Excel, aminek van még számtalan más ingyenes alternatívája.
Viszont semmi ilyet nem fog a bíróság bizonyító erejűnek elfogadni, de ettől még saját szórakoztatásodra / önmagad megnyugtatására miért ne vezethetnéd ezeket az adatokat. -
nyugis21
kezdő
válasz
sztanozs
#5269
üzenetére
Nem, angollal hadilábon vagyok, csak az írott szöveget értem valamennyire. Igaz, németet még annyira se, a francia és spanyol és más nyelvek pedig hottentotta kategóriák nekem.
Nem akarom megtanulni a programozást, meg akarok csinálni azokat, amikre szükségem van.
Elegem van abból, hogy azt mondják, hogy ahhoz fizetnem kell milliókat, amikor látom, hogy access-ben csak kattintgatnak és máris működik.Nemrég egy szélhámos megalázott a bíróságon, hogy összekevertem dátumokat és nem emlékeztem pontosan az adatokra, így még nekem kellett fizetnem azért, hogy átvert.
Két programra van szükségem, amiket meg akarok csinálni, ha már senki se akar segíteni nekem, akkor "magad uram" elv alapján, és amikor elakadok, akkor kérek majd továbblépéshez segítséget.
Az egyik program az legyen, ahova minden este beírom, hogy aznap mi történt, dátum és óra szerint, hogy mi volt az ügy, mi történt, levél vagy telefon, vagy cselekedet, és ki hívott vagy írt levelet. Esetleg legyen megjegyzés, vagy figyelmeztetés, hogy ott valamire várni kell, vagy határidő van, így ne legyen az, hogy valamiért nem kapom meg a levelet, vagy nem hívnak, és utána azt mondják, hogy de, hívtak és volt megállapodás.
Ha kell, akkor ott legyen, akár a bíróság számára is bizonyíthatóan, hogy pontosan mikor mi történt, és akkor már az adott ügy összes történését lehessen csak látni.
Bár már nem akarok többször bíróságra menni az életemben, csak meg akarom mutatni, hogy van egy lista a történésekről, így a szélhámosok már ne is próbálkozzanak többet.A másik program az idézeteknek legyen, nagyon pontosan emlékszem mondatokra, de nem tudom, hogy melyik filmből, vagy könyvből valók.
Ezek szerintem egyszerűen megvalósíthatóak, vagy legalábbis annyira, hogy segítséggel még én is össze tudom ezeket kattintgatni.
-
-
Taci
addikt
válasz
nyugis21
#5267
üzenetére
Nekem személy szerint Access-szel semmilyen tapasztalatom nincs, de persze általános SQL-kérdésekben szívesen segítek, ha tudok.
És eltanácsolást semmiképp nem fogsz kapni, szerintem nagyon jó, ha valaki belevág valami új dolog megtanulásába. És ez a fórum tele van segítőkész tagokkal, szóval szerintem jó helyen vagy. -
nyugis21
kezdő
Jó estét!
Friss nyugdíjasként belefogtam access adatbáziskezelő megtanulásába.
Ha van valakinek itt türelme segíteni nekem, amikor elakadok, megköszönöm.
Egyenlőre ennyi, ha már nem él a fórum, vagy nem kezdőknek való, nyugodtan jöhet eltanácsolás, hogy inkább hol próbálkozzak.
-
Taci
addikt
válasz
crmtanulo
#5263
üzenetére
Én ezeket mondanám:
- HTML: Ez a weblap tartalma, amit látsz, a szövegek, a képek.
- CSS: Ez formázza a HTML által visszaadott szöveget, képeket. Ez mondja meg, hol legyen, mekkora legyen, hogyan nézzen ki, animál stb.
- SQL: Ezzel kéred le az adatbázis tartalmát, ezzel írsz bele, frissíted, törölsz stb.
- PHP: Szerver oldalon ezzel kommunikálsz az adatbázissal (SQL-lekérdezésekkel), és dolgozod fel a tartalmát, készíted elő a lekérdezéseket, küldöd a klienseknek a visszakapott, feldolgozott adatokat stb.
- JavaScript: Kliens oldalon ezzel kommunikálsz a szerverrel, ezzel küldesz és kérsz adatot a szerver irányába, ezzel fogadod a szerver oldalról a PHP-n keresztül érkező adatokat, illetve a "kliensen történő kattintgatások" is ezen keresztül realizálódnak (pl. gombra kattintás mit csináljon). Továbbá módosíthatod vele a HTML tartalmát, manipulálhatod a megjelenést is, feldolgozhatod a PHP által visszaadott adatokat, illetve a másik irányba, a szerver (PHP) felé is adatokat küldhetsz.Nagyon nagy vonalakban.
Biztosan vannak egyszerűbb megoldások is, de én csak ezt ismerem, ahol én kontrollálhatok mindent, mert minden úgy működik, ahogy én írom meg. (Ennek összes előnyével és hátrányával.)
Ezeknek mindnek van külön topikja is (HTML, CSS, JavaScript, PHP és SQL (a jelenlegi topik)), illetve van egy általánosabb, a Weblap készítés topikja.
Illetve én a W3Schools oldalát ajánlom, példákon keresztül lehet megtanulni az alapokat, az összes említett nyelven/technológiával.
-
Ispy
nagyúr
válasz
crmtanulo
#5263
üzenetére
Ezekre nincsenek kész válaszok, ha egy webes alkalmazásról beszélünk, akkor kell egy adatbázis, egy weboldal és egy köztes réteg, ami a kettőt összeköti egymással, vannak különböző modellek, hogy hogyan is illik ezt felépíteni, és hozzá tucatnyi eszköz és program nyelv is.
-
crmtanulo
friss újonc
Ezt szeretném megtudni, hogy miért kell hozzá három másik programnyelv, és miért pont az a három kell hozzá?
Melyiknek mi a feladata?
Hogyan kapcsolódnak egymáshoz?
Hogyan kell gonlkozni, hogy a végén egy ilyen rendszer létrejöjjön?Nekem mindig csak "lépésről lépésre" dolgokat tanítottam, ezért utáltam a tanárokat is, csak egyet kedveltem, aki mindig azt mondta, hogy tudni kell a végcélt, hogyan kell a végén kinéznie az adatbázisnak, csak annak alapján lehet nekiállni megtervezni a lépéseket, különben állandóan módosítani kell mindent. A többiek nem szerették, ki is túrták.:-(
-
crmtanulo
friss újonc
Azt írtam, hogy ezen az alapszinten vagyok, meg tudom tervezni a táblákat és kapcsolatokat és megcsinálni a lekérdezéseket.
Azt szeretném tudni, hogy hogyan tovább, mi a következő lépés?
Hiába keresek könyveket, csak olyanokat találok, hogy adott programokat hogyan kell használni, nem találom az elméleti hátteret.Ezért regisztráltam ide, úgy láttam, itt nagyon tapasztalt programozók vannak, tudják, hogyan kell elméleti síkon gondolkozni, ezt szeretném megtanulni.
-
Ispy
nagyúr
válasz
crmtanulo
#5258
üzenetére
Ha érdekel a téma első körben javaslom a relációs adatbázisokkal az ismerkedést, mármint elméleti síkon, hogyan kell megtervezni a táblákat, a köztük lévő kapcsolatokat stb. Ha ez megvan, akkor nekiláthatsz a saját adatbázisod elkészítéséhez. Ez még messze nem program, ez inkább az egész alapja.
-
válasz
crmtanulo
#5258
üzenetére
"Hali, bocsánat, én még nagyon tanuló vagyok, nekem a CRM az egy korlátozott, vagy célfelhasználásra programozott SQL alapú rendszernek tűnik html támogatással."
És a mellékelt videóban szereplő szoftverhez még felhasználtak mondjuk 3 másik programnyelvet.
Ez olyan, mintha a Helyesírás topicba beírnád, hogy szeretnél egy profi szövegszerkesztőt írni, ami amúgy figyel a helyesírásra is.
Értjük, hogy érdekel a nyelvtan, jól megy a j/ly megkülönböztetése, de a Word konkurenciáját megírni nem innen indul.
Igazából ezért nehéz bármit is mondani erre, mert nem tudjuk, honnan kezdjünk neki.
A lényeg, hogy kezdj el ismerkedni a programozással, aztán egy idő után majd látod te is, hogy ez nagy falat, nem feltétlenül egy emberes célt tűztél ki magad elé. -
crmtanulo
friss újonc
Hali, bocsánat, én még nagyon tanuló vagyok, nekem a CRM az egy korlátozott, vagy célfelhasználásra programozott SQL alapú rendszernek tűnik html támogatással.
Jellemzően amerikai ügynököknek találták ki, hogy a határidőnaplójuk helyett közvetlenül számítógépbe írhassák már telefonálás közben az adatokat. Engem azért érdekel, mert a nagypapám bélyegeket gyűjt és kölcsönöz és cserél, és neki nagyon jó lenne egy ilyesmilyen program, mert az az előnye, hogy az adatokat kell csak begépelni, és létrehozza a táblák közti kapcsolatokat. Megjelenítéshez elegendő egy böngésző program, és minden olyan adat a képernyőn, aminek van további kapcsolata, linkként jelenik meg, rákattintva lehet látni az összes kapcsolatot.Itt egy példa, nem reklám miatt szánom, hanem, mert ha megállítják 1 percnél, majd 3:45-nél. akkor a bal oldalon láthatóak a tucatnyi táblák nevei. (két különböző lista van, de többnyire cég, ember, feladatok, telefon, eladás azonosak szoktak lenni.)
A pár perces, angol nyelvű video linkje:
https://youtu.be/ow44nHQPMJwEz nem mutatja a lényeget, hogy a definiált táblák a képenyőn kis ablakokként jelennek meg, és egy adat összes kapcsolatát lehet látni. Az ügynöknek az kell, hogy azt lássa, hogy egy cégre kattint, akkor megjelenik neki az egyik ablakban a cég cime, a név ablakban annak az embernek a neve, akivel felvette ott a kapcsolatot, a telefon ablakban a vele folytatott telefonbeszélgetések dátum szerint, a sales ablakban a vele kötött üzletek és hasonló.
Azt tartom benne nagyszerűnek, hogy ezek közül mondjuk a cég, az ember és a cím adatok linkként jelennek meg, így ha az emberre kattint, akkor látja, hogy hány cégnél dolgozik vagy dolgozott, ha a címre kattint, akkor látja, hogy azon a címen hány cég van vagy ki lakik ott.
Azon gondolkodok, ha ilyet tudnék csinálni, akkor a cég helyett a bélyeggyűjtemény lenne, a nevek, telefonok, címek maradnának, az eladás helyett a csere lenne, és rögtön látná a nagypapám, hogy melyik bélyeget kitől szerezte be és kiknek kölcsönözte vagy cserélte vagy adta el.
Most excelt használ, állandó probléma az adatvesztés, és ugyan ez lenne bármilyen adatbáziskezelőben is.
Ez a crm megoldás viszont védi az adatokat a vétlen felülírástól, csak egyesével lehet törölni vagy módosítani őket, hiszen akkor a kapcsolatok is változnak a táblák között.Remélem, érthetően írtem, még nagyon kezdő vagyok, csak a megoldás tetszik, illetve az, hogy egyszer kell kitalálni az összes kapcsolatot, és attól kezdve van egy végleges megoldás.
Persze a hátránya az, hogy nincs lehetőség később új táblákat belevinni, mert - ahogy feltételezem - a kapcsolatok az adatok beírásakor jönnek létre, utólag nem lehet tömegesen módosítani őket, mint egy sql adatbázisban.
A másik, ami nagyon izgat, hogyan csinálnak linket az adatokból, feltételezem, a linkek mögött az előre definiált lekérdezések vannak, amikkel az összes kapcsolódó adatot megjelenítik a képernyő többi ablakában.
Ennyit látva úgy gondolom, ehhez kell mondjuk egy mysql, amit mondjuk XAMPP vagy hasonlóban lehet használni, és akkor nem kell web sem, de még mindig nem tudom, hogyan lesznek a képernyőn megjelenített adatok egy részéből html-es linkek.
A crm programoknál persze az a csali, hogy lehet ingyen használni, csak éppen nagyon minimális funkcióra és webes hozzáférést meg havi díjat és adatkarbantartást kell fizetni, satöbbi, de nekem nem is ez a lényeg, hanem az, hogyan tudok egy hasonlót csinálni, mert azt sejtem, hogy az nem megoldás, hogy átnevezem mondjuk a sales ablakot cserére, mert mások lesznek a kapcsolatok.
Jajj, kitört belőlem a grafománia, most meg leszek kövezve, hogy nem tudtam két mondatban leírni mindezt.
Bocsánat, tényleg nem tudok röviden beszélni, apám szerint azért, mert anyám állandóan szappanoperákat nézett a terhessége alatt.
-
Sokimm
senior tag
Kérném az iránymutatásotokat, hogyan épül fel egy normális rendszer?
A tervem egy MySQL háttérre ráépíteni valami JAVA rendszert, amit valamiféle webes (HTML5) felületen elérheti a user. A script-et kerülném ha lehetséges.
A fejlesztés OFFLINE asztali pc-n hajtanám végre, majd az élő rendszert intraneten adnám át.
Véleményeket, kritikát, minőségbeli javulást okozó tippeket elfogadnék a rutinosabbaktól.
-
Taci
addikt
Izgalmasan hangzik.
Bár élvezetes valószínűleg akkor lehetett (volna), ha nem tegnapelőttre kérik a megoldást. De azért ez az eredmény biztosan nagyon jó érzéssel tölthetett el. SQL-ben már nem volt több nyitott kérdés a listámban, csak ez a kettő, ezért tettem fel így a végén. Közben még JS- és PHP-oldalon van teendőm (a tesztek során ami hibát találtam, összeírtam, azokat javítom, és tesztelem újra).
Nagyon szeretném már elindítani az oldalt. Eredetileg nyár elején akartam, viszont ott vettem észre, hogy az SQL-oldalt nagyon rosszul raktam össze. Most már (a Ti segítségeteknek hála
) az a rész úgy néz ki, rendben lesz.
De ha már ennyit "késtem", nem kapkodom, próbálok átgondolni mindent, előre is tervezni. Inkább induljak később, de minél kevesebb probléma legyen a későbbiekben - főleg ha azokat még most "elkaphatom". (De azért kategorizáltam a To-do lista elemeit is, van, ami azonnal megoldandó (mert rosszul működik, rossz eredményt ad stb.), de van amit v1.1-ként jelöltem csak, hogy majd indulás után ráér bőven.) -
nyunyu
félisten
Egyelőre szerintem indulj el, aztán ha már úgy látszik, hogy a táblaméretek növekedésével egyre lassabb, akkor ráérsz optimalizálni.
Akkor már úgyis lesz elég adatod a felhasználói szokásokról, és egyértelműbben kirajzolódik, hol van a szűk keresztmetszet.1% sebességnövelésre nem érdemes napokat elszúrni.
Nekem is volt olyan projektem, ahol engem cseszegettek állandóan, hogy túl sokáig fut nagy ügyfelek esetén az adatmigráció teljességét vizsgáló querym, végül már a DBA guruink optimalizálták, de úgy sem lett sokkal jobb a helyzet, talán 10%-ot tudtak nyerni az indexeléssel és egyéb mágiával.
Legnagyobb telefonelőfizető vállalatot 12 óra alatt tudtuk végigkergetni, ebből 2-3 óra volt az adatkonverzió, és 9-10 az adathelyesség+teljesség ellenőrzés.Aztán projekt végén távoztak a főokosok, akik az adatellenőrző motort fejlesztették, és én örököltem meg a kódjukat a következő projekthez, mondván van már elég gyakorlatom a ellenőrző funkciók írásában.
Sikerült beüzemelni, főnököm elment demózni, hogyan lehet egy mozdulattal megszüntetni 120 ezer előfizetést, aztán 20 perc múlva idegesen telefonál, hogy még mindig nem jött be a következő képernyő.
Végül valami 2 óra volt, mire egy táblában szereplő 120 ezer rekordot sikerült kikeresni pár másik táblából, és a demó alkalmazás továbblépett a következő képernyőre.Kézzel megfuttattam ugyanazt az ellenőrző queryt, 3 perc alatt lefutott.
Na, akkor jobban nekiálltam átnézni az ellenőrzéseket futtató motort, és észrevettem, hogy a kolléga minden rekordra, minden egyes query futtatására kurzort használt, így a tömeges adatellenőrzésre szolgáló query annyi példányban futott libasorban, ahány sor volt a táblában
Plusz megfejelve a dinamikusan összerakott SQL futattatásának a hívásonkénti overheadjével (120e rekordnál az bő egy óra!)Utána egy hétig faragtam az örökölt kódot, mire kiírtottam belőle az összes létező kurzort, hogy az összes query az egész adathalmazra egyben fusson, és egyszer legyen csak dinamikus SQL hívva.
Eredmény? 2 óra helyett 3 perc.Ha visszaportoltam volna az újraírt motort a migrációs projektbe, akkor "kedvenc" nagyvállalatunkat 12 helyett 3 óra alatt le tudtuk volna futtatni, ugyanazokkal az ellenőrző querykkel...
Szóval az optimalizálnivaló nem mindig ott van, mint amire először gondolnál!
-
Taci
addikt
Köszönöm a magyarázatot, így már világos.
@martonx: Neked is.
Amúgy csinálom, folyamatosan. Azért jött fel ez a legutóbbi két kérdés, mert anno amikor nagyon-nagyon elakadtam, akkor találtam egy srácot, aki órabérben ránézett az egészre, ő tett jó pár javaslatot és kommentet, és ezeket én feljegyeztem (a to-do listámba). Vele azóta sajnos nem tudtam beszélni, a kérdések pedig ott voltak nyitott pontként, és most, hogy végre a keresés részét is rendbe raktam (és a hozzá kapcsolódó pontok kikerültek így a listából), utamba került ez a két kérdés is, ezért kértem tanácsot velük kapcsolatban. Mert ha olyan dolgok lettek volna, amikkel előre számolnom kell (és a kódokat hozzájuk igazítanom), akkor még indulás előtt történjen.
Köszönöm a türelmeteket és a segítségeteket. -
nyunyu
félisten
Indexet csak a leggyakrabban keresett/joinolt oszlopokra érdemes tenni.
Ha a hébe-hóba kérdezett feltételeket is indexeled, azzal többet ártasz, mint használsz, mert az új rekordok beszúrása, illetve régiek törlése is lassul minden egyes plusz indexszel.Törlés+index létrehozás, újraépítés max akkor segít, ha nagyon sok rekordot töröltél a táblából, és emiatt lyukas lesz az index, és nem működik optimálisan.
De ez megint a többmillió soros táblák problémája, alatta jellemzően nem nyersz sokat azzal, hogy újraépíted.Szélsőséges példa: van egy millió soros táblád, ennek az indexe is millió rekordot tartalmaz.
Kitörölsz a táblából 900k rekordot, ekkor az index mérete nem változik, továbbra is 1m helyet foglal, lesz benne 900k lyuk.
Újraépítés után az index mérete lecsökken a maradék 100k-ra, így 10x gyorsabban lehet majd végigmenni rajta, mint újraépítés nélkül.
(B-fáknál log2(10) a gyorsulás?) -
martonx
veterán
1. Ember csináld már meg amit akarsz, ne tökölődj a mi lesz majd 50 év múlva ha nyerek a lottón szintű problémákon.
2. amit linkeltél MS SQL-re vonatkozik, tudtommal te valami játszós DB-t használsz (MariaDB vagy MySQL vagy valami ilyesmit).
3. Egyébként igen, van amikor karban kell tartani az indexeket, nyugodj meg, te sose futsz ilyen esetbe bele, vagy ha igen, addigra már rég milliárdos leszel, és lesz DB admin embered, aki majd elszórakozik az ilyen problémával. -
Taci
addikt
Az indexekkel kapcsolatban annyit hadd kérdezzek már még, hogy kell-e őket valahogy "kezelni, karbantartani"? Van nekem bármi dolgom velük a létrehozásukon kívül? Mert elsőre azt gondolnám, hogy minden más már a rendszer dolga lenne, de azért inkább rákérdezek, hátha figyelnem kell (majd idővel) valamire, bármire.
Első körben ezt találtam: [link]
Ezt úgy tudom elképzelni, hogy (maintenance módban) az indexeket újraépítem majd, ha szükség lesz rá (törlés, és újra létrehozás), ahogy írja is.
-
-
nyunyu
félisten
válasz
martonx
#5241
üzenetére
ElasticSearchtől azóta kapok sikítófrászt, mióta kedvenc adóhatóságunk olyat szeretett volna az adószámla egyenlegek tárolására + napi újraszámolására, mert az menő, passzol a mikroszerviz architektúrába, és jól skálázható. (meg ingyenes(?) a licensze, tehát többet lehetett volna a projektből khm. megtartani)
Szerencsére főnökömnek sikerült megértetnie velük, hogy nagy mennyiségű, jól struktúrált adat kezelésére rendes RDBMS való, meg arra találnak hozzáértő szakembereket is, sok tapasztalattal.
Aztán a projekt végén, amikor csak a mi modulunk készült el határidőre (emiatt nem kellett meneszteni a projektért felelős álomtitkárt, meg az illetékes vezérőrnagyokat a sóhivatalból), akkor jól le lettünk szúrva, hogy de hát az architektúra szerint semmi SQL nem lehet a kódban, hol van az ElasticSearch, így nem veszik át.
Közben a projektmenedzseri divatlapokban olvasott menő három-négybetűs buzzwordökből összeollózott szent architektúrát szolgaian követő többi fejlesztőcsapat 2 év alatt 2 év késést hozott össze
-
nyunyu
félisten
Azt neked kell végiggondolni, hogy a táblád legszélesebb oszlopát indexelni akarod-e.
Ha igen, az (közel) megduplázza a tábla helyigényét, de legalább minden beszúrás, törlés művelet sokkal lassabb lesz, hiszen az indexet is karban kell tartania.Kérdés, hogy ez megéri-e azt, hogy néha-néha like '%%'-kal akarj benne keresni.
De mivel egy sokszázezer soros táblára tett többezer karakter széles index sem fog beleférni a memóriába, így szerintem tökmindegy, hogy az eredeti táblán megy a full table scan, vagy a nem sokkal kisebb indexet kell végigolvasnia először, és csak utána éri el a táblát.
Gyors az nem lesz... -
martonx
veterán
Szerintem megválaszoltad magadnak. A hídon majd ráérsz akkor átmenni, amikor odaértél.
Egyébként is van sok lehetőséged, én a helyedben, amikor a mostani megoldás elkezd kevés lenni (ha lesz ilyen), akkor első körben megpróbálnám a felvázolt full text search-öt SQL oldalon megvalósítani.
De ennél is jobb tud lenni, ha beüzemelsz egy ElasticSearch szervert az SQL-ed fölé, és ez szolgálja ki a szöveges kereséseket. Bár ez elég overkill. -
Taci
addikt
Lenne egy egyelőre csak elméleti kérdésem.
Ha jól tudom, valahogy összefüggésben van az indexelt mezők száma, illetve az adatbázisba való írás sebessége: minél több mező van indexelve, talán annál több idő a rekordok adatbázisba való írása. Ezt jól tudom?
Azt szeretném kideríteni, van-e olyan "váltópont", ahonnan már annyira belassulna az adatbázisba való írás, hogy nem érné meg az indexelés használata.
A kérdés háttere:
5 percenkénti kb. 100-400 új rekorddal számolva (még ezt nem tudom, mennyi lehet valósan, de itt körül, szóval legyen ennyi a példa kedvéért) megéri-e full text search-re átállnom a gyorsabb keresés kedvéért?
Ehhez ugye be kell állítanom full text indexet azokra a mezőkre, amiben keresni akarok. Pl.:
ALTER TABLE feed ADD FULLTEXT(title)
ALTER TABLE feed ADD FULLTEXT(description)Viszont mivel elég sok rekord kerül a táblába folyamatosan, azt szeretném kideríteni, hogy emiatt (és a többi) indexelés miatt lehet-e gond később (bármikor, akármikor) a teljesítménnyel, esetleg belassulhat-e annyira az adatbázisba való írás, hogy az 5 percenkénti cron job "túl sűrű" lesz, mert ennyi idő alatt nem végez az új rekordok tárolásával?
Lehet, hogy teljesen alaptalan a "félelmem", de ez a kérdés bennem van már egy ideje, de még csak most jutottam a keresés rendbe tételéhez.
Jelenleg jobb híján a LIKE %%-os keresést használom, kb. 1 mp a lekérdezési ideje egy 300e-res táblánál, szóval nem vészes, úgyhogy az sem tragédia, ha ez marad egy ideig. Plusz a full text search-keresés amúgy sem olyan egyszerű, mint jó lenne.
-
#5238
nyunyu
félisten
Apollo17hu
#5237
nyunyu
félisten
válasz
Apollo17hu
#5237
üzenetére
Rekurzió az matematikalag elegáns, gyakorlatban meg nagyon nem praktikus, akármelyik programnyelvet nézem.
-
#5237
Apollo17hu
őstag
nyunyu
#5236
Apollo17hu
őstag
Hat, azt nem tudom, hogy mi hogyan irodhatott, de abban nagyon igazad van, hogyha az ember nem gyakorlott benne, akkor elegge necces a hasznalata. Egy kivalasztott peldara meg nehany masodperc alatt lefutott a kodom, de szazmillios rekordszamom van, ugyhogy inkabb elengedem a rekurziv temat. Igazabol csak egy szep megoldast kerestem, mert mas modon kozel 100%-os pontossaggal meg tudom hatarozni az ertekeket - es szerencsere ez most eleg.
-
#5236
nyunyu
félisten
Apollo17hu
#5224
nyunyu
félisten
válasz
Apollo17hu
#5224
üzenetére
Hmm, jobban megnéztem ezt a részt:
with cte(id,ertek,runningsum,seqnum) as
(select 0.szint
union
select n+1. szint)
select ... from cte;Ez pont ugyanúgy néz ki, mint amit a Teradata 13 tutorialokban láttam anno.
Ezek szerint az már szabványosított rekurziós szintaxist használhatott?Mondjuk a Teradata mindig hamarabb implementálta az új SQL szabványokat, mint az Oracle
-
Nem biztos, hogy értem, hogy mit szeretnél...
Egyrészt a tűblákat érdemesebb volna ID-val csinálni (mert mi van, ha van két ugyanolyan nevű Kis Péter), de ha eddig nem kézzel volt szinkronizálva a tábla, hanem valami automatizmussal, akkor működhet a mezők "összekötése" utólag is.
Amúgy a harmadik tábla csak egy query lenne, vagy ott is tárolnál valami plusz infót?
Valahogy így raknám össze, ha sokat nem akarnék vacakolni:
De rendesen, Id-kkal valahogy így nézne ki:
-
#5234
nyunyu
félisten
Apollo17hu
#5224
nyunyu
félisten
válasz
Apollo17hu
#5224
üzenetére
Tényleg, a CTE szabványosításának az is volt a célja, hogy az addigi, DB függő szintaxis helyett könnyebben lehessen rekurzív queryket írni.
De sosem szerettem rekurzív kódot írni, mert nagyon könnyen beláthatatlan tud lenni.
-
nyunyu
félisten
Ha nagyon gonosz akarnék lenni, akkor:
UPDATE new_table
SET Parameter1=old_table.Parameter1
WHERE old_table.AzonosParameter = new_table.AzonosParameter;(30+ évvel ezelőtti Teradata szintaxis, még a FROM clause bevezetése előttről.
Kellett nekem ilyenekre SQL parsert írnom adattárház gyakornok koromban.)Ha meg nem akarnék az lenni, akkor:
MERGE new_table u
USING old_table o
ON (u.AzonosParameter = o.AzonosParameter)
WHEN MATCHED THEN UPDATE
SET Parameter1=o.Parameter1; -
#5228
nyunyu
félisten
Apollo17hu
#5214
nyunyu
félisten
válasz
Apollo17hu
#5214
üzenetére
Az a baj, hogy az előző lépésben számolt értékre van szükséged a következő kiszámolásához, és nem szimplán szummázod a korábbi értékeket.
Így vagy rekurzívan számolod ki, vagy ciklust írsz rá.
Ezekre nem nagyon van szabvány szintaxis, kb. minden DBnek más megoldása van rá.
Oracle alatt valahogy így nézne ki a ciklusos megoldás:
DECLARE
v_id varchar2(10);
v_ertek number;
v_korr_ertek number := 0;
CURSOR c is
SELECT id, ertek
FROM proba
ORDER BY id;
BEGIN
OPEN c;
LOOP
FETCH c INTO v_id, v_ertek;
EXIT WHEN c%notfound;
v_korr_ertek := CASE WHEN v_korr_ertek + v_ertek > 0
THEN 0
ELSE v_korr_ertek + v_ertek
END;
dbms_output.put_line(v_id || ',' || v_ertek || ',' || v_korr_ertek);
/*
UPDATE proba
SET korr_ertek = v_korr_ertek
WHERE id = v_id;
*/
END LOOP;
CLOSE c;
END;Deklarálsz egy kurzort, amiben azonosító szerint növekvő sorrendben jönnek a rekordok, aztán azon egyesével végig mész, kiszámolva az aktuális korrigált értéket.
-
Sokimm
senior tag
UPDATE new_table
SET new_table.Parameter1=old_table.Parameter1,
FROM new_table
INNER JOIN old_table ON old_table.AzonosParameter = new_table.AzonosParameter
;
Az uj tablat szeretném frissiteni, amiben beállítódik a Parameter1 (régiből az újba), az (FROM) új táblából..?
Egyesítsük az old table-t ha a régi és új tábla azonos paramétere egyezik.
Ez így nem megy.
Megint mit rontok el?
Most jön a merge próba. -
#5226
Ispy
nagyúr
Apollo17hu
#5224
Ispy
nagyúr
válasz
Apollo17hu
#5224
üzenetére
Szegény utókor.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#5224
Apollo17hu
őstag
Apollo17hu
#5214
Apollo17hu
őstag
válasz
Apollo17hu
#5214
üzenetére
Többé-kevésbé sikerült összeraknom. Álljon itt az utókornak:
WITH t AS(SELECT t.id,t.ertek,row_number() over(ORDER BY t.id) AS seqnumFROM (SELECT 'A' AS "ID",-2 AS "ERTEK" FROM dualUNION ALLSELECT 'B',-5 FROM dualUNION ALLSELECT 'C',-1 FROM dualUNION ALLSELECT 'D', 3 FROM dualUNION ALLSELECT 'E',10 FROM dualUNION ALLSELECT 'F',-7 FROM dualUNION ALLSELECT 'G',-4 FROM dualUNION ALLSELECT 'H',20 FROM dualUNION ALLSELECT 'I',-1 FROM dualUNION ALLSELECT 'J',-3 FROM dual) t),cte(id,ertek,runningsum,seqnum) AS(SELECT ID,ertek,(CASEWHEN ertek > 0 THEN0ELSEertekEND) AS runningsum,seqnumFROM tWHERE t.seqnum = 1UNION ALLSELECT cte.id,t.ertek,(CASEWHEN t.ertek + cte.runningsum > 0 THEN0ELSEt.ertek + cte.runningsumEND) AS runningsum,t.seqnumFROM cteJOIN tON t.seqnum = cte.seqnum + 1/*AND t.id = cte.id*/)SELECT cte.ertek, cte.runningsum AS korr_ertekFROM cteORDER BY seqnum -
nyunyu
félisten
Tudom, Teradata huszonévvel ezelőtti szintaxisát emelték be az SQL Server 2008-ba, ami sosem volt szabványos.
Mondjuk a Teradatának volt egy olyan hasznos fícsöre, hogy csak a sikeresen illesztett sorokon updatelte a cél táblát, míg ha Oraclenek valami ilyesmit írtál:
UPDATE tábla1 u
SET u.valami = (select valami from másiktábla a where a.id=u.id);Akkor a nem illeszkedő sorokat is felülvágta NULL-lal
(Nem emlékszem pontosan az elszabott Oracle szintaxisra, helyette mindig MERGEet írtam.) -
Ispy
nagyúr
Hun van a selectből a join?
Ezt a where-es megoldást ne erőltesd, én nem legalább is nem szoktam:
update x set mező=...from xinner join y on x.mező=y.mezőÍgy csak azokat fogja frissíteni, ahol x-ben és y-ban is megtalálható a kapcsolat alapján a rekord.
Ez mondjuk nem access, hanem ms sql, már rég nem accesseztem, szerencsére, de hátha megeszi.
Kicsit furán kezeled az accesst, mint valami excel táblát.
Nem mint egy relációs adatbázist.A gyémánt operátor egy kapcsos zárójel (leánykori nevén), ebben az esetben gondolom nincsen from és paraméterként értelemzi az access, egyébként ms sql-ben így illik a mezőkre hivatkozni, mert egyébként ha a mező neve egy operátor is, akkor a fordító nem tudja mit akarsz és hibára fut. Vagy ha gyilkos modon szóköz van a mező nevében, akkor is megpusztul. Ilyenkor a kapcsos zárójel közötti részt mezőként értelmezi.
Egyébként valami ilyesmi is lehet a megoldás:
update x set mező=....from x, ywhere (x.mező=y.mező)Csak én rosszul vagyok ettől a sytanxistól.
-
Sokimm
senior tag
A gyerekekkel való példa csak példa, az adatok "értelmezéséhez" kellett, bár lehet elég bénán fogalmaztam, ettől függetlenül siekrült a művelet, köszönöm a segítséget (mindenkinek!).
(hogy válaszoljak is: Azért kell a 2 táblából egy 3.at csinálni, hogy merge-öljem az összes adatot egybe, de "logika" alapján. Az első 2 tábla majd megy a levesbe, a 3. lesz használva csak a jövőben)
Ezért nem elég csak egy lekérdezés, fontos a friss táblába mozgás.
Most viszont a WHERE résszel szenvedek (megint szerintem szintaktika), mert mindig kér kezdő paramétert SQL futtatásakor.
Most nem írok béna példát, csak a szintaktikát kérném segítsetek megérteni.
(Nem tudom mikor használunk gyémánt operátort, vagy [...] ilyet, meg a sima zárójeleit se értem a Microfos-nak.
)
A hibám az, hogy a WHERE végén lévő Zenetagozatosok.NEV mindig kér kezdő paramétert SQL futtatásakor, nem képes a két tábla azonos oszlopát összehasonlítani automatán.
UPDATE ...
SET ...
WHERE (((ÖsszesGyerekTabla.NEV)=([Zenetagozatosok].[NEV]))); -
#5217
pch
senior tag
Apollo17hu
#5214
pch
senior tag
válasz
Apollo17hu
#5214
üzenetére
Ha csak annyi hogyha nagyobb mint 0 akkor legyen nulla akkor arra ott az if
IF(eredmeny>0,0,eredmény) -
#5215
nyunyu
félisten
Apollo17hu
#5214
nyunyu
félisten
válasz
Apollo17hu
#5214
üzenetére
Mint az egyszeri matekpélda, ahol az első megállóban felszáll 2 ember a buszra, másodiknál leszáll 5, akkor hány embernek kell felszállnia a harmadiknál, hogy senki ne legyen a buszon?
-
#5214
Apollo17hu
őstag
Apollo17hu
őstag
Sziasztok!
Kumulálás témában kérem a segítségetek. Pozitív és negatív egész számaim vannak egy mezőben. Egy másik mezőben azonosító szerepel, a rekordok e mentén vannak rendezve.
Az a feladat, hogy a számokat kumuláljuk, de a kumulált érték nem lehet magasabb nullánál. Tehát ha az aggregálás "átfordulna" a pozitív tartományba, akkor ott 0-nak kell szerepelnie.Így néz ki a modell, amiben a 3. oszlopot kellene létrehoznom:
ID ERTEK KORR_ERTEK
A -2 -2
B -5 -7
C -1 -8
D 3 -5
E 10 0
F -7 -7
G -4 -11
H 20 0
I -1 -1
J -3 -4
Sajnos sqlfiddle hibát dob, ezzel próbálkoztam:CREATE TABLE proba (id varchar2(10),ertek number);INSERT INTO proba([id], [ertek])VALUES('A',-2),('B',-5),('C',-1),('D',3),('E',10),('F',-7),('G',-4),('H',20),('I',-1),('J',-3);Milyen módon lehetne kiszámolni a KORR_ERTEK mezőt?
Maga a kumulálás ezzel működik, de a nullával való korrigálásra nem jöttem rá:
SUM(ertek) OVER(ORDER BY id) -
nyunyu
félisten
Nem teljesen értem, mire való a második táblád.
Ha ebben csak a lehetséges táborozási opciók vannak felsorolva, és a harmadik táblába viszed fel a beérkezéskor, hogy melyik gyerek melyik opciókat kéri, akkor a harmadik táblába csak a gyerek nevét (vagy elsődleges azonosítóját/kulcsát), és az opció azonosítóját kell letárolnod.
Ha a második táblában előre le vannak tárolva, hogy melyik gyerek mit kért (gyerekneve/azonosítója, opció párosként), akkor a harmadik tábla helyett kellene egy lekérdezés vagy nézet, ami ebből egy mátrixot rajzol.
valahogy így:
select nev, vega, reggeli, ebed, vacsora, szamtech, lovas, uszas
from (
select x.nev,
max(x.vega) vega,
max(x.reggeli) reggeli,
max(x.ebed) ebed,
max(x.vacsora) vacsora,
max(x.szamtech) szamtech,
max(x.lovas) lovas,
max(x.uszas) uszas,
from (
select gy.nev,
case when o.opcio = 'Vega' then 'I' else '' end vega,
case when o.opcio = 'Reggeli' then 'I' else '' end reggeli,
case when o.opcio = 'Ebéd' then 'I' else '' end ebed,
case when o.opcio = 'Vacsora' then 'I' else '' end vacsora,
case when o.opcio = 'Számítástechnika' then 'I' else '' end szamtech,
case when o.opcio = 'Lovas' then 'I' else '' end lovas,
case when o.opcio = 'Úszás' then 'I' else '' end uszas,
from gyerekek gy
join opciok o
on o.gyerek_id = gy.id) x --vagy o.nev = gy.nev, ha nevet tárolsz
group by x.nev);Ennek az eredménye egy ilyen táblázat lesz:
NEV VEGA REGGELI EBED VACSORA SZAMTECH LOVAS USZAS
Kiss Péter I I I I
Nagy Anett I
Török Flóra I I I(Bocs, nem nagyon vágom az Accesst, de elvileg szabvány SQL-ben is meg lehet feléje fogalmazni a kéréseket.)
-
-
-
-
nyunyu
félisten
Ugyanúgy, where alá megy a szűrő alquery:
SELECT f.item_id, f.item_date
FROM
(SELECT item_id, item_date
FROM items
ORDER BY item_date ASC LIMIT 1000) AS f
INNER JOIN items_categories AS fic
ON f.item_id=fic.item_id
WHERE f.item_id not in (select t.item_id
from items_categories t
where t.category_id IN (27))
GROUP BY f.item_id, f.item_date
ORDER BY f.item_date ASC LIMIT 4Tehát a termék-kategória párosokból leválogatod azokat a termékeket, akik a nemszeretem kategóriában vannak, és ezzel szűröd az eredeti terméklistát.
-
Taci
addikt
Ezért is fontos a QA.
Meg a lomtár. Én most egy kicsit értetlenül is álltam a dolog előtt, mert egy ilyen hibát észrevettem volna ennyi idő alatt (már kerestem egy ideje, nem egyből ide jöttem segítséget kérni).
Aztán rájöttem, hogy egy régi lekérdezést mutattam példának, azt átalakítva a problémához - viszont a problémás lekérdezés nem ez volt...
Szóval most átírtam a példához újra: DB Fiddle
De hátha ez is egy teljesen egyértelmű hiba részemről csak, hogy itt nem úgy működik, ahogy szeretném.
Ránéznél, kérlek?
-
nyunyu
félisten
Ugyanezt benéztem nemrég melóban.
Még szerencse, hogy a tesztelők is átnézték a GDPR törlendő szerződések listáját, és kiszúrták, hogy a left join tiltolista + where tiltolista.id is not null átengedte azokat a szerződéseket, ahol csak az egyik ügyfél volt tilitólistás, másik nem.
Írhattam át a queryt where ügyfél not in (select id from tiltolista)-ra. -
Taci
addikt
Saját kútfőből erre jutottam: DB Fiddle
Van esetleg valakinek jobb/másabb ötlete? Valós adatbázison még csak most fogom kipróbálni, nem tudom, mennyire lehet gyors/lassú.
@nyunyu: Most látom csak, hogy írtál, máris nézem, köszönöm.
Oh, valóban, pont ellenkezőleg gondolkodtam... Köszönöm az irányba állítást! -
nyunyu
félisten
Fordítva gondolkozol.
Nem azokat kell megmutatni, amik nem 27-es kategóriájúak, mert akkor a többszörös kategóriából csak azt az egy példányt zárod ki, nem az összeset.
Helyette azokat a termékeket nem szabad megmutatni, amik 27-esek.
Úgy biztosan kizárja a terméket, akárhány kategóriába tartozik is a 27-esen kívül.SELECT item_id, item_date
FROM items
WHERE
item_id NOT IN (select item_id from items_categories where
category_id in (27))
ORDER BY item_date ASC LIMIT 4
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
- Path of Exile 2
- Kerékpárosok, bringások ide!
- Apple iPhone 16 Pro - rutinvizsga
- Béta iOS-t használók topikja
- One otthoni szolgáltatások (TV, internet, telefon)
- A fociról könnyedén, egy baráti társaságban
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Milyen processzort vegyek?
- Google Pixel topik
- További aktív témák...
- Lenovo X13 Yoga 2in1 Thinkpad WUXGA Touch i5-1145G7 vPro 16GB 256GB 4G LTE GPS Win11 Pro Garancia
- LG K61 128GB, Kártyafüggetlen, 1 Év Garanciával
- HIBÁTLAN iPhone 12 mini 128GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3400, 94% Akkumulátor
- Ritkaság! Új! Microsoft Surface Laptop 5 Alcantara 13.5" i5-1245U 16GB 1000GB 1év garancia
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest