Hirdetés
- Magga: PLEX: multimédia az egész lakásban
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- MasterDeeJay: i7 4980HQ asztali gépben (vs i7 4770)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- ldave: New Game Blitz - 2025
Új hozzászólás Aktív témák
-
-
martonx
veterán
válasz
Gergello
#5662
üzenetére
A többi alternatíva, amit ajánlottam sem fizetős. Más kérdés, hogy azoknak a hosztolását meg kell oldanod valahogy, ami végülis pénzbe kerül. Nekem pl. MeiliSearch lakik egy 1 magos Azure linux VM-en, kemény havi 15 EUR-ért (plusz áfa).
Hidd el, ezek a kereső cuccok sokkal jobbak, mint amit magadnak raksz össze, pl. typo tűréstől kezdve csomó mindent tudnak. -
martonx
veterán
válasz
Gergello
#5660
üzenetére
Inkább javaslom erre beüzemelni egy ElasticSearch-öt / MeiliSearch-öt, vagy legfapadosabb megoldásnak a Google Custom Search Engine-t behúzni az oldaladra, és azzal keresni. De majd mindjárt jönnek az SQL szakik, és jól ledorongolnak, hogy nem SQL-ben oldanám ezt meg.
-
martonx
veterán
Külön programmal. A DB csak tegye ki egy külön táblába, hogy kiknek kell emailt küldeni.
Aztán majd egy külön program ez alapján kiküldi a saját workflowja alapján.
Így a DB is csak azt teszi, amihez ért, és majd a programozó is azt teszi amihez ért (rem,élhetőleg). Ráadásul az email küldés egészen bonyolult is lehet retry policy-vel, fogadottság ellenőrzéssel stb....
A mindent DB-vel megoldatásban óhatatlanul ott van a deadlockok, bármilyen más okból db lockok okozása, amivel vicces módon mondjuk egy sima email küldéssel akár a komplett DB-det is bedöntheted, pedig de jó ötletnek tűnt emailt küldeni a DB-ből (mondom ezt úgy, hogy bármikor elismerem nem vagyok DB szakértő, de régebben láttam már MS SQL-t megállni, valami ilyen huszadrangú jó ötletnek tűnt feature megakadása miatt).
De nyilván mindenki akinek kalpácsa van, az utána mindent azzal akar megoldani, klasszikus probléma. Rám is igaz lehet az előbbi, hogy minél több mindent inkább külön programmal oldanék meg, simán lehetnek esetek, amikor nem ez a jó megközelítés pl. irdatlan adatmennyiségek esetén. -
martonx
veterán
Ez mégis mi a f....sz?
Ez a youtube videó annyi sebből vérzik. Asp.Net Webforms 2022-ben???
Kézzel megírt SQL parancsok 2022-ben????
És mindehhez a zseniális indiai akcentus. Régi szép emlékeket idéz, amikor együtt dolgoztunk indiaiakkal, és nap, mint nap a röhögéstől sírva meséltük a programozós horror sztorikat egymásnak a cégnél a kollégákkal. Bár akkor ezt megélni inkább tragikus volt, mára szép és kitörölhetetlen emlékké halványult
-
martonx
veterán
Áhá így már értem. Bocs az elején félreértettelek. Mivel SQL-t használsz, jobb módja nincs. Más módok is vannak persze, pl. beüzemelsz egy külön NoSql-t ehhez, inmemory SQL táblát használsz, felhőben valami Queue-ba dobod be az eventeket, és majd onnan egy microservice a maga nyugijában updatelgeti a DB-t, stb...
-
martonx
veterán
Szerintem egy kicsit kevered a dolgokat. A backup nem erre való. Backupolni elég naponta egyszer (gondolj bele, amikor X TB-os DB-ket 2 óránként próbálna meg bárki menteni
) . Amire te gondolsz az inkább egyfajta tükrözés, amikor két DB-d van, és időnként a másikba átszinkronizálod az adatokat.
Illetve még olyat szoktak, hogy inkrementálisan backupolnak, így nem foglal annyi helyet. -
martonx
veterán
Mondok egy nem is annyira extrém példát:
Amikor kézzel mókolsz a DB-ben, és te magad hibázol. Vagy ami még rosszabb, kiderül, hogy volt egy programhiba, ami elrontotta az adatokat.
Nem igazán értem, miért neked magadnak kell a backuppal bajlódnod. Jó mondjuk 8 éve csak felhőben dolgozok... -
martonx
veterán
válasz
nyugis21
#5372
üzenetére
Az 1-es sémára szavazok. Viszont tényleg van ezt értelme ennyire mikroszkopikus felbontásban, ultra részletesen adatbázisban ábrázolni?
Feladat és eseményenként? Ennyi erővel akkor már az is feladat és persze esemény lehetne, hogy a találkozóra menet kimész az utcára, felülsz a villamosra, veszel egy menetjegyet stb...Szóval szerintem továbbra is túlbonyolítod.
-
martonx
veterán
válasz
nyugis21
#5361
üzenetére
Kérlek nézd el nekem, hogy utoljára valamikor 2010 táján Access-eztem, és nem is hiányzik.
A gépemen is csak azért van, mert múltkor a kedvedért feltelepítettem, hogy bebizonyítsam hogy lehet Accessben egy táblát önmagához kötni."Ezért kérdeztem, hogy adatbevitelt hogyan oldod meg ott?
Nem értem, ha egyszer egy táblában egy rekordot kezdek bevinni, hogyan tudok ugyan abba a táblába egy vagy több újabb rekordot úgy beszúrni, hogy még nem zárom le a rekordot, ráadásul rögtön kapcsolat lesz az újonnan bevitt rekordokkal?"Fingom sincs (régen is VBA-t programoztam Access mögött, nem az adatbeviteli formokkal tökölődtem), hogy kell az adatbeviteli formokat összenyomkodni varázslóban.
VISZONT: háttal ülsz a lovon logikailag. Adatbevitelnél lényegtelen a kapcsolat az esemény, és a jövőbeli esemény között, mert nyilván ekkor még nincs is kapcsolat. Felviszed az eseményt, és kész. Ez az esemény lesz a szülő eseményed.
Egy dolgot kell megoldanod, hogy amikor egy újabb eseményt felviszel a formon, akkor ki tudj (de ne legyen muszáj) választani egy szülő eseményt, pl. az előzőleg felvittet. Így tudod logikailag megoldani, hogy a jövőbeli események kapcsolódnak az őket kiváltó eseményhez, azaz a tábla önmagához kapcsolódik.
Fogalmam sincs, ezt hogy kell csinálni a formon, de biztos, hogy elég csak a form varázslójában kattintgatni.Sok sikert, részemről téma lezárva.
-
martonx
veterán
válasz
nyugis21
#5358
üzenetére
Ez egy SQL fórum, nem pedig MS Access fórum. Hogy táblák között milyen kapcsolatok vannak, SQL query-kben mit-hogy érdemes megcsinálni, abban tudunk segíteni, de szerintem itt senki nem használ MS Access-t (többek között ezért is próbáltalak volna lebeszélni róla).
Azaz a formok gyártásában, mi itt nem fogunk tudni segíteni neked.
Ahogy azt is hiába kérdezed meg itt, hogy MS Wordben, hogyan formázzuk hupililára egy bekezdés hátterét, miközben felhőcskés szegélye legyen. A mi szemszögünkből nézve az MS Access form készítés mizériája egy szinten van az MS word-ös példámmal.Remélem így már érthető, hogy miért állt itt meg a segítségünk. Olvass MS Access doksikat, nézz MS Access form gyártó youtube videókat, ha létezik olyan, akkor írj direktben MS Access fórumokra, és biztos meg lesz a kérdésedre a megoldás.
-
martonx
veterán
"Na kipróbáltam, futott az update(-elő szkript) kb. fél percig, addig mint az őrült kattintgattam a weblapon (ezzel select lekérdezéseket generálva), és nem volt megakadás sehol sem."
Erről beszéltem, hogy igen, ezek a problémák, amik itt felvetődnek jogosak, és léteznek, de a te rendszered mire ide elér, hogy DB szinten lock stratégiákon kell gondolkoznod, és erre optimalizálnod lehet, hogy:
1. sose fog megtörténni
2. ha mégis akkor meg te leszel a következő magyar bank / telko ez esetben zokszó nélkül fel fogsz tudni venni egy komplett fejlesztő csapatot Szóval elvileg nem haszontalan ezeken itt pörögni, gyakorlatilag viszont az
-
martonx
veterán
Nem csak Hibernate létezik ORM-ként, és nem csak ORM szinten lehet cachelni
Maximális respect a DB tudásodnak, de nem kell mindig mindent DB szinten megoldani.Ez itt nagyon off topic, de minek görcsöltetitek, és csuklóztatjátok szegény kezdő kollégát (bár szemlátomást, ő magával is ezt teszi
) olyan problémák, olyan technológiai szintű mélységében, amikkel egyrészt jó eséllyel a való életben találkozni se fog (vagy végül elég lesz egy hiányzó indexet feltennie), másrészt, ha nem is DB szinten, hanem kód szinten de, tök simán kezelni lehet. -
martonx
veterán
"Egy index a cikk_id-ra" - itt alapból is kellene indexnek lennie, mivel ez Foreign key. Probléma megoldva
Egyébként meg ez ugyan SQL fórum, de mivel egy web alkalmazásról beszélünk, csomó lehetőséged van tehermentesítened az adatbázist, anélkül, hogy belegörcsölnél az SQL minden mélységébe. Pl. cachelés
-
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.
-
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
-
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. -
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. -
-
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. -
-
-
martonx
veterán
Észrevételeim:
1. Select *-ot el kellene felejteni, és ki kellene írni azokat mezőket amiket ki szeretnél listázni.
2. Group By-nál szépen leírja, hogy mi a baja: bele kell venni a többi listázandó mezőt is (érdemes utána járnod, hogy mi is az a group by, mysql, mariadb specialitás, hogy a példádban szereplő szintaktikailag helytelen group by egyáltalán futni tud bizonyos helyezetekben).
3. Önszopatás a táblák mezőit a táblanévvel kezdődően elnevezni. Ha van egy táblád, aminek categories a neve, akkor annak id, és name mezői legyenek, ne pedig category_id, category_name.
4. Nekem ez 4 ms alatt lefut, bár nyilván több szemszögből sem lehet összehasonlítani a te adataiddal (eltérő adat mennyiség, és MySql vs MariaDB, localhostos erős géped, vs. valami ingyenes osztott hosting a dbfiddle alatt).
SELECT DISTINCT *
FROM items AS i
JOIN items_categories AS ic
ON i.item_id = ic.item_id
JOIN categories AS c
ON c.category_id = ic.category_id
AND c.category_id NOT IN (1,3,13,7,20)
WHERE i.item_id NOT IN (117,132,145,209,211)
ORDER BY i.item_date DESC5. Az Item nevű tábláktól idegrángást kapok. Légyszi nevezzük már el normálisan a táblákat. Jó, hogy nem fiszfasz, meg izé nevű tábláid vannak fiszfasz_izé nevű kapcsolótáblákkal. Aztán amikor 2 év múlva ránézel, te se fogod érteni, hogy mit is akartál az egyes táblákkal leképezni.
-
martonx
veterán
"És ha jól értem, ugye azt írod, hogy csináljak egy product_category táblát, amibe úgy kerülnének bele a rekordok, hogy ha a fő táblámban (product) mondjuk van 2 millió rekord, és mindegyikhez tartozik 2-4 (átlagban 3) kategória (category). Akkor e szerint a product_category táblában jelen állás szerint 6 millió rekord lenne."
Ez azért tud gyors lenni, mert ezek mind Foreign Key-ek, azaz indexeltek. Itt tenném még hozzá, hogy sokkal tisztább érzés lenne Kategória ID-re szűrni Name helyett.
-
martonx
veterán
Én mint C# fejlesztő, aki mellette sokat SQL-ezett is régen, ezzel nem értek egyet.
Csak szimplán nem kell hülyének lenni, és el kell mélyedni az egyes nyelvekben.
Az SQL totálisan más logikai megközelítést igényel, mint egy normális programnyelv. De mindkettő megérthető, megtanulható.
Több olyan kollégáról is tudok, akiknél nagyon szépen megfér egymás mellett a két világ ismerete, harmonikus használata. -
martonx
veterán
-
martonx
veterán
Full Text search-öt előbb a DB-ben be kell kapcsolni fel kell paraméterezni (az általad linkelt fisfos hosting cégeknél pláne erősen kérdéses, hogy be tudsz-e ilyet kapcsolni). Bevallom én még sose használtam, mert nem kellett. Igaziból, ha nem sok millió, egészen nagy méretű szövegben kell keresned, akkor szerintem a Like is simán megteszi.
Full text search helyett én pl. hehe a Google-t használom a weboldalaimon, amiket a Google egyébként is indexel
Programmable Search Engine | Google Developers
Így nem az én DB-mnek kell belegebednie az oldalon keresések kiszolgálásába, hanem a Gugliénak, ráadásul ingyen. -
martonx
veterán
Ezt fogd fel tanulópénznek, és igen, mindenképp írd át normálisra a táblastruktúrát. Legalább ezzel is tanulsz.
Illetve máskor lehet nem árt kérdezni, mielőtt magadtól kitalálsz valami butaságot, és 6 hónapig rossz irányba mész (jó persze sokszor a kérdezéshez is már kell egy alap tudás...).Egyúttal szólok előre, hogy az ilyen vicc tárhelyeknél, majd még csak ezután fog kezdődni a kálváriád, amikor ki fog derülni, hogy MariaDB-t nem támogatnak
A helyedben egyből a felhőt céloznám meg (ok, ott meg nem évi 10K HUF lesz a hosting, bááár lehet, lusta vagyok utána nézni a DB áraknak). -
martonx
veterán
Előző munkahelyemen a legnagyobb táblában 6 milliárd sor volt, és naponta pár tíz millióval bővült. Ebben csak az volt a pláne, hogy tök sima MSSQL vitte a DB-t egy 32 magos 256Gigabyte memóriás szerveren AWS-ben.
Mondjuk nyilván még ez se volt semmi a telkok DB-ihez képest. -
martonx
veterán
PostgreSQL is the DBMS of the Year 2020 (db-engines.com) érdekességképpen
-
martonx
veterán
Bocs, pontatlan voltam. Az SQL-t nem számítom a programnyelvek közé. De igazad van végülis ez is programnyelv, csak épp nem imperatív. Ugyanígy nem tekintem programnyelvnek a CSS-t sem
Legalábbis a magam pongyola megfogalmazásában.A Java lambdát ne keverd ide, az csak egy syntetic sugar, nem attól lesz deklaratív nyelv a Java. De kezdünk nagyon eltérni az eredeti problémától
-
martonx
veterán
"Ettől még fenntartom azt, hogy Javaban egyszerűbb lenne lekódolni+gyorsabban is futna."
Mármint bármilyen programnyelven (javascript, php, c#, python, java, stb...) és nem csak egyszerűbb lenne lekódolni, és nem csak gyorsabban is futna, de könnyedén debuggolható, logolható, verzió kezelhető is lenne.
Noha mindezt SQL-el is meg lehet oldani, de elképesztően nyögve nyelősen.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Na jó, megértem, hogy a motor szerelés izgibb...
Új hozzászólás Aktív témák
- Ingatlanos topic!
- Vezeték nélküli fülhallgatók
- World of Tanks - MMO
- Bemutatkozott a Poco F2 Pro (már megint)
- A nagy Szóda, Szódakészítés topic - legyen egy kis fröccs is! :-)
- AMD Navi Radeon™ RX 7xxx sorozat
- HiFi műszaki szemmel - sztereó hangrendszerek
- EAFC 26
- Vivo X200 Pro - a kétszázát!
- Battlefield 6
- További aktív témák...
- magyar billentyűzet - 136 - Lenovo Legion Pro 7 (16IRX9H) - i9-14900HX, RTX 4080 - 4 ÉV GARANCIA!
- Creative Sound BlasterX G6 7.1 USB külső hangkártya
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- AKCIÓ! Apple Studio Display 27 5K Nanotexturált üveg monitor garanciával hibátlan működéssel
- Azonnali készpénzes INTEL CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest