Új hozzászólás Aktív témák
-
válasz
DNReNTi
#3294
üzenetére
Nem értek az SQL-hez, hogyan kellene ezt megírni? Így kezdődik a 14000 soros lekérés:
USE database;
DELETE FROM wp_1_comments WHERE comment_approved = 'spam';
DELETE FROM wp_2_comments WHERE comment_approved = 'spam';
DELETE FROM wp_3_comments WHERE comment_approved = 'spam'; -
kezdosql
tag
válasz
DNReNTi
#3263
üzenetére
Nem, egyikotoknek sincs fogalma se rola, mert ti csak abban gondolkodtok, hogy vannak adattablak, amiket csak ossze kell kapcsolni es kesz.
Az en feladatom az, hogy kitalalni, hogy mi a nyavalya van az adattablaban, es ezt valahogy leirni.
Peldaul kapok egy csv fajlt azzal, hogy "Telephely rezsi".
Az elso oszlop datum, masik ido. Utana van negy oszlop, az oszlop neve szamokbol all, utana jartam, azok a meroorak szamai, tehat tudom, hogy van ket aramot mero ora, egy gazora es egy vizora.
Az adatokbol latni, hogy az egyik arammerot szinte orankent leirtak, a masikat naponta negyszer, a gazorat is van, hogy ket orankent, van, hogy naponta hatszor, a vizorat hetente ketszer.
Ezekrol tudom, hogy 3 tizedesig kell szamokat tartalmaziuk es ures mezo is van.
Emellett van meg hat masik oszlop, amikrol meg nem tudom, hogy mit takarnak az adatok, a tobbseg ures, neha vannak szamok, neha karakterek.Ki kell talalnom, hogy mit jelentenek az oszlopok nevei es leirast kell irni rola, majd csinalni egy olyan nyilvantartas, amibol azonnal latom, hogy melyik fajlban melyik oszlopban milyen adatok vannak.
Raadasul ugy kell megcsinalnom, hogy lassam, hogy melyik fajl hol van, melyik oszlopadatanak meg nem tisztazott a szarmazasa es tartalma, es mik azok, amik rendben vannak.
Messze nincs semmilyen adatbazis sehol, meg csak az adatgyujtesnel tartunk es hihetetlenul nehezen megy.
Remelem, most mar kezditek erteni, mi a problemam.
-
válasz
DNReNTi
#3028
üzenetére
Lehet stored procedure is vagy trigger is a megoldás, szerintem, de nekem valóban az lenne a lényeg, hogy valaki, akinek ezzel sok tapasztalata van, segítsen egy példával.
Én nem nagyon csináltam ilyet, mivel programból is megoldható, de most van rá okom, hogy kiszervezzem. -
Brett001
aktív tag
válasz
DNReNTi
#2701
üzenetére
Hali! Kösz a gyors választ.
1175-öt nem, jó lett köszi!
Ja,mellesleg gondoltam én a WHERE elhagyására (hisz nem kell feltételt szabnunk, hasonlóval próbálkoztam, (el is hagytam) csak unix_timestamp()-t írtam, hisz tudtam, hogy nem kell konkrét érték. Ez igy persze, hogy ne volt jó.
-
martonx
veterán
válasz
DNReNTi
#2697
üzenetére
Igaziból 100K-nyi adat annyira kevés, hogy édesmindegy, hogy melyik verziót választjátok. Ez csak magán vélemény, de az sql adattárolás nem olyan mint egy programkód, azaz ami össze tartozik, és 1 - 1 kapcsolat van közöttük mint esetedben a user neve, jelszava és a user lakcíme, azt semmi értelme csak azért szétbontani, és a másik táblában is elkezdeni egy userID-t vezetgetni, indexelni, meg view-t írni föléjük, hogy mégis egynek látszódjanak stb... mert szeparáljuk minél több, minél kisebb részre az adatokat. Ez SQL adattárolás nem pedig OOP programozás.
És ez nem azt jelenti, hogy ne legyen legalább első normálformára hozva a DB struktúra, csak éppen minek csináljunk felesleges roundtripeket, ha ezek az adatok úgyis összetartoznak.
Persze, hogy ez mennyire eset függő, mert simán tudok magam ellen is érvelni, mikor valakinek több száz Gb-os táblái vannak, és minél jobban partícionálni akarja őket, akkor meg pont az lehet a jó, ha több felé van osztva az adattartalom, mert akkor a cluster több része nagyobb párhuzamossággal tud dolgozni a táblán (mondjuk pár száz millió rekordnál egy rosszul elsült update is ki tudja lockolni az egész táblát), de mondjuk egy szál nagy tábla particionálására is megvannak a módszerek.
Száz szónak is egy a vége, ilyen kevés adatnál teljesen mindegy melyik verziót választjátok, én személy szerint nem kezdeném bonyolítani az egyszerűt.
-
#2696
Sk8erPeter
nagyúr
DNReNTi
#2690
Sk8erPeter
nagyúr
válasz
DNReNTi
#2690
üzenetére
Erre a kérdésre a tárolandó adatok ismeretének hiányában tényleg nem nagyon lehet pontosan válaszolni, DE esetedben már kapásból látszik egy ilyen, hogy pl. user_log, ez már eleve feltételezi, hogy itt több bejegyzés is fog szerepelni, mert elég érdekes napló az, amiben minden korábbi értéket folyton felülírsz.
(Az időnkénti tisztítás más tészta, mert az is kell, de nem így. ) Ergo ez már kapásból különválasztást, normalizálást igényel.
Ha a user_settings sok mezőt feltételez, és akár már nem is 1-1 kapcsolat van köztük, akkor megint csak kötelező normalizálni (egyrészt ronda a teleokádott tábla, másrészt kerülni kell a szokásos anomáliákat).
A többi adat széjjelbontása is csomó mindentől függ, de tényleg tervezési kérdés, ha szebb különválasztva, akkor tedd azt, ha nem, akkor ne.
Nem kell erőltetni, de a jointól sem kell félni, sőt. -
rum-cajsz
őstag
válasz
DNReNTi
#2690
üzenetére
Igazából ez nem elméleti kérdés, hanem tervezési. Attól függ, hogy mire fogod használni később a táblát. Ha felosztod külön táblákra, akkor a lekérdezések gyorsabbak lehetnek, illetve az adatírások nem lassítják az olvasást.
Mellesleg ha egy nézetet készítesz a sok tábládra, akkor nem kell mindig a joinokkal vacakolni, elég a nézet nevét használnod. Ha primary keyen kapcsolódnak, akkor az index mentén a join nem számottevő.Nehéz erre tanácsot adni mert ismerni kellene a rendszereteket, és a felhasználási módokat, de ha nagyobb adatmennyiségről van szó (több százezer) akkor én a több táblás megoldást választanám. Ha csak pár ezer felhasználóról van szó, akkor édesmindegy, válaszd azt, ami közelebb áll a lelkedhez.
-
martonx
veterán
válasz
DNReNTi
#2540
üzenetére
beleokoskodhatok én is?
Amellett, hogy abszolút egytértek veled, ha már nevezéktanról beszélünk, akkor nem kellene rövidítéseket használni pl. _nm
Még most is gondolkozok rajta, hogy mit jelenthet az az nm? Ráadásul abból, hogy size_and_price bőven látszik, hogy miről is szól az a tábla.
Aztán szerintem az alulvonósdi elég idétlen az SQL nevezéktanokban (html-ben persze tökéletes az alulvonás, de ez most SQL). Miért nem lehet simán SizeAndPrice-nak hívni a táblát? Ez totál szubjektív, de szerintem sokkal szebb felesleges alulvonások nélkül. -
#2262
csabyka666
veterán
DNReNTi
#2261
-
#2260
csabyka666
veterán
DNReNTi
#2259
-
#2257
csabyka666
veterán
DNReNTi
#2255
válasz
DNReNTi
#2255
üzenetére
Igazából nem fontos, hogy nullázni tudjam, csak tesztelés fázisban vagyok az oldallal, aztán azt gondoltam, hogy én állítottam be valamit rosszul, és azért nem engedi törölni. Főleg azért gondoltam, hogy én szúrtam el, mert teljesen üres táblákon sem működik, de ezek szerint nem ott van a gond, hanem egyszerűen az adatbázis nem fogja sohasem engedni.
Marad a törlés, és újra létrehozás. Azzal nullázódnak az indexek, és végülis az a cél...
-
#2252
csabyka666
veterán
DNReNTi
#2251
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Vezeték nélküli fülhallgatók
- Milyen külső akkumulátort mobileszközökhöz?
- Kormányok / autós szimulátorok topikja
- Facebook és Messenger
- Meghozta a régóta várt asztali Ryzen APU-kat az AMD
- Spórolós topik
- Bittorrent topik
- E-roller topik
- Anime filmek és sorozatok
- Valószínűleg késnek majd a Valve új Steam eszközei
- További aktív témák...
- Apple MacBook Pro 14 (2021) 16GB/512GB használt, szép állapot 100% akku , 8 ciklus
- BESZÁMÍTÁS! MSI B450 R5 5600X 16GB DDR4 512GB SSD RTX 2070 Super 8GB Rampage SHIVA Adata 600W
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4022
- Azonnali készpénzes Intel i3 i5 i7 i9 12/13/14 gen processzor felvásárlás személyesen / csomagküldés
- 263 - Lenovo ThinkBook 16p (G6 IAX) - Intel Core U9 275HX, RTX 5060
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest