Net 6, EF core, kérdés adatkezelési lehetőségekre (milyen fejlettségre számíthatok, hogyan kell esetleg DB-t újraterveznem).

Lenne egy ilyen 3 táblás adatszerkezetem:

table1 ( int table2_id, int table3_id) - kb 850 sor
table2 (int table2_id, int data2) - kb 50 sor
table3 (int table3_id, int data3) - kb 50 sor

Nyers query esetben join query-vel table1-en keresztül behúzom a másik 2-t, gyártok flat adatszerkezetet, és keresek benne pld olyan sorokat, ahol data3==constant, kérem a lehetséges data2-ket.

EF / migrations le tud-e kezelni ilyesmit? Megadok neki osztályokat "table1", "table2", "table3" elemi adatokkal, tud azokból flat adatszerkezet reprezentációt gyártani? Vagy nekem kell olyat gyártanom, és kézileg editálgatnom ezernyi helyen?

Ha a fentivel elboldogul, meddig feszíthetem a húrt a join querykkel? Például table3-on keresztül lenne még egy table4, és table4-en keresztül egy table5, aztán data5 alapján keresném a data2-ket és társai. Számíthatok rá, vagy kicsit túl sokat akarok?

Amit jó lenne tudnom, meddig tartanak az ef kiforrott szolgáltatásai join query környezetben, amire még számíthatok, mert a DB-t természetesen át tudom tervezni, de képben kellene lennem róla, mit tud az ef a jelenben, és azt hogyan tudja? (Jelenleg DB tervezési lépésnél tartok)

Valami blog / video blog / bármi útmutatás jönne jól akár pár szóban. Előre is köszönöm.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Jó lesz, ne aggódj.

Én kérek elnézést!

Oké, értem, csak hát annyi eszem van, mint egy egysejtűnek, és nem sikerül rájönnöm a weben talált temérdek sok 1-1 kapcsolatot bemutató példa alapján, hogyan tudok 1-sok kapcsolatot lelistázni, amikor a másik tábla példányból nem csak 1-nek kell tartoznia az aktuálishoz, hanem egy egész tömbnyinek. Van esetleg kéznél egy olyan példa link is?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Relationships - EF Core
Configuring One To Many Relationships in Entity Framework Core

ha azt a sok táblát hozzá lehet kötni egy táblához, akkor azok valószínűleg egyformák. viszont ha egyforma entitásokat sok táblába pakolsz szét, az felveti a hibás normalizálás lehetőségét.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Jó lesz, köszönöm.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Most nézem, hogy elrontottam a linket, az első ez akart lenni:
Relationships - EF Core

[ Szerkesztve ]

A linket köszönöm. A linkeden van példa kulcs definiálására a táblákhoz. Sajnos csak olyan formán, hogy 1 tábla - 1 kulcs. Nekem kellene van 6-8 index a táblákban adatokat keresni (főleg 2-3 oszlopból gyártott kulcsok). Nosza rákerestem a HasForeignKey()-re, amire a példák mind egy lambdát adtak, hátha tud tömböt. Az msdn doksi meg 2 paramétert ír, nem egyet. Ezekben a lambda dolgokban még kezdő vagyok. Például van egy ilyen:

modelBuilder.Entity<RecordOfSale>()
.HasOne(s => s.Car)
.WithMany(c => c.SaleHistory)
.HasForeignKey(s => new { s.CarState, s.CarLicensePlate });

Mondjuk ott nem indexet gyárt, hanem idegen kulcsot, de végeredményben a kód keresni kezd, a db szerver indexet fog tudni használni, és a lényegi problémámat az megoldja. Csak lehetne neki valahogy még több tagot felsorolni. Vagy chain-be kötni szokás és ráhívni többször?

Aki használja aktívan, egy tippet / példakód linket had kérjek tőle, hogyan szokás megoldani egy táblához több indexet, ami szövegszerkesztésileg még ki is fog nézni valahogy?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Légyszi ne mi guglizzunk már helyetted. Composite key, index, ef core ezek a kulcs szavak.

Én kérek elnézést!

Sziasztok
Kezdő vagyok a programozásban, és most tanulgatom a Swiftet. Azt látom, a programozáshoz kellene valamilyen Apple termék. Ti mit javasolnátok, ami nem túl drága? Úgy tudom, már ipaden is lehet programozni a Playgrounddal.

