- iPhone topik
- Hivatalos a OnePlus 13 startdátuma
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Android szakmai topik
- Milyen okostelefont vegyek?
- Apple Watch
- A hagyományos (nem okos-) telefonok jelene és jövője
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
Új hozzászólás Aktív témák
-
disy68
aktív tag
válasz
#68216320
#11642
üzenetére
CodeSource codeSource = YourMainClass.class.getProtectionDomain().getCodeSource();File jarFile = new File(codeSource.getLocation().toURI().getPath());String jarDir = jarFile.getParentFile().getPath();A fentivel megvan a jar path-ja, hozzácsapod az elvárt fájlnevet és azt próbálod beolvasni, ha nincs ilyen fájl, akkor mehet fallback-nek a resource beolvasás. Esetleg a jar mappájában keresel bármilyen .properties fájlt és mindegyiket beolvasod, de ez már részletkérdés.
-
#68216320
törölt tag
válasz
#68216320
#11485
üzenetére
Nem tudom mennyire sikerült leírnom a feladatot. A lényeg, hogy idegen szerveren futtatva a programomat védeni kellene bizonyos adatokat, amik ott helyben vannak tárolva. Konfig adatok esetén fájlban vannak ezek, egyéb adatok esetén mondjuk sql-ben.
Ha valaki ránéz a szerveren ezekre az adatokra akkor simán kiolvasva őket használhatatlanok legyenek csak a program futása közben tudja használni ezeket. Vagyis valami kulccsal titkosítani kellene. De hogy hol lenne mondjuk tárolva ez a kulcs, na azt nem tudom. Tehát valami elvi megoldás kellene, hogy hogyan lehetne ezt felépíteni.Van olyan kulcs amit az adott szerver tulajdonosa (cég) ismer és azt használná a program titkosításra. (ez a jelen feladat)
És lenne olyan is, amit csak én ismerek és az valahogy fixen a programban lenne, azzal tudná a program az általam biztosított adatokat írni/olvasni. (ez egy következő feladat)
-
válasz
#68216320
#10800
üzenetére
Az exe futtatása megoldható a
Runtime.getRuntime().exec(...)hívással. Visszakapsz egy processz-t, aminek a lefutásátwaitFor()-ral megvárod. Itt van rá egy kis példa program, ami már demonstrálja azt is, hogy hogyan lehet az exe outputját (stdout) megszerezni. (Alternatíva, hogy az exe egy fájlba írja az outputját, amit futás után normál módon fájlként felolvasol.)A parsolásra régebben még azt mondtam volna, hogy kell írni egy parsert, de manapság ez nem divat... Ha tényleg ennyire rögzített a szerkezet, akkor a sorban szereplő négy komponens (csoport, adatnév, értéknév, érték) előbányászható egy reguláris kifejezéssel is, pl. ezzel:
^([^.]+)\.([^.]+)\.([^.]+): *(.*?) *$Az outputot soronként célszerű feldolgozni, az elején vagy ki kell hagyni fix számú sort, vagy egyszerűen ki kell hagyni azokat, amire nem illeszkedik a regex:
Pattern pattern = Pattern.compile(<a fenti regex>);
while (<van sor>) {
Matcher m = pattern.matcher(<a sor tartalma>);
if (m.find()) {
String sensorGroup = m.group(1);
// ...
String sensorValue = m.group(4);
// DB mentés
}
}Alternatív szervezés: linux-ban oldod meg, amit lehet. A java program nem hajt végre exec-et, helyette a standard input-ot olvassa, és dolgozza fel. Hívni meg valahogy így:
>sensor.exe <opciók> | java -jar sensorprocessor.jarÉs az egészet lehet futtatni pl. cron-ból. (Hátránya, hogy a JVM indítás kissé erőforrásigényes, 30 másodpercenként meg pláne.)
Megjegyzések: (1) fejből írtam, a kódot tekintsük pszeudokódnak, (2) a regex pattern-ben a
\-eket duplikálni kell a Java string konstansban.Szerk: A korábbi válaszokat nem láttam, pár dolog így ismétlés, bocs.
-
bambano
titán
válasz
#68216320
#10806
üzenetére
"Egyrészt szeretném a beérkezett értékeket validálni mielőtt tárolom.": egyrészt lehet shellben, awk-ban, bármiben validálni. de validálhatod az adatbázisban is. már ha a mysql alkalmas erre, sose próbáltam. postgresql alkalmas.
"esetleg tényleg a megoldás az lenne, hogy egy API-t csinálni java-ban, amit a kliensek hivogatnak és a már parse-olt adatokat azon keresztül tolnák befelé.": van ilyen api, a mysql hálózati apija, minek akarnál még egy újabb apit kitalálni?lyalyly curl... most eltekintve attól, hogy tök értelmetlen http-n csinálni ilyet, a curl-ben túl sok hiba van ahhoz, hogy komoly rendszeren használd.
ha mindenáron kell a wines kliens, akkor winre van sed, bash, mysql kliens, és ugyanaz, mint linuxon. hogy powershellben mekkora meló leprogramozni, nem tudom. de mivel úgysem tudod ugyanazt a szenzorprogramot futtatni, ezért a rendszer mindenképpen különbözni fog.de ha már itt tartunk: miért nem rakod bele a mysql klienst a szenzorokat kezelő programba?
persze elfelejtettem az alapvető kérdést feltenni: dolgozni akarsz vagy megoldani a problémát?
-
floatr
veterán
válasz
#68216320
#10806
üzenetére
Ez a formátum YAML-ként is értelmezhető, így egy YAML parser be tudja olvasni, és akkor nem egy igénytelenül gányolt shell-ninja szutyokkal oldod meg, amit 1 év múlva a saját szerzője sem tud már támogatni.
De van rá lényegében kész megoldás is: ELK stack. Azt pont ilyenekre találták ki. Logstash illesztőkön keresztül Elastic-ba tolja a szenzorok adatait, amit később Kibanával meg tudsz jeleníteni. Ezt a shelles babrálást meg felejtsd el
-
bambano
titán
válasz
#68216320
#10804
üzenetére
a véleményedtől függetlenül súlyos hiba java vm-et meg java-s programot indítani ott, ahol egy sed vagy awk program tökéletesen elegendő. attól, hogy van java a gépeden, még nem kell minden esetben használni.
a mysql-nek van parancssori kliense, az tökéletes arra, hogy betöltsd az adatokat az adatbázisba."jó lenne java exec megoldással a kimenetet elkapni és parse-olni.": azt sem értem, ehhez minek java exec. feltalálták a csővezetéket, tessék szabvány bemenetet olvasni és parsolni, ha mindenáron java-ban akarod.
bocs, de úgy gondoltam, hogy nem központi probléma megoldani, hogy egy linuxon futó program kimenete hogy kerül egy windowson futó programba. te írtad, hogy linuxon futó program szenzor adatokat gyűjt. miért akarnák windowson adatbázisba rakni?
hagyd a fenébe a java-t, shell szkript topicban vagy linux kezdő topicban megmondják a jó megoldást. szenzor program kiolvassa a mért értékeket, kiküldi szabvány kimenetre, azt sed-del, awk-val vagy shell szkripttel átalakítod szabvány sql insert utasítássá, azt bele küldöd a mysql kliensbe és kész. ennyi. nem java, meg legyen kéznél jdbc driver, meg vm meg a fene se tudja még mi minden függőség.
-
Drizzt
nagyúr
válasz
#68216320
#10800
üzenetére
A Linuxos program időzített futtatására használj cront, vagy egyszerűen írj egy bash scriptet, ami tight loopban vár. A kimenetet meg simán irányítsd bele egy fájlba. A Java programban ugyanezt a fájlt nyisd meg ugyanilyen időközönként. Aztán dolgozd fel, s írd ki adatbázisba. Amúgy ahogy az adatod jellegét nézem, kb. egy time series database-ben lenne a legjobb őket tárolni. Erre jó pl. Influxdb. Aztán csinálhatsz rá mindenféle fancy ábrát Grafanával.
Parse-olni ezt egyébként elég egyszerű, soronként végigolvasod, majd line.split("."), a három elemű tömböt meg felhasználod ahogy akarod..
Más: Mi a legjobb, legmélyebb Spring video course amivel találkoztatok? Kéne nekem egy masszívabb. Ha csak fizetős van, az se gond. De örülnék, ha legalább 20 óra körüli lenne és nagyon a részletekbe menő.
-
axioma
veterán
válasz
#68216320
#10731
üzenetére
Biztos kozos ososztaly kell neked, nem lenne jobb a kozos interface? Mar persze ha arrol van szo hogy azert szeretned oket valahogy kozositeni, mert kesobb egyforman kezelned a kettot (az egyforma tulajdonsagokkal). Ha most sehol nem kezeled egyutt, akkor meg siman ket osztaly, az nem akadalyozza hogy kesobb kozos interface is legyen, ha valos indok lesz ra.
-
Szmeby
tag
válasz
#68216320
#10728
üzenetére
Csak annyit tudok a prjektedről, amennyit most leírtál róla, így lehet, hogy valamit félreértek.
1. Én most microservice bűvkörökben élek és a selfcontained alkalmazás a kedvenc, vagyis semmit sem vágok, cserébe viszont pici a cucc, és nincs benne ui. Természetesen a komponensek közti kommunikációt megvalósító DTO-kat, külön, közös projektbe teszem, hogy mindegyik komponens ugyanazt lássa.
Ha látod értelmét a vágásnak (mert mondjuk több egymástól eltérő modul is használná), akkor vágj. Ha nincs értelme, akkor ne vágj. A legrosszabb, amit tehetsz, hogy túl korán vágsz és később szívsz, hogy hát lehet, nem is ott kellett volna, ajaj.
A több UI, több modul felállás szimpi.2. A tesztet. Nincs hibátlan osztály. A tesztet. Leginkább párhuzamosan. TDD. Mondtam már, hogy a tesztet?
Amúgy meg a te dolgod, ahogy jobban esik. Főleg, ha a teszttel kezded.3. Ha valami nem komplex, én nem frameworközök, mert csak megköti a kezet, lassít, bonyolít. Amúgy passzolom a kérdést, nem tartom magam frontend gurunak. Persze lehet az, hogy mondjuk valaki csak az angulart ismeri és semmi mást, neki érezhetően könnyebb dolga lesz abban megcsinálni, mint szenvedni egy fura jsp-vel.
4. Ne származz le.
Oké, hogy a nyelv megengedi, de attól még nem jó.
Én nem osztom azt a nézetet, hogy ami úgy néz ki mint egy kacsa és olyan hangot ad ki, mint egy kacsa, az egy kacsa. [link]
Az egy másik osztály.
Ha mégis van némi közük egymáshoz, akkor még a composition-t tudom elképzelni, vagyis az osztály egy tagja lesz a meglévő cucc, és az osztályod csak az értelmes mezőket engedi ki az apiján. -
#68216320
törölt tag
válasz
#68216320
#10728
üzenetére
4. Ha van egy már meglévő model amiből leszármaznék, mert mert az új model tartalmaz még pár tulajdonságot, de van olyan is amit a parent igen, de a child nem, akkor azt hogyan szokás megoldani? Obj esetén mondjuk lehet NULL, de például int vagy boolean esetében mit csinálok vele? Ha adok értéket akkor azt hihetem, hogy az valós.
-
Szmeby
tag
válasz
#68216320
#10704
üzenetére
Egy adott fajta kód vagy stílus azok számára nehezen olvasható, akik nem szoktak hozzá. Kezdőként én is nehezen dekódoltam, hogy mi van. Aztán megszoktam és már nem nehéz.
A fenti kód nyúlfarknyi. Ebbe belemagyrázni azt, hogy ez azért nem jó, mert lehet nem nyúlfarknyit is írni, hát, jó, de a fenti kód továbbra is nyúlfarknyi marad, minden más csak a kivetített félelmeid. Vagy valaki más félelmei, nem célom személyeskedni.
A lambda nem egy kalapács, hogy mindenre IS használható, ahogy egyébként semmi sem az, nincs ultimate weapon minden problémára. Természetes, hogy a 200 soros förmedvényt nem egy lambda blokkban kódolja le az ember, hanem elgondolkozik, hogy miért lett ez 200 sor, aztán egyszerűsít, absztrahál, és kitalál egy a probléma megoldására optimálisnak tűnő módszert, stílust, eszközt, stb. Ami nem KELL, hogy egyáltalán tartalmazzon lambdát végül.A lambda (meg lényegében a stream api) azért jó, mert egységet képez, egy komplexebb folyamatot is atomi egységbe zár, nincs mellékhatása, ergo "bugmentes". Ha matekosabb beállítottságúnak érzed magad, olvass kicsit a monad-ról. Ha kevésbé matekosnak, akkor inkább ne, nehogy eret vágj magadon.
Nyilván ezt is el lehet cseszni, ha mondjuk egy a lambdán kívül létrehozott listát piszkálunk a lambda belsejében, annak már lesz mellékhatása, de az nem is a lambda hibája.Én személy szerint azért nem szeretem a stream apit, mert lassú. Egy forEach lassabb egy for ciklusnál, és ez engem időnként zavar.
Nehéz debugolni? A régi eclipse valóban elég körülményesen működött, a closure környezetének csak egy részét látta. Hogy most jól működik-e, nem tudom. Mint mondtam, nem illik 200 soros lambda törzseket produkálni, és akkor nem kell debugolni sem. Problem solved. Érthető, hogy a határidő szűkössége miatt folyamatosan megy a
gányolás... khm... képződik tech dept, de akkor is a fejlesztő felelőssége marad, hogy jól olvasható kódot produkáljon a végén. Ha valaki elég igénytelen arra, hogy egy egyszerű lambda kifejezést túlbonyolítva ott hagy, refakt nélkül, oké, de nem az eszközt kellene ilyenkor hibáztatni az olvashatatlan és debugolhatatlan kód miatt. Gondolom.
Egyébként meg a 200 soros blokk metódusba szervezésével és egy jól irányzott method ref beillesztésével máris nagyot léptünk előre a tisztánlátás útján. Az már más kérdés, hogy sok esetben ez csak a probléma elfedésére jó és nélkülözi az igazi optimalizálást.Az olvashatóságot egyébként tengernyi más dolog is befolyásolja, csak hogy a legkézenfekvőbbet említsem, a nevek. Ha semmitmondó változó és metódus neveket használ a fejlesztő, akkor az olvasó arra kényszerül, hogy belenézzen a metódusba. Ha kifejező neveket használ, akkor erre nincs szükség. Innentől kezdve meg már teljesen mindegy, hogy igazi metódusokat, vagy névtelen metódusokat használunk a megoldásban. De akkor sem illik túlbonyolítani egy lambda kifejezést.
--------
@floatr: Sajnos nem értem a kérdést, kifejtenéd? A reduce egy darab string optional-t ad vissza, azon nem tudok már sokmindent gyűjtögetni. -
Lortech
addikt
válasz
#68216320
#10704
üzenetére
A best practice az olvasható kód.
Ez persze bizonyos mértékig szubjektív.
Az olvashatóság lambda esetében még inkább az, erősen függ attól, hogy ki az olvasó. Ki mihez van szokva, kinek már állt rá jobban az agya. Már csak azért is, mert a lambda nem volt mindig alap nyelvi elem, és máig rengeteg kódbázis van, ami nem ilyen szemléletben íródott. Ha a csapat, aki a kódot írja és karbantartja, lambdát preferálja, akkor menjen a lambda, de azért ne ész nélkül.
Az adott problémától függ, hogy lambdával olvashatóbb lesz-e a kód, esetleg hatékonyabb vagy elegánsabb. -
axioma
veterán
válasz
#68216320
#10704
üzenetére
Engem meg code review-n (prod.code) direkt felszolitottak, hogy lambda-sitsak. Szerintem attol fugg, hogy hol mi a szokas, en egyebkent nem tartom olvashatatlanabbnak (csak az adott esetben kovettem a korabbi kodstilust). Szerintem nem art megszokni, peldaul a sonarlint ezt nem veszi elagazasnak es extra bonyolitaspontnak ha jol remlik
-
Lortech
addikt
válasz
#68216320
#10668
üzenetére
Jonak nez ki.
Annyi megjegyzes, hogy ImageIO es a beepitett javas kepfeldolgozo megoldasok nagyon eroforraspazarloak mind memoria, mind cpu szempontjabol, es a vegeredmeny minosege sem feltetlenul a legjobb, szoval ha komoly megoldas kell, akkor erdemes ezeket kikerulni es valami nativ celeszkozt hasznalni (Pl convert (imagemagick) parancs linuxon), majd a vegeredmenyt direktben kiirni az outputstreamre. -
Lortech
addikt
válasz
#68216320
#10663
üzenetére
Kissé összemosódik a kép "nevének" (fájlnév / uri ? ) és magának a képnek a dinamikussága.
Nem világos az sem, hogy jön ide a header. Mindegy, kezdjük el és hátha kiderül, mire gondoltál./kepstream-re mappelsz egy servletet web.xml-ben vagy annotációval, request.getPathInfo-ból kiparse-olod a /kepstream utáni részt, megvan a path paramétered, amivel a képet azonosítod szerver oldalon.
Aztán a httpservletresponse outputstreamedre azt írsz dinamikusan, amit csak akarsz, akár on-the-fly generált képet, akár fájlból beolvasottat.
Plusz content-disposition, content-type headert nem árt kitölteni a céljaidnak megfelelően. -
disy68
aktív tag
válasz
#68216320
#10510
üzenetére
Szerintem érdemes ismerni mindkettőt, de a maven-t mindenképp. Kezdőként elég az egyik is. A Gradle rugalmasabb, a néhanapján felmerülő cache problémákat szopás kiszűrni. A maven kevésbé rugalmas - pluginekkel persze lehet bármit - de régi motoros, szerintem minden problémára van megoldás (plugin) hozzá. Gradle esetében találkoztam olyannal, ami nincs vagy csak részben volt meg a maven-es megoldáshoz képest.
-
Drizzt
nagyúr
válasz
#68216320
#10493
üzenetére
Szerintem a legérdemesebb beszerezni valamelyik beginner Udemys Spring traininget. Általában nagyon szájbarágósak és a végletekig praktikusak. Ha szerencséd van, olyan helyed dolgozol, hogy van ingyen access. Ha nem, akkor érdemes kinézni valamelyik akciósat és rákölteni vagy 10-20 eurót. Szerintem ezerszer könnyebb megérteni egy ilyenből, mint könyvekből, vagy írott tutorialokból.
-
disy68
aktív tag
válasz
#68216320
#10486
üzenetére
DTO: data transfer object
ez lehet bármilyen két komponens közötti kommunikációban szereplőDAO: data access object
ez egy olyan objektum, amin keresztül adatokat érünk el/tudunk manipulálni, általában adatbázissal a túloldalon - az objektum elrejti a DB részleteketrepository:
a DAO-hoz hasonló pattern, inkább domain centrikusabb, az adat objektumokat entity-nek hívjuk ebben az esetben
A rétegek szervezése/szeparálása fontos dolog, nehéz elsőre ráérezni, fog kelleni hozzá némi tapasztalat. Annyit szerintem mindenképp jegyezz meg most, hogy nincs semmi kőbe vésve. Vannak ajánlások, de mindig az adott problémához keressük a megoldást, nem pedig valami "best practice-t" erőszakolunk rá mindenre.Amennyiben egy egyszerű crud a cél, akkor nem is feltétlen szükséges külön entity/dto/pojo-kat készíteni a különböző rétegekhez, mert fölöslegesen kéne transzformálgatni mindent többször is.
Ha a crud-nál tovább lépünk vagy más jellegű a probléma, akkor hasznos lehet különválasztani a rétegeket jobban.Amúgy olvass még kicsit utána funkcionális programozásnak, immutability-nek - java 8 óta java-ban is van hozzá támogatás - szerintem árnyalja majd a képet.
A Spring JavaEE vs sima java témakörben pedig én javaslom a keretrendszer használatát, ha máshoz nem is, de a dependency injection miatt mindenképpen.
-
#68216320
törölt tag
válasz
#68216320
#10485
üzenetére
Megkeveredtem a DAO és DTO fogalmak között.
Tehát valami ilyesmi lenne?
View <- (Model) -> Service <- (DTO) -> PersistenceAzaz arra irányulna az újabb kérdésem, hogy a DTO, amit mondjuk megkapok adatbázisból és van benne ID, nem juthat el a view rétegbe igaz? Hanem a kontroller mintegy mapper-ként új objektumot (POJO) hoz létre, de szintén a DTO-ból kapott ID-t használva és azt adja a View-nak?
-
válasz
#68216320
#10483
üzenetére
Én amikor Springben csinálok egy API-t a következőket követem, a Controller kap egy kvázi DTO-t (sima POJO ami semmire nem jó csak adatokat szállítani) amit validálok majd adott esetben elmenetem tehát model készül belőle.
Amúgy meg modelekkel dolgozom repository-n keresztül.
Ahogy a kolléga is írta feljebb.
mobal,
-
floatr
veterán
válasz
#68216320
#10480
üzenetére
A népszerűbb keretrendszerek azt a felállást támogatják, hogy Model + Repository/Dao + Service. Az ID kezelését egy alp perzisztencia motor is megoldja, és a Repository/Dao dolga a Model és adatbázis közti kapcsolat funkcionalitásának megteremtése.
Ezzel szemben van a domain driven design, ami az adatokat hordozó objektumnak adja a funkcionális részt is. -
Drizzt
nagyúr
válasz
#68216320
#10428
üzenetére
Ha külön vannak, akkor mindenképpen nyered:
- Az egyes komponensek fordítása jóval gyorsabb lesz.
- Kisebbek, célszerűen jobban értelmezhetők lesznek a komponensek.
Hátrány:
- A verziószámokkal komoly kavarodást lehet összehozni. Bár ha követi az ember a semver szabályait, akkor igazából nem kéne, de én azt tapasztalom, hogy mégis nagyon nehéz eldönteniük embereknek, hogy mikor melyik verziószámot kellene léptetniük.Extrémebb eset, ha kiszervezed teljesen független alkalmazásokba a modulokat, amik különféle API-kal kommunikálnak. Előny:
- Lehet skálázni csak azt a komponenst, amit kell.
- Lehet heterogén az architektúra.
Hátrány:
- Amint valami kimegy a hálózatra, fel kell arra készülni, hogy a kommunikációval bajok lesznek. Timeout-ok, elveszett üzenetek, duplikált üzenetek.Még lehet message bus architektúrát is alkalmazni. Ez olyan, mint az utóbbi, de az üzenetek tárolása, küldése, etc. nem a saját alkalmazásod feladata, hanem egy message bus-é. Mint pl.: a Kafka, vagy JMS.
-
-
válasz
#68216320
#10411
üzenetére
Alapvető fogalmakkal kell tisztáznod először és utána szerintem mehetne a Spring.
Amire szükséged lesz (így hirtelen fejből, nem teljes lista):
- Singleton
- MVC
- Repository
- DI
- Annotációk
- Hibernate (ORM)
- SQL
- ... és még sok dologEgy kiindulási alap: [link], továbbá célszerű Gradle vagy Maven tool-al is megismerkedned (én személy szerint a Gradle-t ajánlom).
-
Drizzt
nagyúr
válasz
#68216320
#10411
üzenetére
Szerintem határozottan nem érdemes nulláról SE-vel elkezdeni megírni. Hiszen éppen ez lenne a Spring, meg az EE lényege: ne kelljen feltalálni a spanyolviaszt, s lehessen a business logic-ra fókuszálni.
Szerintem érdemes mindkettőhöz amúgy valamilyen maven archetype-ból kiindulni. Vannak pl.: egyszerű REST + EJB + JPA skeletonok, azokat már elég jól testre lehet szabni és kibővíteni, mégis faék egyszerűek.
-
#68216320
törölt tag
válasz
#68216320
#10406
üzenetére
Közben az merült fel bennem, hogy a Spring megértéséhez közelebb vinne-e az a módszer, ha ugyanazt a project-et először sima JavaSE-vel oldanám meg. Jdbc, Servlet, stb.
Ezután teljesen ugyanazt csinálnám meg Spring-el (esetleg jóval későbben JavaEE-vel talán)
Így talán az elméleti és megvalósítási különbségek egyértelműbbek lennének.Főleg mondom ezt az alapján, hogy 2 év kihagyás után az akkori friss Java tudásomból mostanra megkophattak jelenleg még előre nem látható részek.
Vagy ne törődjek vele és ugorjak neki csak a Spring-nek? -
#68216320
törölt tag
-
Szmeby
tag
válasz
#68216320
#10220
üzenetére
Nem igazán így néz ki. A sequence csak egy futósorszám. Tehát tényleg csak egy szám van benne... az éppen aktuális érték. Ha elkéred tőle az értéket, automatikusan növeli magát eggyel (vagy neked kell növelned kézzel... kinézem ezt a mysql-ből). Ha mindenképpen táblaként akarod elképzelni, akkor van egy oszlopa, neve mondjuk legyen value, és van egy sora, abban az érték pedig 6, mert mondjuk a 6 volt az utoljára kiosztott id.
Lásd az oldal alján.Szóval találkoztam már pár helyen ilyen megoldással... bár az oracle volt, nem mysql, de a concept ugyanaz, globálisan egyedi id. Nyilván nem kötelező minden táblán ezt használni, táblák egy csoportján is lehet, meg létrehozhatsz több sequence-t, más-más csoportoknak... ahogy a domain megköveteli.
Bár a hozzászólások alapján úgy látom, ebből 1 fő tábla lesz.
-
bambano
titán
válasz
#68216320
#10229
üzenetére
"Nem is várható bővülés": híres utolsó mondatok
a lekérdezés sebessége egyrészt nem számít akkor, amikor elméletben vizsgálsz egy logikai struktúra->tárolási struktúra leképezést, másrészt nem is tudhatod előre, mi a gyorsabb, harmadrészt oldja meg a hardver
szerintem a kód mindenféle részén folyton azt mókolni, hogy most melyik táblát kell joinolni, hova mit írsz, az nagyobb teher, mint berakni egy táblába, indexelni, a többit oldja meg az adatbáziskezelő meg a beszerzési osztály rambevásárló felelőse.
-
Drizzt
nagyúr
válasz
#68216320
#10229
üzenetére
Még egy aspektust akarok felvetni. Milyen táblákhoz kapcsolódik a termék még? Ha van olyan, ami termék ID-t használ, akkor innentől kezdve abban a táblában ha akarsz foreign key-t használni, akkor kénytelen leszel 3 különféle oszlopot felvenni. (Utóbbit mondjuk úgy is ki lehet küszöbölni, ha minden 1:1, 1:n kapcsolatot is kapcsolótáblával valósítasz meg, mintha n:n lenne, mert ilyenkor a foreign key a kapcsolótáblába kerül át.)
Másik dolog amit fontolj meg, hogy érdemes lehet Flywayt, vagy Liquibase-et használni, ami jelentősen meg tudja könnyíteni az életed, ha később mégis kell változtatni az adattáblák struktúráján, s ilyenkor a meglevő rendszerek update-elése automata kell, hogy legyen.
-
bambano
titán
válasz
#68216320
#10217
üzenetére
szerintem meg egy táblát kell csinálni a terméknek, azon mezőkkel, amelyek biztosan mindegyik terméknél előfordulhatnak, meg egy táblát a változó tulajdonságoknak, és abba belerakni az adott termék tulajdonságait. esetleg egy harmadikat tulajdonságtípusnak.
A harmadikba beleraknád, hogy milyen tulajdonságok fordulnak elő (pl. kijelzőméret, hdmi száma), a másodikba meg hogy termek_id,tulajdonsag_id, ertek.
-
RexpecT
addikt
-
Szmeby
tag
válasz
#68216320
#10217
üzenetére
"Viszont ekkor az autoincrement id a mysql-ben csak egy táblára lesz érvényes, azaz lenne 1-es id-val tv és mosógép is."
Nem kötelező a táblákra bízni az id generálást, autoincrement használata helyett csinálhatsz az adatbázisban egy sequence-et (vagy sequence table-t? nem tudom, mysqlnél milyen eszközök állnak rendelkezésre), és az entitásaid abból szedhetik majd a next id-t.
-
Drizzt
nagyúr
válasz
#68216320
#10217
üzenetére
Teljesen nem olvastam vegig az alabbi linket, de szerintem minden kerdesedre valaszt kapsz belole. A valasz: attol fugg. 3 fo megoldas van: egy tabla az osszes termektipussal. Ezzel lehet a leggyorsabban lekerdezni termektipusokat ativelo modon, de constrainteket not null constrainteket nem tudsz megadni, ha az altipusok egy reszenel kellene, de legalabb egy altipusnal nem. Aztan lehet mindegyik tioust sajat tablaba rakni. Ekkor az osszes tipus lekerdezesehez tobb tablat kell lekerdezni. Aztan van a kozos tabla a kozos mezoknek, majd egyedi altipus mezoknek kulon tablak, amik visszareferalnak a kozos tulajdonsagokat tartalmazo tablara. Itt joinnal lehet lekerdezni az osszes altipus osszes elemet egyszerre. [link]
-
Taoharcos
aktív tag
válasz
#68216320
#9191
üzenetére
A swing is elvesztegetett idő, egy munkaadó se kiváncsi erre. Inkább valami mást tanulj, Vaadinon kivűl még ott van a GWT, Struts, de a JSF vagy JSP is hasznosabb, vagy JPA, Hibernate, Eclipselink, Spring, Junit, Mockolás, TDD, SQL stb.
Ha már könyvből tanulsz "az agyhullám java" sokkal hasznosabb, aktuálisabb és érthetőbb. Ráadásul a Youtube-on sok jó java oktató videó van, angolul rengeteg, de még magyarul is sok. -
-
disy68
aktív tag
válasz
#68216320
#9141
üzenetére
Helló, jó kis probléma
Hirtelen olyat találtam, hogy:
import java.io.PrintStream;
import java.io.UnsupportedEncodingException;
import java.util.Scanner;
public class Main {
private static final String UTF_8 = "UTF-8";
private static final String INPUT_MESSAGE = "Írj be egy betűt: ";
public static void main(String[] args) throws UnsupportedEncodingException {
try (Scanner scanerObj = new Scanner(System.in, UTF_8);
PrintStream out = new PrintStream(System.out, true, UTF_8)) {
while (true) {
out.print(INPUT_MESSAGE);
out.println(String.format("key: '%s'", scanerObj.next().charAt(0)));
}
}
}
}Ezzel helyesen kezeli a scanner által utf-8-nak beolvasott betűket, viszont az INPUT_MESSAGE-et nem. Amit találtam még, hogy indítani a -Dfile.encoding=IBM437 (nálam ez az alapértelmezett kódlap chcp parancs megmondja) paraméterrel, bár ezzel nem kísérletezgettem szóval nem tudom működne-e helyesen.
-
#9138
Aethelstone
addikt
#68216320
#9137
Aethelstone
addikt
válasz
#68216320
#9137
üzenetére
Dobj már ide valami kódot....egyébként meg.....
Amúgy meg a te dolgod, ahogy jobban esik. Főleg, ha a teszttel kezded.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Autós topik
- iPhone topik
- Azonnali fotós kérdések órája
- Hivatalos a OnePlus 13 startdátuma
- Veszprém és környéke adok-veszek-beszélgetek
- Kerékpárosok, bringások ide!
- A fociról könnyedén, egy baráti társaságban
- TV antenna és jelerősítés
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Anime filmek és sorozatok
- További aktív témák...
- Intel X540-T2 dual-port 10GbE RJ45 hálózati vezérlő (10Gbit, 2 port, áfás számla, garancia)
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- Ikea Eilif Paraván - Asztali elválasztó
- Apple iPhone 11 128GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged