Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz Speeedfire #1090 üzenetére
Nyilván MySQL-ről van szó.
Lehet 2 timestamp 1 táblában.
Ami a baja, hogy ha van két timestamp egy táblában, azt nem lehet megcsinálni, hogy az egyik mezőnek defaultból CURRENT_TIMESTAMP az értéke, ÉS a másiknak pedig on update CURRENT_TIMESTAMP tulajdonsága van. Ahogy az sem lehet, hogy mindkettő mezőnek on update CURRENT_TIMESTAMP tulajdonsága van, vagy mindkettő mezőnek CURRENT_TIMESTAMP a default értéke.
Választani kell.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #1111 üzenetére
"Hogy lehetne engedélyezni ezt a felhasználót az adatbázisban?"
Screenshot
1.) "Jogok" fül
2.) itt hozzá tudod adni az új felhasználót; de nálad ez már megtörtént, úgyhogy "Jogok szerkesztése" az adott felhasználónál
3.) "Adatbázis-specifikus jogok" résznél "Jogok hozzáadása a következő adatbázison:", kiválasztod a megfelelő adatbázist,
4.) itt a "Jogok szerkesztése" ablakban kiválasztod, milyen jogokat akarsz adni az adott felhasználónak (kattints a "Mind kijelölése" linkre, ha minden jogot meg akarsz adni az adott felhasználónak ezen az adatbázison belül
5.) Indítás, és kész vagy.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #1115 üzenetére
Hát akkor lehet, hogy az adott táblára globális jogok vonatkoznak, hogy minden felhasználó hozzáférhessen, szóval akkor az adott adatbázisnál a "Jogok ellenőrzése" résznél meg kellene kukkantani, milyen jogosultságok vannak beállítva; vagy az adott júzereknek túl sok a joga. Az tényleg nem jóféle, ha mindenki hozzáfér.
=====================
WolfLenny : nincs mit![ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #1120 üzenetére
Az adott felhasználónak, akivel kapcsolódsz a Yii-n keresztül, van joga a feltöltéshez is?
Sk8erPeter
-
PazsitZ
addikt
válasz Speeedfire #1120 üzenetére
Ha attributumon keresztul mentesz nezd meg a safe attributumokat
- http://pazsitz.hu -
-
martonx
veterán
válasz Speeedfire #1128 üzenetére
Meg mondjuk ott egy DB szerver akkora, mint egy szoba.
Én kérek elnézést!
-
martonx
veterán
válasz Speeedfire #1132 üzenetére
A noSQL sem csodaszer. Select-ek futtatásában pláne nem.
Bonyolult adatstruktúrák írásakor sokszorosa, akár százszorosa a sebessége a hagyományos RDBMS-ekhez képest.
Bonyolult adatstruktúrák olvasásakor van olyan eset, amikor jóval gyorsabb (néhány szoros) a sebessége a hagyományos RDBMS-ekhez képest.
Full-text search-ben sokkal rugalmasabbak, gyorsabbak a noSQL-ek, különösen azok, amelyek magukba intergálják a Lucene-t is, ilyen pl. a ravenDB
Viszont ha van egy komolyabb adatstruktúrád, de annak csak bizonyos elemeit akarod lekérdezni (mintha több táblád lenne hagyományos sql-ben, de éppen csak egyet akarsz lekérdezni, vagy csak 1-2-t), nos egy ilyen triviális feladat noSQL-ben már korántsem triviális.Ebben az esetben a webszerver, hogy Apache, vagy nginx, vagy IIS, vagy Tomcat vagy bármi totál lényegtelen. Nem az lesz a szük keresztmetszet.
Én kérek elnézést!
-
PazsitZ
addikt
válasz Speeedfire #1137 üzenetére
NoSQL DB-knél, mindegyiknek megvan a maga rendeltetése célja, amire jól hasznosítható.
Nincs és nem is lesz ultimate winner.
[link]- http://pazsitz.hu -
-
martonx
veterán
válasz Speeedfire #1137 üzenetére
Pont a múltkor kezdtem el noSQL-ezni, pont a mongoDB-vel. Én is még csak kostólgatom. Viszont ahhoz, hogy dönteni tudjak közülük (mármint RDBMS - noSQL közül, és ha noSQL, akkor melyik), bele kellett mélyednem az előny-hátrányaikba.
Még annyit tennék hozzá a fentebbi irományomhoz, hogy amit írtam, az a dokumentum alapú NoSQL-ekre vonatkozik. A kulcs-érték, gráf stb... típusú NoSQL-eknek értelemszerűen teljesen más előnyei lehetnek. RDBMS kiváltásához nyilván a dokumentum alapú NoSQL-eket szokták használni.Én kérek elnézést!
-
martonx
veterán
válasz Speeedfire #1150 üzenetére
Szvsz nem ajánlott keverni, legalábbis vagy RDBMS-t, vagy dokumentum alapú NoSQL-t érdemes használni. És e mellé persze könnyen lehet gráf tárolót, vagy kulcs-érték tárolót használni (lásd pl. Facebook, ami MySQL alapú, de a kapcsolatokat gráf tároló NoSQL-ben tartja).
Én kérek elnézést!
-
rum-cajsz
őstag
válasz Speeedfire #1152 üzenetére
vagy írsz egy függvényt, vagy egy másik táblában definiálod a kívánt sorrendet.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
PazsitZ
addikt
válasz Speeedfire #1152 üzenetére
SELECT id, name, type FROM table
WHERE type IN (1,2,3)
ORDER BY
CASE type
WHEN 3 THEN 1
WHEN 1 THEN 2
WHEN 2 THEN 3
END;- http://pazsitz.hu -
-
bpx
őstag
válasz Speeedfire #1155 üzenetére
persze mert első futás után már cache-ből megy
-
Sk8erPeter
nagyúr
válasz Speeedfire #1167 üzenetére
Hát én komplexebb feladatokra tárolt eljárást használok, mióta belekóstoltam.
De a te feladatodat igazából nem értem, hogy miért akarod tömbökbe szedni a userek id-ját... Adott userekhez tartozó bejegyzéseknél X időközönként csak Y mennyiséget akarsz törölni, tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Szóval nem csak törölni kell a táblából azt az Y sort, azt' kész?
Fejtsd ki, MOST!===
(#1166) lakisoft :
"Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya ."
Miért, a tárolt eljárás önmagában még nem ocsmány, de el lehet rondítani.Sk8erPeter
-
bpx
őstag
válasz Speeedfire #1167 üzenetére
PHP-t erre felejtsd el, adatok ilyen szintű manipulációját az adatbázis végezze, ne a hozzá kapcsoló alkalmazás
ez 1, azaz egy darab színtiszta SQL utasítás:
DELETE FROM tabla WHERE id IN(
SELECT id FROM(
SELECT id, RANK() OVER (PARTITION BY uid ORDER BY time DESC) r FROM tabla)
WHERE r > 500);magyarázat:
a legbelső select partíciókat képez a táblából az uid alapján, és a partíciókat idő szerint (time) csökkenő sorrendbe rendezi, és minden egyes id-hoz rendel egy sorszámot (rank), hogy adott partícióban a rendezés szempontja szerint hanyadik helyen áll
az eggyel kintebb levő select lekérdezi azokat az id-kat, ahol ez a "rang" 500-nál nagyobb, tehát kívül esik a kívánt limiten
a delete meg törli az ilyen id-val rendelkező sorokat
szerk: adatbáziskezelőt mondjuk nem írtál, ez Oracle-ben működik, én a tábládból úgy tippelem hogy MS SQL (auto increment PK, meg int típus), de ezek a funckiók mintha ott is meglennének
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Speeedfire #1804 üzenetére
Úgy akarod, hogy a lekérdezésed eredménye az legyen, hogy:
minden fórumazonosító (id) egyszer, ezekhez pedig a legutolsó (=legfrissebb) komment (comment), és a hozzá tartozó create_time érték? Ha igen, akkor kell bele a comment mező is vagy elég csak az időpecsét? -
válasz Speeedfire #1804 üzenetére
select *
from forum t
left join (select forum_id, MAX(create_time) as lastTime group by forum_id) as s
on t.id=s.forum_id
order by s.create_time desc[ Szerkesztve ]
-
válasz Speeedfire #1808 üzenetére
Fentiból hiányzik egy from comment, mindegy.
Sub query nélkül is lehet:
select t.id, t.name, MAX(s.create_time) as order
from forum t
left join comment s on t.id=s.forum_id
group by t.id, t.name
order by MAX(s.create_time) desc -
Ispy
veterán
válasz Speeedfire #1811 üzenetére
Ha MS SQL, akkor igen.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Ispy
veterán
válasz Speeedfire #1813 üzenetére
select * from (select * from message) message
helyett elég ez is:
select * from message
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Ispy
veterán
válasz Speeedfire #1815 üzenetére
Nem is kell oda, vedd ki belőle
select * from message
pivot
(
max(translation)
for(language) in (hu, en, de)
) pivotmess;[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Apollo17hu
őstag
válasz Speeedfire #1811 üzenetére
vagy:
SELECT id
,MIN(CASE
WHEN lang = 'hu' THEN
mess
END) AS "hu"
,MIN(CASE
WHEN lang = 'en' THEN
mess
END) AS "en"
FROM tabla
GROUP BY id -
Apollo17hu
őstag
válasz Speeedfire #1818 üzenetére
Igen, ugyanazt az eredményt hozza a kettő, de azért írtam be, mert a pivotot talán nehezebb "testreszabni" nagyobb mátrixoknál.
-
bambano
titán
válasz Speeedfire #1822 üzenetére
én úgy látom, hogy itt a from query-ben megadott select eredményét hozza ki, nem pedig a megadott select lefuttatásával kapott eredményt.
de lehet, hogy elgépeltem valamit, nem tudom.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz Speeedfire #1824 üzenetére
execute vagy pl/pgsql scriptben van, vagy prepared statementben. Ez utóbbi esetben nem így kell meghívni, hanem a nevével és a paramétereivel.
a pl/pgsql scripttel azért nem bírtam még zöldágra vergődni, mert nem lehet tudni előre, hogy milyen formátumban adja vissza a táblát az exec, de azt előre bele kellene drótozni a scriptbe. pech.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Speeedfire
nagyúr
válasz Speeedfire #1876 üzenetére
Érdekes mód a select részeb írva már jó volt.
select
a.*,
(select group_concat(b.mezonev separator ',') as listagg from tabla_2 where a.id =tabla_id) b
from tabla_1 aFotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
amargo
addikt
válasz Speeedfire #1876 üzenetére
left joint írtál be, nem inner joint. Mit is szeretnél pontosan?
“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
Speeedfire
nagyúr
válasz Speeedfire #1879 üzenetére
Valami ilyesmit, amit utána concat_ws()-el fűznék össze, de nem hiszem, hogy nincs rá jobb megoldás.
select concat_ws(',',
`int1`,
`int2`,
`int3`,
`int4`,
`int5`,
`int6`
) as tipus
from (select
case
when `int1` = 1
then 1
end as int1,
case
when `int2` = 1
then 2
end as int2,
case
when `int3` = 1
then 3
end as int3,
case
when `int4` = 1
then 4
end as int4,
case
when `int5` = 1
then 5
end as int5,
case
when `int6` = 1
then 6
end as int6
from pelda) a;De nem túl elegáns szerintem.
[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Apollo17hu
őstag
válasz Speeedfire #1880 üzenetére
Az nem lenne jó, ha előbb a 2. táblából csinálnál egyetlen konkatenált oszlopot (+ mellé az id oszlopot), majd az így kapott lekérdezést kötnéd (allekérdezésként) az 1. táblához?
SELECT ...
FROM tabla1
JOIN (SELECT tabla2.id, [konkatenált oszlopok]
FROM tabla2)
ON tabla1.id = tabla2.id[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Speeedfire #1882 üzenetére
Ja, most már értem. Akkor én passzolom a témát.
Botlottam már hasonló problémába korábban, akkor úgy szerettem volna az értékeket összefűzni egy mezőbe, hogy az ismétlődések csak egyszer jelenjenek meg benne. Lényegében te is ezt csinálnád a nullértékekkel/nullákkal. Na, erre nincs normális függvény [prog.hu -n legalábbis nem tudtak segíteni, és gugli is csak olyan találatokat adott, ahol ciklusokat kell használni (PL/SQL)].Esetleg ha úgy csinálnád, hogy:
SELECT
CASE WHEN a.int1 IS NOT NULL THEN a.int1 || ', ' END ||
CASE WHEN a.int2 IS NOT NULL THEN a.int2 || ', ' END ||
CASE WHEN a.int3 IS NOT NULL THEN a.int3 || ', ' END ||
CASE WHEN a.int4 IS NOT NULL THEN a.int4 || ', ' END ||
CASE WHEN a.int5 IS NOT NULL THEN a.int5 || ', ' END ||
a.int6
FROM (...) a[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Speeedfire #1884 üzenetére
Jövő héten ki fogom próbálni, pont az volt a gáz, hogy a listagg() függvény nem engedte a DISTINCT-et.
-
bpx
őstag
válasz Speeedfire #1887 üzenetére
"Subqueries cannot be used in the FROM clause of a view. "
-
Ispy
veterán
válasz Speeedfire #1889 üzenetére
Hol használod? Mire? Tárolt eljárás? Minek kell ennyi subselect? Kód?
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Ispy
veterán
válasz Speeedfire #1891 üzenetére
Én biztosan nem próbálnék meg subselectes unionos viewkat használni, egy tárolt eljárásban szét kell szedni a feladatot, mert ez így nem lesz egy villám.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Ispy
veterán
válasz Speeedfire #1893 üzenetére
Akkor viszont a subselectek helyett viewk, majd joinnal összekötöd ezeket.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Ispy
veterán
válasz Speeedfire #1906 üzenetére
Hagy ne kelljen már találgatni, azt hiszem ez elvárható, ha már valaki segítséget akar.
Szerintem nyugodtan szét lehetne szedni ezt a topikot arra a pár SQL nyelvre, amit a nagy többség használ.
MySql-nek például van dedikált topikja.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
Új hozzászólás Aktív témák
- Kínai, és egyéb olcsó órák topikja
- TCL LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kormányok / autós szimulátorok topicja
- Hálózati / IP kamera
- ASUS ROG Ally
- PlayStation rajongói nyereményjáték
- Szeged és környéke adok-veszek-beszélgetek
- (nem csak) AMD FX / Ryzen tulajok OFF topikja
- További aktív témák...