nincs almás cuccod, se pénzed, akkor miért éppen almás nyelvet erőltetsz?
Olcsóbb, más nyelvet kitűzni célul, mint hirtelen 1 misi környékén bevásárolni almás cuccból.

Én kérek elnézést!

Linuxra tuti van Swift.

while (!sleep) sheep++;

Linuxra van Swift fordító, és jól működik. Jó tudni, hogy egy csomó, leginkább IOS és Mac specifikus api nem elérhető linuxon.

Backend-hez tökéletes a linuxos swift is, bármilyen IOS/MacOS/stb alkalmazás fejlesztéséhez továbbra is szükség van Mac-re.

Legalább egy használt mac mini-t be kellene szerezni. Almáéknál a nyamvadt notarizáció az az átok, ami miatt nem könnyű megkerülni az eredeti hardvert + az apple licenc kifizetését, ha érdemben bármi hasznosat akarsz tanulni.

A magam részéről nem erőltetném pont az almát, ha abszolút kezdő lennék. Vennék valami jelenkori 130-150k huf-os laptopot, és vannak MS cuccok alkalmazás fejlesztési irányban (ahhoz kell "okosban" windows kulcsot vásárolni, de nem drága), vagy van linux üzemeltetési és webezési csapásirányon (az free). Olcsóbban tesztelheted le, tényleg tetszeni fog-e neked az informatika, vagy inkább valami más hobbit választanál.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

A Swift tetszik, próbáltam régebben a Javascriptet, de nem ment. A többi nekem túl bonyolultnak tűnik, a web meg egész kaotikusnak.. Nem hobbiból csinálom, csak olyan szakmát keresek, amivel bárhol tudok pénzt keresni, nem vagyok helyhez kötve..

Ha a javascript "nem ment", akkor lehet elkezdenek problémáid lenni a mai alkalmazásfejlesztési tendenciákkal, amik nem 1 szálon szinkron eseményeket kezelnek, hanem service réteg van a háttérben, és több szál a UI-on.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Azért az utóbbi 1-2 évben hirtelen egészen felfejlődött a webes fejlesztők eszkötára. JS nagyon szépen fejlődik, CSS is egészen használható mostanra.

Én kérek elnézést!

A web azért kaotius, mert a fejlődése sokkal inkább evolúciós, mint tervezett. Valahogy mégis csak úgy alakult a dolog, hogy nagy túlélőnek bizonyult a technológiák versenyében. Ki hitte volna, hogy így alakul (pl. én , aki sokat foglalkoztam az evolúciós pszichológiával is).

[ Szerkesztve ]

Forget your troubles, c'mon get happy

Hát nem tudom, mi javult benne. A böngésző mint platform végül is eléggé kiforrott.
De az egész javascript ökoszisztéma az egy igazi foskazal, nekem lábrángásom van, amikor az a munka, hogy ahhoz hozzányúljak.

Régen a php és a ruby on rails köré gyülekeztek a hülyék a szoftveriparból, azóta a javascript utcahosszal átvette a vezetést.

Hát nem tudom, nekem csak a szívás jut vele.

Az npm és az egész mikro package elképzelés egy határ szar. Az nem normális, hogy egy viszonylag egyszerű szoftvernek 2-300 dependenciája van.
Aztán ha nem megy vele valami, akkor sok sikert. Néha az a hiba, hogy adott package csak globálba telepítve megy. Vagy beszarik a node-gyp. Vagy rossz a node verzió. De türelmesen próbálkozz a 8 magos gépeden, mert ez a szar egy szálon fut.

Aztán ott van, hogy itt mindenki preprocesszort meg fordítót akar írni. Typescriptet fordítunk. CSS-t fordítunk. Template-et fordítunk. Aztán az egészet becsomagoljuk. Sőt jönnek a php-s hülyék és ők sem akarnak kimaradni a jóból, ezért a csomagolóra írnak egy saját csomagolót (laravel mix). És az egészre egy futtatót, mert hát az felháborító lenne, hogy írjunk egy build scriptet, hát nem vagyunk mi állatok. De egy futtató nem elég, legyen több, az "industry standard" az ilyen lefordíthatatlan szójáték. És fontos, hogy az egyik package ezen dependáljon, a másik meg azon.

Na és ez a tooling, berakod a projektbe, hoz mindegyik magával 100 dependenciát meg úgy 300 nyitott bugot. Te futottál már be typescript fordító hibába? Mi igen.

Na és ezekkel fogod és elmerülhetsz a frontend fejlesztés mocsarában. Ahol mindenki annyira okos, hogy saját virtuális dom-ot meg event loop-ot ír, mert hát biztos jobban megoldja javascriptben azt, amit a böngésző fejlesztők C++ban megírtak. Sok sikert ahhoz, hogy találd meg, hol leak-el a memória, mert valahol leak-elni fog.

Bocs a rantért, de szerintem az ipar egyik rákfenéje mostanában pont a javascript ökoszisztéma, annak a minősége, és az a tény, hogy kenyérpirítótól desktop appon át szerverig mindenki mindent ebben a szarban akar lefejleszteni.

[ Szerkesztve ]

Igazabol ez a jo a Java okoszisztemaban. Mindenki utalja egy kicsit a Maven-t, de azert mukodik. Spring detto. Vannak fajdalmas reszei, de szinte biztos, hogy ugy nagyjabol rendesen meg van csinalva az egesz.

while (!sleep) sheep++;

Hidd el, hogy amit te látsz, az nem a normális webes javascript fejlesztés.
Tudom hihetetlen lesz, de egy immár több, mint egy éves, egészen komoly nagy több emberes frontendes projektnek nálunk pl. így néznek ki a node-modules függőségei (Vuejs 3.2.X miatt még mindig sok benne a beta, alpha csomag, de ezek stabilak, csak épp nem rég lettek a 2.X-ről forkolva):

"dependencies": {
"vue": "3.2.31",
"vue-grid-responsive": "next",
"vue-i18n": "9.2.0-beta.28",
"vue-meta": "3.0.0-alpha.10",
"vue-router": "4.0.14",
"vue-tiny-validate": "0.2.4",
"vue-good-table-next": "^0.1.0"
},
"devDependencies": {
"@intlify/vite-plugin-vue-i18n": "3.3.1",
"@vitejs/plugin-vue": "2.2.4",
"eslint": "8.11.0",
"eslint-config-prettier": "8.5.0",
"eslint-plugin-prettier": "4.0.0",
"sass": "1.49.9",
"vite": "2.8.6"
}

Én kérek elnézést!

Amiről írok, hogy ez a láthatóan nem túl bonyolult vue.js alkalmazás 134 dependenciát hoz be, 100 mb méretben. Az i18 plugin dependencia nélkül, annál ütközés van.

Épp unatkoztam és futtattam egy npm i-t.

A hüjék mostanra tovább mentek az asp-re, meg a node-ra a react, angular és többi szutyokkal karöltve. A php annak köszönhetően kezd egész helyre billenni. Na nem mintha bármelyik framework nem kukába való lenne, mert az ugye hagyatékként hátramaradt. Azokat el kell kerülni, és tűrhető marad.

Ja igen, a 100 mega függőség. Ha csak 100 mega lenne Egy asp környezethez a VS 20 gigányi dependency-t behúz, aztán jön a node az npm miatt 2 giga, meg a node függőségei újabb 4, és akkor még az sql szerver és egyéb tool-ok, plusz a kliens oldalra a per app packages. 30 giga fölött van a stack, mire elkezdhetsz dolgozni. A 100 megában még simán kiegyeznék. Egy wamp is van fél giga, és az még tűrhető a mai 8 giga ramos gépeken. Egy laptopban benne van annyi. Akár 1 gigáig el lehet menni a stack mérettel. A másik 30 kezd el sok lenni.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Egyebkent praktikusan kit zavar a kezdeti X giga? Es egyebkent hogy fugg ossze a diszken levo meret a memoriaigennyel?

Az ESP32 fejlesztokeszlet tobb szaz megabajt, kozben a teljes OS 180 kB memoriaban fut

while (!sleep) sheep++;

Azért nagy dolog a web.
Az zseniális hogy nem kell órákat utaznom a bankba, ahol órákig kell sorba állnom.
Most meg csak belépek otthonról és megcsinálom.
Persze van amikor nem működik.

A technológiák versenyéről írtam, nem arról, hogy az informatika jó-e vagy sem.

Forget your troubles, c'mon get happy

Nem tudom, mi is reactot kezdük el csinálni és eddig pozitív a dolog kimenetele. Gyorsan lehet vele haladni, sok okos dolgot tud. A laravel nem jött be, ekkor dobtuk a phpt és mentünk inkább js vonalra.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Azta 100mb méret a node_modules, és maguk alá 134 alfüggőséget húznak be? Úúúú de dúrva
Az app egyébként valóban nem a legkomplexebb, viszont nem is egyszerű, még ha a dependency-k alapján annak is tűnhet. Csak mi nem rohanunk mindenért külön lib-et behúzni, hanem igyekszünk sok mindent házon belül tartani, megoldani. Lehet, hogy ezzel van amikor plusz pár nap munkát okozunk magunknak, viszont a végeredmény sokkal jobban menedzselhető lesz, és a kismillió függőségnek se vagyunk úgy kitéve, amivel meg végeredményben munkát tudunk spórolni, és a végeredményünk is személyre szabottabb, kisebb bundle méretű tud lenni.

Én kérek elnézést!

Engem nem a függőségek száma, vagy a modulméret szokott zavarni, hanem amikor elkezd nem működni a dolog. Ütközés, satöbbi. És akkor lehet kezdeni a doksik, fórumok feltúrását. Composer php alatt ugyanez.

Forget your troubles, c'mon get happy

No igen, mindenki futott bele ilyenbe, ezért is próbáljuk minimálisra csökkenteni a frontend kódunk kitettségét ennek, pláne amikor csomó olyan lib van, amit tényleg szinte semeddig nem tart megcsinálni magunktól.

Én kérek elnézést!

A 134 dependencia nem amiatt riasztó, hogy mennyi helyet foglal a diszken.
A probléma, hogy a 134 dependencia az vagy 100 vendort jelent, mindegyik hozza magával a saját kódolási stílusát, véleményét és bugjait.

A tietek egy egyszerű eset, mert tudatosan nem húztok be mindenre egy libraryt. A vadonban az általános inkább az, hogy mindenki nyakló nélkül húzogatja be a dependenciákat, aztán a végeredmény az lesz, hogy az egész rendszert a szentlélek tartja össze, és ha a több száz dependencia közül 1-el bármilyen probléma van, akkor az egész kártyavár összeomlik.

És probléma lehet bőven. Senki se tudja megszámolni, a több száz libraryból hányan változtatgatják a globális típusok prototípusait. Senki sem tudja, ki mit hívogat node-gyp segítségével, vagy mit matat a filesystemben. Még abban sem lehetsz biztos, hogy a több száz dependenciád mind helyesen követi-e a szemantikus verziózást.
Emlékszünk a left-pad.js problémára. Vagy a múlt héten a hülyére, aki a node-ipc package-be malware-t rakott.

Tök mindegy mit matat ha dockerből fut.

Szerintem ez megint a rossz oldal.Dolgoztam olyan helyen ahol saját microservice volt összepattintva mert csak (a magyarázat az volt, hogy a Spring 10ns-kel lassabb, a valóság pedig, hogy a külső cég aki bevezette ott a microserviceket (KEK) máshoz értett) és bizony eléggé pain in the ass volt.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Amit írsz node.js-hez (de hehe Python-t, sőt PHP-t is láttam már emiatt kártyavárként dőlni) teljesen igaz. Webes frontend dolgokra mérsékelten igaz. Egyébként meg, ahogy mondtam nem kell, agyatlanul mindenre libeket behuzigálni, és akkor elég könnyen lehet minimalizálni ezt a problémát.

Én kérek elnézést!

> Tök mindegy mit matat ha dockerből fut.

a halozatra kimehet a docker is

while (!sleep) sheep++;

nyilvan, de most arrol van szo, h egy kompromittalt npm modul problema-e, es a valasz az, h 'jellemzoen igen'

while (!sleep) sheep++;

Ezért van az, hogy egy rendes cégnél nem csak úgy update-elünk égbe-világba, hanem van UAT (külön környezetben) és ha valami nem megy, akkor nincs élesbe állítás, hanem ki van vizsgálva mi ment gallyra.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Vagy nem ha nem engeded.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

UAT onmagaban kb. semmit nem er biztonsagi szempontbol. (Nalunk nincs is egy konkretan UAT egyebkent, kortlatlan szamu "UAT" kornyezetet fel tudunk loni barmelyik git branchbol.)

[ Szerkesztve ]

while (!sleep) sheep++;

A kovetkezo lepcso meg az, hogy van library compliance, illetve a build soran csak a compliant library-kat tartalmazo registry-k erhetok el. Meg library approval process.
De ez az a kategoria, amit mindenki gyulolni szokott. Foleg akinek meg kell kuzdenie az approval mocsarakkal.
Meg persze build artifact scan tobbfele szempontbol.

I am having fun staying poor.

"Tök mindegy mit matat ha dockerből fut.": a docker security szempontjából nullát ér.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis