Ú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
- Itt a ChatGPT végső megoldása
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- PlayStation 3
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Google Chrome
- Battlefield 6
- Elektromos autók - motorok
- Határozatlan időre kiszáll az Asus a mobilbizniszből
- Horgász topik
- LEGO klub
- További aktív témák...
- 212 - Lenovo IdeaPad Slim 5 (16IMH9) - Intel Core U5 125H, no GPU
- 211 - Lenovo Legion 5 (15ITH6H) - Intel Core i7-11800H, RTX 3060
- 210 - Lenovo IdeaPad 5 Pro (16ARH7) - AMD Ryzen 7 6800HS, RTX 3050Ti
- 209 - Lenovo Yoga Pro 7 (14APH8) - AMD Ryzen 7 7840HS, no GPU
- 206 - Lenovo Legion Slim 7 (16IRH8) - Intel Core i7-13700H, RTX 4060
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs