Hirdetés
- Brogyi: CTEK akkumulátor töltő és másolatai
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Krumple: [Xpenology] DSM 7.3 telepítése proxmox 9 alatt - GUIval
- eBay-es kütyük kis pénzért
- Kalandor: „Ha engedtem volna a lelkiismeretemnek, az üzlet kevésbé lett volna jövedelmező”
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
Új hozzászólás Aktív témák
-
DNReNTi
őstag
válasz
kezdosql
#3270
üzenetére
Komolyan egyre inkabb nem ertem, hogy kapcsolodik ez az SQL topikhoz. Arrol nem beszelve, hogy te "mindossze emberi hozzaallast varsz", azoktol az emberektol, akik "azt se tudjak, mit kene csinalni" es "egyikojuknek sincs fogalma se rola, mert ok csak abban gondolkoznak, hogy vannak adattablak, amiket csak ossze kell kapcsolni es kesz", illetve nem kis cinizmust felfedezve "nagyfomeltosagu programozo urak", raadasul ok "lefele taposnak, elvarjak, hogy pontosan azt az adatot kapjak, amire szukseguk van".
Kabare ez az egesz kerem. -
DNReNTi
őstag
válasz
kezdosql
#3261
üzenetére
Szerintem itt a tobbseg eleg jol tudja mit kellene csinalni egy ilyen feladattal, en inkabb azt erzem, hogy te nem tudod, hogy egyaltalan mit akarsz csinalni / csinaltatni, mi a cel, a specifikacio roppant feluletes, totalis fogalmi zavar van, es a faradtsagot sem veszed arra, hogy rakeress a kulcsszavakra amik itt mar elhangoztak.
Nem bantasnak szanom, csak nem ertem ezt az oszto dumat, a fent leirtak es annak figyelembevetelevel, hogy vagy harman probaltak segiteni hasznalhato otletekkel. -
DNReNTi
őstag
válasz
kezdosql
#3254
üzenetére
Gondolom CSV lesz az a CSS.
Egyebkent egy ilyen tok altalonos import rendszert megirni nem egy trivialis feladat. Ilyenkor a legjobb talan az, ha elmondod hogy fog kinezni a bemenet (altalnossagban, tehat: formatum, kotelezo fejlecek, max oszlopszam, stb), es te a vegen mit szeretnel latni. A 60 oszlop egyebkent nem szamit orulten soknak. Sot.
-
DNReNTi
őstag
Sziasztok,
Paraméterezhető MySQL tárolt függvényben van e lehetőség foglalkozni az SQL injection elleni védelemmel, illetve kell e foglalkozni vele? Próbáltam keresni a témában de csak PHP-related topikokat találtam, konkrétan arra példát, hogy pusztán SQL oldalon, hogy lehet prepared statement-eket használni, olyat nem. Valaki tud egy ilyet linkelni?
Thx. -
DNReNTi
őstag
válasz
lakisoft
#2778
üzenetére
"Tudnátok segíteni a logikai felépítésben?"
Szerintem ehhez nem kell kód. Gondolom inkább arra kíváncsi ki hogyan építené fel a táblákat, kapcsolatokat, hogy az jó legyen.És ha már itt tartunk leírom én is:
Mindenképpen kell felhasználók és alapanyagok tábla ugye. Kell egy étrendek kapcsolattábla, ez fogja tárolni melyik felhasználónak mely étrendjei vannak. Ezt követi az étkezések kapcsolattábla ami azt mondja meg mely étrendek milyen étkezéseket tartalmaznak. Végül jön az alapanyag kapcsolattábla, ami összeköti az alapanyagokat az étrendekkel. Hát így nagyon leegyszerűsítve valahogy így. -
DNReNTi
őstag
válasz
Brett001
#2700
üzenetére
Ne használd a lekérdezésben a WHERE-t, hanem engedd rá az egész táblára. Persze ne konstans adattal, hanem az épp aktuális mező tartalmával, valahogy így:
UPDATE table SET datetime = UNIX_TIMESTAMP(datetime);Nem tudom most kipróbálni, de így mennie kéne.
Ha 1175-ös hibát dob, akkor ki kell kapcsolni a safe mode-ot:
SET SQL_SAFE_UPDATES = 0;Azért egy biztonsági mentést csinálj a tábláról.
-
#2697
DNReNTi
őstag
Sk8erPeter
#2696
DNReNTi
őstag
válasz
Sk8erPeter
#2696
üzenetére
Igen az pont 1:n.
Kapkodtam.Lényeg a lényeg, így összesítve az információkat, nem lesz kevésbé hatékony, ha meg vannak osztva az adatok, így aki ezzel érvel, azt el tudom hajtani.
-
DNReNTi
őstag
1-1 kapcsolat persze. A VIEW jó ötlet, eszembe nem volt. Egyébként rosszul tettem fel az eredeti kérdést. Hatékonyabb e, ha egy táblában van? Mert ha csak felesleges az nem gond.
Szerk:
(#2692) rum-cajsz
PK-n vannak összekapcsolva, és igen, elég nagy mennyiség, jelenleg közel 100k felhasználóról van szó. -
DNReNTi
őstag
Sziasztok,
Tegnap melóban felmerült egy érdekes kérdés. Jó kis cicaharc lett belőle.
Melyik a jobb megoldás?
1. Az objektum adatait több táblában tárolni.
pl: user, user_meta, user_settings, user_log.
Így jobban megoszlik az adat, olvasmányosabb a struktúra, cserébe sok a JOIN.
2: Az objektum összes adatát egy táblában tárolni.
pl: Minden felhasználóval kapcsolatos adat a user táblában.
Így ömlesztve van az egész, de egy sima SELECT-tel elérhető minden.(Én az 1. pont táborát erősítettem.)
-
DNReNTi
őstag
válasz
joni1700
#2537
üzenetére
Nem okoskodni akarok és nem is válasz lesz a kérdésre, de én magát a struktúrát átalakítanám egy kicsit általánosabbra később könnyebben bővíthetőre. Először is nem használnék magyar tábla és mező neveket, meg egyáltalán semmit sem magyarul.
pizza tábla:
id (int, pk, uq, ai, nn) - értelemszerű
name (varchar(32), uq, nn) - a pizza neve
description (varchar(255), nn) - leírás, feltétek
active (bool, nn) - aktív / inaktív e a termék
size tábla:
id (int, pk, uq, ai, nn) - értelemszerű
name (varchar(32), uq, nn) - méret neve, pl: 28 cm-es ésatöbbi
active (bool, nn) - aktív / inaktív e a méret
restaurant tábla:
id (int, pk, uq, ai, nn) - értelemszerű
name (varchar(64), uq, nn) - étterem neve
active (bool, nn) - aktív / inaktív e az étterem
size_and_price_nm kapcsolati tábla:
pizza_id (int, pk, nn) - értelemszerű
size_id (int, pk, nn) - értelemszerű
price (smallint, nn) - adott pizza ára adott méretben
discount (bool (vagy smallint ha számszerűen akarod megadni)) - a kedvezmény beállítása
active (bool, nn) - aktív / inaktív e a kapcsolat
restaurant_and_pizza_nm kapcsolati tábla:
pizza_id (int, pk, nn) - értelemszerű
restaurant_id (int, pk, nn) - értelemszerű
active (bool, nn) - aktív / inaktív e a kapcsolatHa jól gondolom ezzel most mindenféle adat és kapcsolat kezelhető lenne amit egy pizzáról tudni kell. Tudni lehet a nevét, a feltéteket, az árát különböző méretekben, az ezekre esetleg alkalmazott akciókat, és azt is melyik pizza melyik étteremben elérhető. Persze ez most fapad, de a végtelenig bővíthető: pl az éttermek címélve kapcsolati adataival, a pizzákat lehetne kategorizálni, ésatöbbi ésatöbbi.
Remélem segítettem, ha nem, akkor meg írtam egy jó kis regényt. -
#2533
DNReNTi
őstag
Sk8erPeter
#2531
DNReNTi
őstag
válasz
Sk8erPeter
#2531
üzenetére
Gondolom arra gondol, hogy akkor már nem a procedurális hanem az oop módon használná a prepared statements-t meg az egész adatbázis kezelést.
-
#2528
DNReNTi
őstag
Apollo17hu
#2527
DNReNTi
őstag
válasz
Apollo17hu
#2527
üzenetére
-
#2261
DNReNTi
őstag
csabyka666
#2260
DNReNTi
őstag
válasz
csabyka666
#2260
üzenetére
Akkor jó hírem van: jól csináltad. Az adatbázis pedig azért nem engedi a már emlegetett parancsokat mert a kulcskapcsolat az üres táblákra is érvényes. Például kitörölnéd a felhasznalok táblát, akkor mit vinnél fel a kapcsolati táblába. Egyébként ebben az egyszerű példában, ha először a kapcsolati táblát törlöd, akkor megszűnnek a kulcskapcsolatok, így törölhető / kiüríthető lesz a többi is.
-
#2259
DNReNTi
őstag
csabyka666
#2257
DNReNTi
őstag
válasz
csabyka666
#2257
üzenetére
azt gondoltam, hogy én állítottam be valamit rosszul
Megint azt tudom írni, attól függ mi a cél. Külső kulcsot akkor használsz amikor egy másik tábla elsődleges kulcsára akarsz mutatni, ez egy szigorú megszorítás, az adatbázis csak meglévő értéket enged ide felvinni. Jó példa mondjuk egy bármilyen (1:1, 1:n, n:m) kapcsolati tábla. A legegyszerűbb példa hogy érthető legyen:
3 táblád van: felhasznalok, hozzaferes_szintek, felhasznalok_hozzaferese.
Itt a kapcsolati tábla a felhasznalok_hozzaferese összesen két mezővel: felhasznalo_id és hozzaferes_szint_id, mindkettő külső kulcs. Ez tipikus, egyszerű esete a külső kulcs használatának, hogy visszatérjek az eredeti gondolathoz, ha ilyesmire használod, akkor jól használod. -
#2255
DNReNTi
őstag
csabyka666
#2252
DNReNTi
őstag
válasz
csabyka666
#2252
üzenetére
Nem is egészen értem pontosan mi is a cél. Jobban mondva a célt értem, csak azt nem miért van rá szükség. Egyébként egy tipp: én minden táblában használok egy "active" nevű mezőt. Ez mindig az utolsó, boolean, default: 1. Minden lekérdezésben szerepel a WHERE active = 1; tehát ha "törölni" akarok egyszerűen csak inaktiválom azt a rekordot, és az "megszűnik" létezni az oldal számára. Lehet csak az én hülyeségem, de szerintem adatbázisból törlést kerülni kell amennyire lehet. Hozzáteszem: éles oldalaknál, amíg tesztelsz és telehányod sallanggal az adatbázist akkor persze érdemes legyalulni. Erre pedig a tökéletes módszer ha exportálod csak a struktúrát, eldobod az összes táblát, majd importálod a struktúrát. Lehet van erre szebb megoldás, ha van, engem is érdekel.
-
#2251
DNReNTi
őstag
csabyka666
#2250
DNReNTi
őstag
válasz
csabyka666
#2250
üzenetére
A DROP sem működik ha kulcskapcsolatok vannak a táblák között. A FOREIGN_KEY_CHECKS ki (és be) kapcsolása működő módszer, ha favágó ha nem, de én csak teszteléskor használom, pl ha ki kell nullázzak egy adatbázist, vagy csak néhány táblát. Nem véletlen nem működik se a DROP, se a DELETE se a TRUNCATE, így ezt egy éles oldalon felejtsd el.
Kulcskapcsolatok okkal vannak egy adatbázisban. -
#2191
DNReNTi
őstag
kemkriszt98
#2190
DNReNTi
őstag
válasz
kemkriszt98
#2190
üzenetére
TRUNCATE TABLE `táblanév`.
Eldob minden rekordot, és visszaállítja az AI-t is.
Nem bantasnak szanom, csak nem ertem ezt az oszto dumat, a fent leirtak es annak figyelembevetelevel, hogy vagy harman probaltak segiteni hasznalhato otletekkel.
Új hozzászólás Aktív témák
- Huawei Watch GT3 46mm Rozsdamentes acél váz, számlás, dobozos
- JBL Boombox 2 Brutális hang, számlás, dobozos, patika állapot
- Apple iPod Video (5. Gen) 30GB - A1136 - Wolfson DAC - Gyűjtői állapot!
- Asus Dual Radeon RX 5500 XT EVO 8GB GDDR6 Számlás, dobozos, újszerű!
- Canon EOS M50 Mark II Travel Kit Számlás (2023), újszerű, minden tartozékkal!
- AKCIÓ! Törött Apple iMac 19.2 i5-8500 Radeon Pro 560X 4GB 16GB 256GB SSD 21.5" 4K Retina
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB DDR5 RAM RTX 5070 12GB GAMER termékbeszámítással
- BESZÁMÍTÁS! GIGABYTE A520M R5 1400 8GB DDR4 256GB SSD 500GB HDD GTX 1050 Ti 4GB ZALMAN S3 400W
- BESZÁMÍTÁS! Acer Predator Helios Neo 18 Ai - Ultra 9 275HX 32GB DDR5 1TB SSD RTX 5070Ti 12GB W11
- HIBÁTLAN iPhone 13 Pro Max 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3521
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest