- Xiaomi AX3600 WiFi 6 AIoT Router
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Letartóztatták a bitcoin-Jézust
- Hálózatokról alaposan
- ASUS routerek
- Asustor NAS
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Milyen program, ami...?
Új hozzászólás Aktív témák
-
L3zl13
nagyúr
1. Felsorolást tárolni egy mezőben eleve rossz ötlet. Szóval az a minimum, hogy az egyes hobbikat külön sorba rakod, mellette a gyerek nevével.
Itt szvsz még nincs értelme táblákra szétbontani, de a normalizálás szabályai lehet, hogy megkövetelnék...
2. Egy szakács több ételt is csinál illetve több szakács is csinálhatja ugyanazt az ételt. Nyilván nincs értelme a szakács által elkészített minden egyes ételnél eltárolni a személyi adatait.
Tehát személyi adatok egy táblában.
Hasonlóképp a kajáknál, nincs értelme minden egyes elkészítésnél (más szakács, más mennyiség) eltárolni az étel teljes nevét. (Szöveges adat sok helyet foglal...)
Szóval egy táblában a kaja kódja, és neve.
És amivel összekapcsolod a kettőt:
szakácskód, ételkód, mennyiség (+én betennék egy egyedi azonosítót is a kapcsolótáblába)
A fajta nem tudom mit takar, valószinűleg az is külön táblába tartozik...
Kulcsok: Ami a rekordot az egyik táblában egyértelműen azonosítja -> Elsődleges kulcs az adott táblában. És ha a kapcsolótáblában ezt használjuk az összekötéshez, akkor ott meg idegen kulcs lesz.
Pl a személyi adatos táblában a cím vagy név nem egyértelmű azonosító (bár lehet, hogy épp nincs azonos nevű szakács a konyhán), de a személyi szám igen.-> Elsődleges kulcsnak használható, és a kapcsoló táblában viszont idegen kulcs lehet. (Bár én nem ezt használnám, hanem inkább egy generált egyedi kódot...)Aki hülye, haljon meg!
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest