- Motorola Moto G06 Power – nagyfater új zakót vett
- Honor 200 - kétszázért pont jó lenne
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Google Pixel topik
- Android szakmai topik
- Fotók, videók mobillal
- MWC 2026: Bajnoki címre pályázik a Xiaomi Watch 5
- Bemutatkozott a Poco X7 és X7 Pro
Új hozzászólás Aktív témák
-
modder
aktív tag
válasz
bambano
#2081
üzenetére
Nem nagyon voltak meggyőző érvek a szöveges tárolás ellen. A település név tök jó példa.
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig? Egy településeket tartalmazó táblára mindig szükségünk van, mert valahol el kell tárolni a lehetséges értékeket.
bambano:
Sématervezési szempontból semmivel sem rosszabb, ha szövegként van tárolva a település neve a személy táblában. Ez nem növeli a redundanciát, se nem lesz denormalizált. Redundanciáról akkor beszélhetnénk, ha a lélekszámot is mindig eltárolnánk a település neve mellett a személyek táblában, mert a település neve meghatározná a lélekszámot, így ez utóbbi tárolása is (még mindig a személyek táblában) csak bonyodalmat okozna. Pontosan ez is a redundancia definíciója. Ha már a normálformákat hoztad fel, vegyél elő egy egyetemi jegyzetet, és olvass bele. Vagy pl. ez egész jól leírja: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.2Ha van egy település táblánk, a település neve - mint szöveg - ugyanúgy lehet idegen kulcs a személyek táblában. Nem kell ahhoz numerikus elsődleges kulcs, hogy kikényszerítsük a személyek táblában, hogy csak bizonyos település neveket lehessen felvinni.
"azok után pedig, hogy azt állítottam, az sql-ben a teljesítményt feláldozzuk más célok elérése érdekében, ez a link mennyiben releváns?"
Attól, hogy állítasz valamit, az még nem biztos, hogy igaz. Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el, pedig az SQL csak arra jó, hogy nem neked kell megírnod, hogy mikor melyik indexeket akarod használni. De az SQL végrehajtási tervbe fordítása mellett még száz másik szempont van, ami nagyban befolyásolja a lekérdezés sebességét, aminek semmi köze ahhoz, hogy milyen lekérdezőnyelvet használsz. És persze az sql-t is többféleképpen írhatod meg, hogy segíts az optimalizálónak a hatékonyabb végrehajtási terv elkészítésében.martonx: Köszönjük a hozzáértő, szakmailag megalapozott hozzászólást

Ami megfontolandó:
- karakterkódolási problémák: Ez általában olyan, hogy vagy fennáll az egész adatbázisra és az őt használó alkalmazásra, vagy nem, ami persze más szöveges mezőket is érint.
- "könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?
- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?
- tárolás: a szöveg több byte-ot használ felA hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni, amikor a tárolási kapacitás és pl. a beszúrási (index frissítési) sebesség sarkalatos pont, ami egy "egyszerű" webalkalmazásnál ritkán fordul elő.
pazsitZ: leginkább mysql cli, phpmyadmin vagy egyéb kliens programra gondoltam, amikor kotorászásról beszéltem.
Új hozzászólás Aktív témák
- ELADÓ FOXWELL NT630 Plus OBD2 autódiagnosztikai eszköz
- Ryzen 7 3700X / RTX 2060 SUPER / 32GB RAM / 512GB NVMe Gamer PC
- Beszámítás! Motorola Sound Flow XT2549-1 hangszóró hibátlan működéssel
- Beszámítás! Lenovo Thinkpad P15 Gen 1 FHD notebook - i7 10850H 32GB DDR4 1TB SSD T2000 4GB W11
- Beszámítás! Samsung Galaxy S23 Ultra 256GB okostelefon garanciával hibátlan működéssel
- 27% - ASUS VY229HF IPS Gaming Monitor! 1920x1080 / 100Hz / 1ms / FreeSync
- S21 Dobozában 128/8
- DELL LATITUDE 7330 /i5-1245U/16GB/256 GB SDD/13.3/FHD/IPS/Garancia/
- Beszámítás! Asus TUF VG249Q 24 144Hz FHD IPS 1ms monitor garanciával hibátlan működéssel
- Lian Li LCD-s 360mm-es vízhűtés akciós áron eladó!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest


