Hirdetés
- Google Pixel topik
- Redmi Note 15 Pro+ - több plusz, mint mínusz
- iPhone topik
- Xiaomi 15 - kicsi telefon nagy energiával
- One mobilszolgáltatások
- Vivo X300 Pro – messzebbre lát, mint ameddig bírja
- Samsung Galaxy Watch7 - kötelező kör
- Xiaomi 15T Pro - a téma nincs lezárva
- Távozik az Apple vezérigazgatója
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
Ú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
- BESZÁMÍTÁS! 32GB G.Skill Trident Z Neo RGB 3600Mhz DDR4 memória garanciával hibátlan működéssel
- BESZÁMÍTÁS! 2TB Samsung 990 Pro Heatsink NVMe SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! 2TB Samsung 870 EVO SATA SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! MSI SUPRIM X RTX 3070 8GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Powercolor RED Devil RX 7900XTX 24GB videokártya garanciával hibátlan működéssel
- MSI Gaming Thin 15 - 15.6"FHD 144Hz - Ryzen 7 7735HS - 16GB - 1TB - Win11 - RTX 4060 - 2,5 év gari
- BESZÁMÍTÁS! Intel Core i9 11900K 8 mag 16 szál processzor garanciával hibátlan működéssel
- Thermal Grizzly Aeronaut paszta 3,9g /BONTATLAN/Több darab/Számlával!
- Eladó egy Pixel 7 a Dobozzal tokkal
- AKCIÓ! Sapphire Nitro+ AMD RX 7900 XTX 24GB videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest