- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Mobil flották
- India felől közelít egy 7550 mAh-s Redmi
- iPhone topik
- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
Új hozzászólás Aktív témák
-
bandi0000
nagyúr
válasz
bandi0000
#4284
üzenetére
Ha emlékeztek volt ez a kérdésem, amire az IN-t javasoltátok
Sajnos nem jó, mert ha megadok pl 3 elemet a tömbben, akkor nem azokat adja vissza amibe mind3 van, hanem azokat amibe legalább az egyik, és így értelemszerűen nekem nem jó, lehet erre valami más megoldás?
Én még arra gondoltam, hogy beágyazott selecttel kellene kiszedni ezeket az innel, aztán megszámolni, hogy meg van e az eredmény annyi, mint ami a tömbnek a nagysága, viszont ezt nem tudom hogy kellene kivitelezni
-
bandi0000
nagyúr
válasz
bandi0000
#4295
üzenetére
na szóvalEz a lekérdezésem@Query("SELECT * FROM plants WHERE plants.start_date <= :yearAndMonth and plants.end_date >= :yearAndMonth")
LiveData<List<PlantEntity>> getAllPlantsByDate(String yearAndMonth);A Dátum formátum: 2019-05-05
És amit átadok neki paramétert : yearAndMonth ott ezt kapja: 2019-05*És ugye mondtam, hogy a felső határérték dátumnál megáll és annyiadik napig adja vissza az értéket amíg kell, de az alsónál meg nem ad vissza semmit a kezdő hónapraTehát mikor a yearAndMonth 2019-05 akkor azokat a rekordokat nem kapom meg, amik 2019-05-08-tól érhetők elNa mire leírtam rájöttem mi a baj, a kezdő dátum az kisebb és nagyobb is lehet mint az aktuális hónap , a vég dátum meg csak nagyobb lehet, így be kellett még raknom egy vagy feltételt és jó lett
-
Ispy
nagyúr
válasz
bandi0000
#4292
üzenetére
1. Miért string a dátum?
2. Lekédezéskor miért nem konvertálod a stringet dátumra?
3. Miért string a dátum?![;]](//cdn.rios.hu/dl/s/v1.gif)
Ha dátum lenne nem kéne konvertálni és mennének rendesen a dátum keresések...
4. Stringből is lehet midenféle mókolással megkapni az évet és hónapot, year, month függvénnyel, pl. ki tudod szedni, hogy 201907 vagy 201912, csak amikor összefűződ garantálni kell, hogy a hónap 2 karakter legyen: eléraksz 00-át és levágod jobbról 2 karakter hosszan RIGHT-tal. Persze előtte garantálni kell, hogy dátumként értelmezhető, jó lenne többet tudni az egészről. -
martonx
veterán
válasz
bandi0000
#4281
üzenetére
Ha jól értettelek, akkor ezek között 1-1 kapcsolat van. Azaz milyen normál formát szegnél meg ezzel? Semmi értelme az 1-1 kapcsolatot ily módon szétbontanod (persze lehet értelme, ha annyira óriási lenne a tábla mondjuk 100 mezővel, vagy ha lenne egy gyakrabban változó mező struktúra, és egy fixebb).
Termék - id - név - dátum1 - dátum2 - kép1 - kép2
A fentit semmi értelme így szétbontanod:
termék - id - név
termékid - dátum1 - dátum2
termékid - kép1 - kép2
-
válasz
bandi0000
#4277
üzenetére
Szia!
A képeknek és a dátumoknak van köze egymáshoz? Arra gondolok, hogy a kezdet az éretlen fénykép, a vég pedig az érett?
Mi a cél?Elvileg lehet 1 táblában is, de kettőben is. Pl, ha kettő, akkor az 1-esben tárolnám a zöldségeket azonosítóval, névvel kezdet, vég dátummal. A másik táblában pedig lenne a zöldségazonosító a képkészítés dátum és a kép. A kettőt a zöldségazonosító és a dátum mezőkkel kapcsolnám össze.
-
rum-cajsz
őstag
válasz
bandi0000
#4032
üzenetére
Ha jól értem a problémádat, akkor nem a dátumot/időt kell kitenni a külön táblába, hanem a vásárláshoz tartozó termékek listáját.
Tehát a te logikád szerint:
TERMÉK (termékid, terméknév, stb)
VÁSÁRLÁS (vásárlásid, eladó, vevő, dátum, fizetendő, stb)
VÁSÁRLÁSTÉTEL (id, vásárlásid,termékid, db, stb.)táblák kellenek.
-
bpx
őstag
válasz
bandi0000
#4032
üzenetére
Ennyi erővel az árat és a darabszámot is ki lehetne tenni külön táblába, mert lehetséges, hogy különböző termékeknek ugyanannyi az egységára és ugyanannyi darabot vásároltak belőle ugyanakkor.
Ezt pl. úgy szokták csinálni, hogy külön táblába kerül a vásárlás és annak a tételei, hogy milyen termékeket vettek. Pl.:
VÁSÁRLÁS(vásárlás_id, dátum+idő)
VÁSÁRLÁS_TÉTEL(vásárlás_tétel_id, vásárlás_id, termék_id, db, ár) -
Doink
aktív tag
válasz
bandi0000
#3758
üzenetére
Teljesen korrekt csak még hegesztgetni kell rajta.
- Fogalalt-e mezők feleseslegesek mert azt látod a bérlés/kölcsönzésből.
- Nincs klub tábla annak ellenére hogy a kluboknak és a klub tagoknak is lehet hajója. Ha egy ember több klubban is lehet akkor értelem szerűen many-to-many lesz.
- Jacht_kikötője rossz helyre van kötve, most az a klubtagok kikötője.
- A Jachtnál az épp_ebben_a_kikötőben_van dolog kicsit cseles mert ha éppen nem bérelték ki mégis mozgott akkor gondolkodni kell azon, hogy az is bekerül az útvonalba NULL bérléssel vagy sem. Ha igen akkor nem kell épp_ebben_a_kikötőben_van mező, ha nem akkor kell.Úgy hirtelen ennyit látok.
-
Doink
aktív tag
válasz
bandi0000
#3756
üzenetére
Ez jól hangzik, de a sok szöveg helyett foldobhattál volna egy ábrát mert az többet mond minden szónál.
Az első kérdésedre a válasz ha jól értem akkor idegen kulcsokkal tárolnád szóval nem probléma.
A hajós dologhoz:
hajók(hajo_id, jelenlegi_kikötő_id, .....)
kikötők(kikötő_id, cím, .....)
kölcsönzések(kölcsönzés_id, ......)
útvonalak(id, kölcsönzés_id, hajo_id, kikötő_id, érkezés_ideje, ....)Most itt nem tárgyalom ki hogy az id mezők helyett lehetne összetett kulcs mert nem írtál semmi sémát arról, hogy mit kell tárolni.
Ha feltételezzük, hogy egy hajó nincs mindig kikötőben mert néha épp járja a vizet akkor úgy csináld ahogy írtad és arra vigyázz, hogy az útvonalba bekerüljön az induló kikötő induláskor. -
Szmeby
tag
válasz
bandi0000
#3624
üzenetére
Szevasz,
én nem tudom elmagyarázni, de az biztos, hogy az iskolán kívül nem kell először kettesbe, majd hármasba forgatni, hanem a cél, hogy minél előbb kellően normalizált legyen az a DB, és gyorsan szállítsuk a megrendelőnek, mert már tűkön ül, hogy miért nincs még kész.
2NF
Ha eltekintünk attól a ténytől, hogy a valóságban egy gyerek több általánosba is járhat, és a példánál megszabjuk, hogy márpedig nem járhat, akkor nyilvánvalóvá válik, hogy egy gyerek csak egy általánosba jár, így a középiskolás kiszervezésével meg is van a 2nf. Gondolom. Mivel a gyerek önmagában meghatározza az általános iskolát is. Amiből csak egy lehet, mint ahogy korábban megszabtuk. Míg középsuliból több is, így szükségessé válik a gyerek duplikációk megszüntetése. Amit egy szuper kis kapcsolótáblával oldunk meg. Így 1 tanuló csak egyszer fog szerepelni a tanulók táblában, mert már nincsenek ott azok a csúnya középiskolák, amelyek megduplázták (megtöbbszörözték) a sorok számát.3NF
Viszont azt is látjuk, hogy ez még nem elég, mert ugyan a gyerekek már egyediek, de a Csillagvár bizony kétszer is feltűnik, két gyerek is ugyanoda jár. Ez nagy pazarlás, minden gyereknél nyilvántartani ugyanannak a sulinak a címét. Mi van, ha a suli elköltözik? Vagy kedves vezetőnk átnevezi az utcát, mert ahhoz van kedve? Elkezdjük tömegesen átírogatni a tanulók tábláját azért, mert az iskola adataiban valami megváltozott? Ha kézzel kellene átírnod, neked se lenne természetes a mosolyod egy néhány tízezres tanulóbázis esetén. Mennyivel egyszerűbb lenne 1 helyen átírni a suli címét, és az automatikusan az összes adott suliba járó gyerekre igazzá válna. Hát ezért szervezzük ki az általános iskolát is külön táblába. Felhívnám a figyelmet, hogy ez esetben egy-több a kapcsolat, így a kapcsolótábla szükségtelen.Összefoglalva: Úgy látom, a 2NF arra jó, hogy a sok-sok duplikált SOROK számát csökkentsük le. A tanulók táblában a tanulók a fontosak, vagyis a cél, hogy soronként különböző tanulókat lássunk. Ne szerepeljen két sorban ugyanaz a tanuló. A 3NF pedig arra jó, hogy az adott táblában található kiegészítő (értsd: a tanuló személyéhez nemigazán tartozó) ADATOK ne szerepeljenek feleslegesen többször, mert ha azokat át kell írni, az halál.
Hogy mi az, ami nem tartozik a tanuló személyéhez? Azt érezned kell. A neved például a tiéd, a születési dátumod is a tiéd, mivel az nem változhat, vagy ha változik, akkor te is változol vele. A lakcímed pl. nem a tiéd, mert simán elköltözhetsz, és más költözhet a te címedre. A sulid sem a tiéd, mert rajtad kívül sokan mások is abba a suliba járnak, még a mobilod sem a tiéd, mert bármikor lecserélheted, másnak adhatod. Ami nem a tiéd, nem a téged nyilvántartó táblába tartozik, hanem egy másikba.
Persze megfontolás kérdése, ha csak az iskola nevét akarjuk a tanulónál tárolni, akkor még akár maradhat is a tanuló táblában. Nem szép, de van olyan helyzet, amikor ez a hatékonyabb. De ha mondjuk a suli neve mellett a suli címe is nyilvántartásra kerül, meg a suli alapításának éve, meg az ott dolgozó tanárok száma, stb stb... Azt már nehéz megmagyarázni, hogy a suli alapításának éve mit is keres a tanulók nyilvántartásában. A gyereknek semmi köze hozzá, mikor alapították az iskolát. Szóval ha már ilyen kacifántos tranzitív függőségeket látsz, akkor szólaljon meg benned a csengő, hogy ez külön táblát kíván.Lehet, hogy mégis sikerült elmagyarázni?
Az okosok javítsanak ki, ha hülyeséget írtam. -
nyunyu
félisten
válasz
bandi0000
#3614
üzenetére
Úgy több-több a kapcsolat, hogy egy vásárló több eladótól is vehet (az mindegy, hogy mikor), de egy eladó termékeit is több vevő veheti.
Labor házidra ugyanez igaz, egy ember több fodrászhoz is foglalhat időpontot, de egy fodrásznak is több vendége van egy nap, és ezek egymástól függetlenek.
Minden egyes tranzakció egy új rekord lesz a foglalásos táblában.
-
nyunyu
félisten
válasz
bandi0000
#3612
üzenetére
N:M reláció:
Jól látod, foglalásnak külön tábla kell 4 oszloppal:
- foglalt termék idegen kulcsa
- foglaló vevő idegen kulcsa
- foglalás ideje
- foglalás áraMajd az itt tárolt külső kulcsokkal joinolod össze a foglalót a foglalt termékkel.
[szerk:]Céges feladat? Ez inkább egy állásinterjúhoz szakmai beugrónak tűnik, amit fél délután össze lehet rakni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha dátum lenne nem kéne konvertálni és mennének rendesen a dátum keresések...
Új hozzászólás Aktív témák
Hirdetés
- Vezetékes FEJhallgatók
- sziku69: Fűzzük össze a szavakat :)
- Elektromos autók - motorok
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Tesla topik
- Bambu Lab 3D nyomtatók
- Milyen notebookot vegyek?
- The First Berserker: Khazan
- OLED TV topic
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600XT 16GB GAMER PC termékbeszámítással
- LG 27GR95UM - 27" MiniLED - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 1000
- Fém, összecsukható és kihúzható fotó állvány eladó
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest