Sziasztok!

Laravel-ben szeretnék egy kereső mezőt létrehozni, amibe a beírt szöveg(részlet)nek megfelelően, visszakapok egy tömböt.

Tehát mondjuk, ha beírom, hogy kan, akkor adja vissza az összes 'kan' nemű kutyát, meg azokat is amik pl. Kaskantyú-n vannak.

Hogy szokás egy ilyen keresést kivitelezni?

Az adatbázisok közötti reláció be van állítva és le tudom hívni az összes egymáshoz tartozó információt, de nem tudom, hogy hogyan kereshetnék a hozzátartozó adatbázisban. A kutyák táblába a pl. a megye táblára csak a megye azonosítója szerepel

Eddig ilyesmivel próbálkoztam, de mivel nincsen county mező a kutya táblámon ezért ez így nem működik.

$dogs = Dog::with('county')
->where('gender', 'LIKE', "%$search%")
->orWhere('county', 'LIKE', "%$search%")
->paginate(8);

Feltételezem, hogy valami JOIN kéne nekem, de egyszerűen most nem tudom megérteni annak a működését.

Irányba tudna valaki állítani?

Így hirtelen azt hiszem, hogy kereshetnék külön külön is a táblákban, de végeredménybe én azt szeretném, hogy minden egy tömbben legyen tovább adta a View-nak.

Let's begin, de gozaimasu!

Nem ismerem a laravel-t, de a with opció mondja meg (legalábbis yii-ben így van), hogy mihez legyen kapcsolva és a model-ben írod le a kapcsolatot (inner, left, right stb.).

De egy egyszerű példa sql-ben.

table_a :
id : number
data: varchar2

table_b:
table_a_id : number
data: varchar2

select a.*
from table_a a
left join table_b b
on a.id = b.table_a_id
where a.data like '%valami%' or b.data like '%valami%'

Összekötöd az a táblát a b táblával, ahol az a.id értéke megegyezik a b.table_a_id értékével. A feltétel részben pedig az a.data és a b.data mezőkre írsz like-ot. Az eredményhalmazban pedig kilistázza az összeset az a táblából.

Kereshetsz külön is, de akkor kell egy union all.

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Valami összejött, de felvetett jó pár kérdést.

Elsőnek engem a sorrendiség zavart meg. Mivel a kutyák táblám tartalmaz minden infót vagy inkább kapcsolódó 'id'-t, ezért azt hittem, hogy a kutya táblához kell hozzákötni a többit, de most a 'users' táblához kötöttem a 'dogs' táblát, méghozzá a 'user.id', '=', 'dogs.user_id'.

Meg is kapom szépen a keresett infókat. Igen ám, de van még 'county, settlements,dog_breeds' táblám is, ezeket már nem tudom, így hozzákötni a 'users' táblámhoz. Szóval nem működhet ez valahogy visszafelé is?

Mindenesetre még túrom a Laravel doc.-ot, mert 2 dolog is feltűnt. A fenti DB queryt használva másképp kapom meg az adatokat, mint a Laraveles Eloquent-tel.

Eloquenttel a kapott eredmény:

Dog:with('county', 'settlement')->get(); eredménye:

id:
breed:
county_id:
settlement_id (és folytatásként külön tömbben a 'county', majd megint különben a 'settlement'
id:
county:
.
.
.

Míg a DB query join után egyben volt minden, tehát tényleg, mintha egy táblából olvastam ki volna mindent.

Let's begin, de gozaimasu!

A kutya táblához is lehet kötni a usereket, attól függ mi a cél. A kutya tábla eredményhalmaza, vagy a users tábla.

A with szerintem biztos használható több táblára is. Azt már a model reláció résznél kell megadni, yii-ben ez a through kulcsszóval megy, laravel-re is biztos van hasonló.

Szerintem a Laraveles Eloquent az össze relációt felhozza neked.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Úgy tűnik, hogy szépen elakadtam.

Félig meddig sikerült valamit összehoznom, viszont azzal együtt jött vmi tábla ütközés, mert fals értékek jelentek meg. Itt az első postomban leírtam, hogy mi volt az ami látszólagosan működött.

Amúgy a model relációim működnek, szóval le tudom kérdezni a kutya fajtát vagy a hozzátartozó települést egy egyszerű '$dog->dog_breed'-el, ill. a kutyák táblában is tudok keresni 'LIKE'-al, de ilyen keresést nem tudok kiterjeszteni a hozzátartozó táblákra.

Most nekifutok még egyszer joinnak, hátha frissebb fejjel más lesz az eredmény.

És közben most kaptam egy tippet, hogy scope query-t is nézzem meg, ill. az eager loadingot.

Let's begin, de gozaimasu!

Azt hiszem sikerült az eredeti elképzelésem.

'whereHas' kellett neki:

$dogs = Dog::where('gender', '=', "$search")
->orWhereHas('dogBreed', function ($query) use ($search)
{
$query->where('dog_breed', 'LIKE', "%$search%");
})
->orWhereHas('county', function ($query) use ($search)
{
$query->where('county', 'LIKE', "%$search%");
})
->orWhereHas('settlement', function ($query) use ($search)
{
$query->where('settlement', 'LIKE', "%$search%");
})
->get();

Nem hittem volna, hogy ennyit fogok elidőzni már az elején.

Let's begin, de gozaimasu!

A dokumentáció olvasás bizony hasznos tud lenni.

Én kérek elnézést!

Parancsolj:

(SQL:
select count(*) as aggregate from `dogs` where `gender` = szuka
or
(select count(*) from `dog_breeds` where `dogs`.`dog_breed_id` = `dog_breeds`.`id` and `dog_breed` LIKE %szuka%) >= 1
or
(select count(*) from `counties` where `dogs`.`county_id` = `counties`.`id` and `county` LIKE %szuka%) >= 1
or
(select count(*) from `settlements` where `dogs`.`settlement_id` = `settlements`.`id` and `settlement` LIKE %szuka%) >= 1
)

martonx: De még mennyire, hogy hasznos. Noha a Laravel dokumentációban nem túl erős, ezt párosítva a tapasztalatlanságommal, sokszor, ha előttem van vmi, akkor sem vagyok benne biztos, hogy az az amit keresek, lásd a fenti helyzetet. Eloquent query alatt ez is ott van, de egyszerűen túlmentem rajta, amíg nem találtam egy könnyen érthető példát a neten.
Ebben szerencsére jók, a hypenak köszönhetően nagyon sok talált van, csak tudjam, hogy mit is akarok pontosan.

Let's begin, de gozaimasu!

Sziasztok.

Előzetesben most kezdek ismerkedni a mysql-el. Olyan kérdésem volna, hogy Access van összekötve odbc-n keresztül mysql táblákkal akkor az access formon amin keresztül felviszem az adatokat hogyan tudok törölni? elvileg az éppen a formban levő rekordot szeretném mindig törölni. Ilyen gombszerű törlésre gondoltam, megnyomom és töröl.

más:
Mysql-nél össze kell kötni a táblákat vagy elég az accessban? Ha igen akkor hogy lehet?

[ Szerkesztve ]

A kisebbség is számíít, teszkó.

Szvsz ez nem igazán mysql-es kérdés, inkább Access-es kérdés. És igen, illene már mysql-ben összekötni a táblákat.

Én kérek elnézést!

ok értem, de az összekötésről tud valaki infót adni. Mysql-ben gyak. van egy webes felületem, na itt hogy lehet összekötni a táblákat?

A kisebbség is számíít, teszkó.

Ha összekötés alatt a külső kulcsokat érted akkor:
ALTER TABLE amihez_kulcsot_adsz
ADD CONSTRAINT fk_kulso_kulcs_neve
ADD FOREIGN KEY (kulso_id)
REFERENCES masik_tabla(id);

Remélem nem rontottam el, fejből írtam.

but without you, my life is incomplete, my days are absolutely gray

aham vmi ilyesmire gondoltam. És ha összekötöm azt elég egyszer megcsinálni ugye?

A kisebbség is számíít, teszkó.

persze

Én kérek elnézést!

A mysql user passnak milyen feltételeknek kell eleget tennie?

ilyenkor hogy tudom megadni a kapcsolat típusát értem ezalatt az 1:1 vagy 1:T esetleg határozatlan?
és az integritás megőrzést is be kéne kapcsolni néhol.

A kisebbség is számíít, teszkó.

Számomra egy kicsit furcsa helyzet előtt állok.
Van egy webalkalmazásom, aminek a fejlesztése közben MySQL-t és InnoDB-t használtam. A tábláim többségében van idegen kulcs, ami(k) segítségével van meghatározva az egyes táblák közti reláció.
Ezt az adatbázist szőröstül-bőröstül exportáltam, majd importáltam egy MyISAM motorral működő MySQL-be és szinte minden ugyan úgy működik.
Nem értem, hogy miért és hogyan. A MyISAM nem támogatja az idegen kulcsokat, az egymáshoz fűződő adatokat mégis le tudom kérni.
Kicsit tartok attól, hogy olyan a helyzet, mint matekban, amikor rossz számolás után jó eredmény jön ki,...legalább 2-szer hibáztam.

A dolog egyébként úgy tűnt fel, hogy kettő if-em hibásan fut le:

if (Auth::user()->admin === 1)
{

return Redirect::route('admin.index');

} else...

, illetve

if ($id === Auth::id() or Auth::user()->admin === 1)

Mindkettő esetében az admin rész mindig false.

Kaphatnék ebben egy kis felvilágosítást?

Let's begin, de gozaimasu!

Attól, hogy valamin van idegen kulcs vagy sem nem befolyásol egy lekérdezés eredményt. A join-ok, exist feltételekre nincs hatással.
Az idegen kulcs a join-t gyorsítja és megszorításokat tesz, insert, delete, update, truncate stb utasításokkor.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Na de nem pont az a lényege az ORM használatának, hogy előredefiniált táblarelációk vannak az idegen kulcsokon keresztül? Máskülönben hogyan határozódik meg a reláció?

Ezt félretéve nagyjából értem amit mondasz, amennyiben a úgy érthetem, hogy a relációk az alkalmazáson belül kerülnek beállításra és az InnoDB motornak pedig sebességi előnye lesz, ha megadjuk, hogy melyek az idegen kulcsok egy másik táblából.

Nem akarok hülyeséget kérdezni, nem hogy írni, csak azt hittem, hogy ha nincsen meghatározva az idegen kulcs, akkor az ORM használatát is bukom.

Let's begin, de gozaimasu!

"Na de nem pont az a lényege az ORM használatának, hogy előredefiniált táblarelációk vannak az idegen kulcsokon keresztül? Máskülönben hogyan határozódik meg a reláció?"
De pont az a lényege, megmondod a model relációban, hogyan kapcsolódik össze a 2 model (tábla) és az alapján állítja össze az eredményhalmazt neked.

Ha használ idegen kucsot akkor gyorsabb, nem tudom mysql alatt van-e végrehajtási terv, de ott észre lehet venni, hogy hash join alapján a select cost-ja nagyon kicsi lesz. Míg reláció nélkül lassabb a select.

A legjobban úgy tudod ezt kideríteni, hogy megnézed a framework, hogyan használja fel ezeket a relációkat, ha bemegy a db-be és bekérdezi a constraint-eket, akkor bukod, ha nem kérdezi meg, csak használja, amit a user megadott neki akkor nem.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Ez így már világosabb akkor, köszi!

Viszont az továbbra is rejtély, hogy miért nem működik az admin ellenőrzés, máshol is van még egy-egy ilyen if, igaz nem a controllerben, de hasonló a funkció és hibátlanul működik:

@if($dog->user_id === Auth::id())

Ránézésre a host és a vagrant box-om közti különbség a MySQL verziója 5.1-5.5 és tároló motor, de hoston az a két if nem igazán működik úgy, ahogy kéne.

Let's begin, de gozaimasu!

Sziasztok!

Elég noob vagyok a mysql-hez, szóval ne üssetek plz. Van egy (nyilván) primitív problémám amit nem tudok megoldani. Van 2 táblám, nevezzünk tabla1-nek és tabla2-nek. A tabla1 2 oszlopból áll, egy id és egy nev mezőből. A tabla2 3 oszlopos, amiből most 2 lényeges, legyen id1 és id2. Azt szeretném megoldani, hogy a tabla1 azon sorait lekérdezni, amik a tabla2 id2-ben NEM szerepel, ha az id1 = 'xy'.

Előre is köszönöm a segítségeteket!

Citizen Diopapa / Commander Diopapa "SC csomag olyan, mint a barackfa, unokáidnak veszed - .tnm / De pálinkát nemlehet főzni belűle - *SkyS1gn"

Ezt olvastam már, köszönöm, csak én összemostam a két dolgot.

A Framework külön dolgozik a MySql szervertől.

Foreing_key megadása nélkül is működnek a relációk, persze jelen esetben csak akkor automatikus, ha a megfelelő elnevezéséket használunk.

Továbbá a MyIsam is tudja értelmezni a FK-t, csak a hozzá tartozó megkötéseket nem. Így hiába törlök egy felhasználót, a kutyák gyerek táblán, nem történik semmi változás.
Tehát törléskor külön kéne még egy query a kutya táblában a user_id-re és úgy lehetne törölni a hozzá tartozó kutyákat is.

És igaz mi igaz, elég pontatlanul is fogalmaztam. Ebből a szempontból az ORM egy hadik játékos, a lekérdezéseknek csak közvetve van köze a beállított relációkhoz.

Tehát esetemben most, azért kell InnoDB és FK, hogy könnyebb módon törölhessek egy felhasználót kutyástul. Továbbá nem egy eget rengető dolog, de így a megkötések révén, programhiba/akármi esetén sem, tud mondjuk rossz megyéhez kerülni egy település.

Persze az eredeti hibát nem sikerült még kijavítanom, de legalább tudom, hogy valószínűleg az ORM-el kapcsolatos a jelenség és nem konkrétan az adatbázissal van baj.

[ Szerkesztve ]

Let's begin, de gozaimasu!

Senki?

Citizen Diopapa / Commander Diopapa "SC csomag olyan, mint a barackfa, unokáidnak veszed - .tnm / De pálinkát nemlehet főzni belűle - *SkyS1gn"

NOT IN

vagy

LEFT JOIN és IS NULL

Nagyon köszönöm a PM-ben nyújtott segítséged is!

Citizen Diopapa / Commander Diopapa "SC csomag olyan, mint a barackfa, unokáidnak veszed - .tnm / De pálinkát nemlehet főzni belűle - *SkyS1gn"

Sziasztok!

Lenne egy gyakorló feladatom, de kicsit akadozik a megfejtése.
Adott egy rendelések xml fájl, és ennek megfelelően kéne relációs táblákat létrehozni MySQL-ben normalizálva és minimalizálva a redundanciát.

Az alap táblákig nagyjából világos a helyzet:

Customers
-id
-name
-email
-telephone

Products
-id
-item_code
-item_cc_code
-item_name
-vtsz
-unit
-unit_price_netto

Gondolom, célszerű külön a Shipping és Billing táblákat is létrehozni, pl:

Shipping
-id
-customer_id
-name
-country
-postcode
-city
-street
-telephone

Bár ez esetben a HU és a Budapest, már valószínűleg többször szerepelne, szóval esetleg azokat lehetne egy Cities táblába menteni
-id
-country
-post_code
-city

és a shippingn táblába a country helyett city_id lenne.

Ez eddig nagyjából jó?

Let's begin, de gozaimasu!

Sziasztok,
Deadlockot hogyan lehet lekérdezni/feloldani mysql alatt?

Sziasztok!

Keresnék kimondottan MySql admint, aki windows szerveren futtatott mysql admin feladatát ellátná időnként. Ha bárkit érdekel, privátban keressetek!

Én kérek elnézést!

egyik webshopom kezd kicsit nagyra hízni ... normális működéssel nincs is gond azt sikerült optimalizálnom...

kivéve a 3 óránkénti termék updatet (még itt sem a termékek updatejével van gond ...) ugye minden esetben csak azokhoz a termékekhez nyúlok amik
- adatai változtak (rendelési státuszok)
- új termékek
- eltűnt termékek

majd mivel ez a kb 70.000 termék 8.000 kategóriában van és minden kategóriában tudnom kell (weboldalon megjelenik) hány termék van így a kategória fában a levelektől a gyökér irányába bejárom a fákat szintenként ...

a gond itt van ugyanis a 8000 lekérdezés baromi lassan fut le valamiért pedig sima queryk ...

"UPDATE webshop__category SET productnumber = 0 WHERE id = 10370"

mit lehetne tenni? A térjek át postgresre jó válasz ... de postgresen ez a webshop nem fut csak ennek a 2.0-ás változata (az már megy mysql és postgres alatt is) és az ügyfél nem akarja kifizetni az átállás költségét ... anno 500 kategória és 10.000 termék volt picit hízott

Nekem is volt hasonló gondom, hogy két baromi nagy adathalmazban kellett a változásokat figyelni.
Egy ideig járható volt ez a favágó/vasutas módszer, hogy ide oda ellenőrizek aztán egy pont után... slow query...
Én úgy oldottam meg, hogy a kivánt csoportokat lequery-ztem és csináltam egy különbséget és csak azt toltam fel. Illetve töröltem / updateltem.
Lehet, hogy a fáradtság teszi, de nem értem pontosan, hogy melyik a lassú rész. Mit csinálsz ott pontosan?

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

a folyamat az alábbi

-- termék lista frissítés --
1.) letöltöm a csvt (20-30.000 sor pl az egy beszállító adatbázisa)
2.) soronként md5 hasht generálok
2.a.) ha a sor md5 hash-ét megtalálom a dbben (SELECT) akkor nem csinálok semmit mert az a sor az adatokkal már szerepel
2.b.) ha a sor md5 hash nem szerepel az adatbázisba akkor lekérem a cikkszám szerint a terméket
2.b.I.) ha megvan a termék cikkszám szerint (UPDATE) és az md5 hasht is frissítem
2.b.II.) ha nincs meg a termék (INSERT)
3.) az összegyűjtött md5 hash-en kívüli termékeket inaktiválom (mert a lista mindig tartalmazza az összes elérhető terméket (de néha ki be kerülnek termékek + seo szempontból a nem kapható termék is google találat ráadásul igen elöl ... ehhez meg az ügyfél tud megadni alternatív termékeket melyre az ügyfél át tud ugrani...

-- kategória frissítés --- (az ügyfél kérése, hogy minden kategóriában megjelenjen, hogy hány termék van és csak az a kategória legyen amiben van termék)
4.) lekérdezem az összes kategóriát ami egyik kategóriának se a szülője (azaz a leveleket) (SELECT)
5.) végig járom a leveleket majd a szülőiket berakom a tömbbe ha még nincsenek ha vannak akkor összeadom az adott kategória elem számát a szülőjével ... azaz egy fabejárást csinálok, és minden kategóriát csak egyszer frissítek mikor már kiszámoltam a kategóriák elemszámait ...
6.) egyesével lefrissítem a kategóriák elemszámát... Ez a lassú pedigg a fenti query fut le ... most annyit raktam még bele, hogy

UPDATE webshop__category
SET productnumber = ".$numCount."
WHERE id = 10370
AND productnumber != ".$numCount

Így csak akkor updatel amikor valóban változott a product number ... Ma kiderül mennyivel jobb a helyzet ...

[ Szerkesztve ]

tudtommal a mysql eleve csak akkor update-el VALÓBAN ha más értéket adsz be, ezt én a NOW() problémánál vettem észre, ha az X mező 1, akkor ha updatelem 1-re, nem változik a NOW() értéke sem

egyébként szerintem símán nem indexelt a category number

Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |

úgy néz ki, hogy a mysql erre nem figyel ... vagy az ellenőrzés több erőforrást eszik mint ha a where feltételnél van ilyen feltétel szabva ...
- előtte 2-es loadot csinált ez a script a meglévő cuccok mellett
- most meg 0.5 fölé nem ment ...

remélem így is marad :9 egyenlőre nem iszunk előre rá remélem így is marad: )

A mysql configjára van ráhatásod? Be van állítva rendesen? Mivel a default mysql beállítások igazán, tragikusan, csapnivalóak.

Én kérek elnézést!

Mert ha jól sejtem a "productnumber" egy indexelt oszlop ami fel tudja gyorsítani a folyamatot.

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

az id meg primary key ....

#martonx: van rálátásom és tudnék matatni is de jelenleg nem vagyok akkora szerver guru, hogy elkezdjek mókolni vele illetve van a szerveren 1-2 igen fontos és komoly projekt ami ha leáll engem elföldelnek

Igaziból azzal, hogy több memóriát engedsz a mysql-nek használni, meg beállítod normálisra a log írást, és nem folytod le a maximális kapcsolatok számát szvsz esélytelen elrontani
InnoDB vagy MyIsam motort használnak a tábláid?

Én kérek elnézést!

Sziasztok!

Adott ez a feladat
Tudom, hogy nagyon alap, de van pár része, ami nem sikerül pl. az a rész ahol az irányítószámot kell ellenőrizni nálam így néz ki, de mégis elfogad 3 jegyű számot is.

irsz dec(4) not null check(1001 <= irsz <= 9999),

egyik csoporttársam próbálta between-nel is, de úgy sem ok.
valaki tudna segíteni?

Szerintem a dec(4) elég, mert a check funkció nincs tökéletesen implementálva a mysqlbe
"The CHECK clause is parsed but ignored by all storage engines" [link]
viszont ez lenne a helyes
CONSTRAINT chk_irsz CHECK (irsz BETWEEN 1001 AND 9999)
(de ne query browserből próbáld mert ott még a not null-as kivételt is meg lehet kerülni)

Ha van más megoldás tedd közzé kíváncsi vagyok

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

Köszi!

A between-nel mégis csak jó lett

Sziasztok,

mit rontok el?

mysql> SELECT strPath from tblPath where strPath = '\\\\nas\\usb';
+-----------+
| strPath |
+-----------+
| \\nas\usb |
+-----------+
1 row in set (0.00 sec)

mysql> SELECT strPath from tblPath where strPath like '\\\\nas\\usb'
Empty set (0.00 sec)

Értelmezésem szerint a 2. select is azonos eredményre kellene, hogy jusson, mint az első.

A 4 darab \-ből LIKE-nál 1 darab \ lesz, mert duplán escape-el.

[link]

Because MySQL uses C escape syntax in strings (for example, “\n” to represent a newline character), you must double any “\” that you use in LIKE strings. For example, to search for “\n”, specify it as “\\n”. To search for “\”, specify it as “\\\\”; this is because the backslashes are stripped once by the parser and again when the pattern match is made, leaving a single backslash to be matched against.

Sziasztok!

Van valalkinek tapasztalata, hogy a "mysqloptimize" körülbelül mennyi ideig fut egy körülbelül 51-52.000.000 soros táblán? Nyilván környezettől is függ. Nálam lassan 12 órája fut és nem tudom, hogy meddig várjak vele, vagy van-e valamilyen sztenderd ezzel kapcsolatban. Köszi!

Megválaszolva: az egész gép lehalt reggel 8, 9 körül. Úgyhogy fasza volt MYSQL-t rendesen leállítani nem tudtam, nyomtam neki egy reboot-ot; induláskor MYSQL nem tud elindulni valami innodb-s file lockolási problémja van. Klassz a dolog.

Valahogy volt egy ilyen érzésem, de mivel ilyet nem csináltam még, nem akartam bedobni.