Értem, köszönöm. Én is úgy néztem, hogy ezzel lehet a baj.
És ha php-ben írom a lekérdezést, nem tudom úgy varázsolni az adatokat, hogy azzal kezelje?

utf8mb4_bin-t használva fulltext-et használva jó lesz az.
Case insensitive és csak a kívánt találatot adja.

http://sb-soft.hu - "A" számlázó

Itt a típusra gondolsz? Varchar amit most használok, ahelyett kellene sima text-nek lennie?

E: Na igen így jó, viszont ci kellene, hogy kis és nagybetűt viszont egybe vegye

[ Szerkesztve ]

Nekem egybe vette. NÉV, NEV volt a tartalom és név-re kerestem match against-el.

http://sb-soft.hu - "A" számlázó

Üdv!
Mariadb 10.9.3-nál másnál is belassult a join utáni like '%keresés%' ?
Van egy eléggé sokrétű lekérdezés. Eddig simán ment max 0.5mp volt. Ez a legutolsó update során felment 4.5mp-re.
Így áttértem a match against-re beállítva az egy karakteres limitet.
Viszont ez ugyen csak a szó elejétől keres, és az ügyfelek eléggé hogy is mondjam.. nem tetszik nekik.
Szóval másnál is előfordult?

http://sb-soft.hu - "A" számlázó

Sziasztok!

EGy kicsit speciálisabb kérdéssel jönnék. Adott sql server 2019. Csomagot kellene készítenem SSDT segítségével. Visual studioban a send mail nem opció, mert ahhoz su jog kellene. Így marad a Script task, ahol a system.net.mail segítségével tudnék levelet küldeni.

Ami a gondom, hogy igyekeznék hatékony kódot írni. A feladat annyi lenne, hogy van egy leválogatás. Egy hibalista az érintetteknek. Egy felhasználó egy rekordon szerepel és neki kellene levelet küldeni. Erre kurzort gondolnám a leghatékonyabbnak. De nem tudom miképp rakjam össze. Execute SQL task-ban a kurzort meg tudnám írni, de miképp "hívom meg" a script task-ban található emailküldést?

Remélem sikerült röviden összefoglalni a dilemmám

Mess with the best / Die like the rest

Én se sqlben csinálnám....de gugli 3mp 2. találat [link]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Az sp_send_mail-hez su jog kell, ami tiltott. Ezért írtam, hogy system.net.mail lehet a megoldás.

@martonx: agent job. Leválogat egy listát, amit ki kell küldeni az érintetteknek. Nem elég csak kimenteni, mert elfelejtik. Mire gondolnál alternatívaként.

Mess with the best / Die like the rest

Oh, így értem mire utaltok. Kényelmesnek tűnt ez a megoldás, H már van a Visual Studioban erre lehetőség, de akkor keresünk külső megoldást.

Fontos a hatékonyság.

Köszönöm!

Mess with the best / Die like the rest

Első mongodb sématervezésemmel el is akadtam szépen, ahogy illik, ebben kérném a segítségeteket.

Van a két képen szereplő entitásom, valamint egy Garage, amiben PlayerCard-ok vannak. Login után be kell töltenem a garaget. Na most hogy lenne ez gyorsabb?

- Garage <= List<String>(PlayerCardok ID-je)
- PlayerCard <= (String)Card ID-je

vagy

- Garage <= List<PlayerCard>
- PlayerCard <= Card

Első esetben ugye PlayerCardCount * 2 lekérdezéssel tudom kiolvasni a garaget.
Másodikban meg garageId alapján ott van izibe.
De ha azt mondom, hogy egy Cardból 1 playernek lehet több példánya is, amik természetesen PlayerCard szintjén egyediek, de ezt még meg kell szorozni a playerek számával is. Nem tudom ez mennyire elnézett/nem javasolt mongoban. Nekem annyira nem tetszik.

Egybe tenni azért nem tudom a cardokat, mert a Card-on vannak az alap/kezdőértékek, a PlayerCardban meg a playerenként és PlayerCard-onként eltérő módosító értékek. A fronton az ezekből kalkulált érték fog megjelenni.
Pl: topSpeed * tuningEngine * ENGINE_MULTIPLIER

Meg ez utóbbi esetben, ahol nested entitásként tárolok mindent, ha esetleg változik vmelyik Card vmelyik értéke, akkor mit csinálok? Végigmegyek mindenkinek minden playerCardján, h ha olyan card van benne, akkor updatelje?
Az első esetben ilyenkor beupdatelem a cards táblában levő Cardot, és annyi, onnantól már az új értékkel kerül majd mindenkihez a következő lekérdezéskor.

Így leírva sztem maradnék az első verziónál. Szerintetek?
Még talán annyi, h Card lesz kezdésnek vagy 1-2000, player meg 2 biztosan, én a fiammal, de ki tudja mi lesz? Lehet leszünk vagy ezeren

[ Szerkesztve ]

Sziasztok!

Újabb SQL szerveres kérdés. Elgondolkodtam egy dolgon. Nálunk van egy kezdeményezés, hogy a meglévő jobokat ültessük át SSIS package-ekre. Ezzel nem is lenne gond. Hisz copy-paste a nagy része. De!

Ha volt valami változás a forrásban vagy szűrést kell bővíteni, akkor az msdb.dbo.sysjobsteps hamar kidobta, hogy hol kell a változásokat lekövetni.
Az SSIS-szel viszont ez megszűnik.

Van értelme annak, hogy a lekérdezéseket kimentem tárolt eljárásokba és csak az import-exportokat hagyom meg az SSIS számára? (Bevallom nem teszteltem még, de lehet holnap megpróbálok 2-3 jobot csinálni és megnézni, hogy mekkora a különbség.)

Mess with the best / Die like the rest

SSIS-ben szépen vizuálisan össze lehet kattintgatni a betöltő job-okat, és a ha a fejlesztőkörnyezetből futtatod, akkor látszik is, hogy melyik lépésben hol tart. Persze ha nem kell bonyolult feldolgozás a betöltéshez, akkor vsz az SSIS ágyúval verébre szituáció.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Én a T-SQL megoldást jobban csíptem. Nem voltak túlbonyolított jobok. Kisebb ellenőrző riportok, töltések. Csak most kitalálták az anyacégnél, hogy mindent át kell ültetni.
Az okot nem tudom. De mivel akad néha valami módosítás, ami igényli, hogy hozzányúljuk meglévő folyamatokhoz. Eleve nem túl gyors és viszonylag sűrűn omlik össze a Visual Studio. Félek, hogy ez durván lassítani fog. Ezért gondoltam ,hogy a tárolt eljárás kiskapu lehetne, hogy gyorsan szűrhessek. Anno Excelbe elkezdtük adminisztrálni, hogy melyik job mit tartalmaz, de hamar hamvába halt, hogy nem cska ketten csináltuk. Vagy mindenkinek kellene vagy senkinek.

Mess with the best / Die like the rest

Nem kell Visual Studioban futtatni a jobot. Ha egyszer kész van és mukodik, akkor csak feltoltod az SSIS szerverbe és ott fut, user felugyelet nélkul.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Udv! Van valamilyen kulcskesz megoldas ketiranyu DB szinkronizaciohoz vagy ki kell fejlesztenunk egyet?
Utobbira keszulunk, de megprobalok rakeresni/rakerdezni az elobbire.

Tobb gepunk (markolo, epitoipari gepek stb) naploz bizonyos adatokat es kuldi el a kozponti szervernek. Viszont most jon be az a forgatokonyv hogy nem mindig van internet egy bizonyos gepen, illetve bizonyos gep nem a szerverrel hanem csak a szomszedos geppel van kapcsolatban. Igy szinkronizalni kell az adatokat a szerverrel es egymas kozott is.

PostgreSQL-t hasznalunk es erdeklodom hogy valaki talakozott-e mar ezzel a problemaval es akar fizetos megoldast talaltatok.

Ha nincs mas, akkor a reconciler pattern-t fogjuk kiprobalni: [link]

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

biztos, hogy ezt akarod? nekem nagyon rossz érzésem van a kérdéseddel kapcsolatban, az ilyen megoldásoknak szinte biztosan nagy kavarodás lesz a vége.
mondjuk jó lenne tudni a probléma részleteit is, hogy pl. mennyi adat keletkezik, mennyi idő alatt kell feldolgozni és van-e olyan más gépen keletkezett adat, amit vissza kell tölteni a gépekbe.

szerintem naplózásra a syslog való, és annak van olyan verziója, ami kezeli az általad írt problémákat is. Balabit vagy Balasys vagy hogy hívják őket a héten, fejlesztette, pénzes.

táblák szinkronizálására vannak postgreses cuccok, én nem kezdenék velük Slony és társai.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Egyetertek - valami rendes logolo framework kellene, nem kozvetlenul adatbazisba irogatni a kliensekbol.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Koszi a valaszt!
A gepek rendkivul pontos helyzete van naplozva es abbol terkep felepitve, igy nem igazan van mas valasztasunk mint szinkronizalni az adatokat. Tudom hogy nagy szivas az ilyen , szerencsere van egy DB expert is velunk, hat majd meglassuk.

Sok adat keletkezik es a leheto leggyorsabban kell atkuldeni, hogy a gepek lassak a tobbi poziciojat es az irodaban ulo menedzser is

Elertuk azt a pontot amikor elkezdtuk hasznalni a syslog-ot is

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Szerintem sima HTTP POST/REST API sokkal jobb lenne erre a celra, mint adatbazis - vagy alternativakepp valami logolo framework, ahogy bambano is irta...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Jah, de a postgresql tetejeben PostGIS-t hasznalunk foldrajzi adatok tarolasara, ahol SQL lekerdezessel bizonyos muveletekel vegezhetunk egy terbeli pont, utvonal vagy poligon felhasznalasaval. Ezt nehez lenne sima naplozassal megcsinalni.

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Gondolom a kliensek nem kérdeznek le, csak feltöltenek - innentől fogva meg mindegy...

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

én még nem láttam olyat, hogy postgres kész applikációval úgy működjön, ahogy te leírtad.
nevezzük nevén a gyereket: gyári multimaster postgres tudtommal nincs.
tehát vagy csináltok valami cuccot, amitől multimaster lesz a postgres, és komolyan hiszek benne, hogy nem fogjátok tudni normális költséggel normális idő alatt megoldani,
vagy megváltoztatjátok az adatszerkezetet úgy, hogy ne kelljen multimastert csinálni, mindig pontosan egy irányba menjenek az adatok.

az külön necces, hogy egyes gépen hol van net, hol nincs, ahelyett, hogy ilyenkor másik gépen keresztül küldi az adatot, inkább oldjátok meg, hogy legyen net. mibe se kerülne egy építési területre saját wifit telepíteni...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ez inkább hálózatos, 5G meg IoT buzzwordökkel leírható témakör, nem DB oldali probléma.

Hello IT! Have you tried turning it off and on again?

"inkább oldjátok meg, hogy legyen net. mibe se kerülne egy építési területre saját wifit telepíteni..."

Minden gep 4G modemmel rendelkezik azonban bizonyos orszagok, bizonyos teruletein nincs net, pl hegyekben, kint a tajgan, oserdoben stb.
Pl Alpokban a ho'tolo'k allomasanal van internet, de amikor kimennek, akkor vannak foltok ahol total nincs net es nem fognak telepitgetni nagy tavolsagu wifi allomasokat.

"ne kelljen multimastert csinálni, mindig pontosan egy irányba menjenek az adatok "
jah, egyetertek, 1 master eseten sokkal konnyebb lenne az elet.

@tobbieknek: koszi az eszreveteleket.

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Akkor mindenki alapesetben a saját helyi DBjébe írja a koordinátáit, adatait, aztán föléje tesztek egy Java/C# alkalmazást, ami a neten kommunikál a központi DBvel, és ha van net, akkor beszúrja a még fel nem töltött adatokat, majd letölti a többiekét egy másik lokális táblába. *
Ha sikerült a központi szerverről letöltenie a saját koordinátáit, akkor az ahhoz az időbélyeghez tartozó rekordokat meg törli a lokális temp táblából.

Arra nyilván figyelni kell, hogy ne legyen ID ütközés: adatok központba feltöltésénél NE a lokális szerver IDját/szekvenciáját használjátok, hanem kérjetek a központi DBből újat, különbön összeütköznének a különböző eszközökről jövő adatok.

Térkép helyi megjelenítésénél meg gondolom a helyi, még fel nem töltött adatokat tartalmazó tábla ÉS a központi szerverről leszinkronizált adatokat tartalmazó táblák unióját kell majd megjelenítened.

Nyilván ha éppen nincs net a hótolón, akkor a többiek által takarított felületből csak annyit tud megjeleníteni, amennyit az előző netkapcsolat idején sikerült letöltenie.
Meg az iroda is csak akkor fog valós idejű adatokat látni, ha éppen van net, kiesett időszakot csak utólag, ha megint net közelbe ér a munkagép.

*: Elvileg DB oldalon is fel lehet konfigurálni DB linkeket, interfészeket, és a távoli szerveren lévő táblákat is meg tudja címezni, így akár (percenként) időzített jobokkal is meg lehetne csinálni az adatszinkronizációt, de jártam már úgy Oracle alatt, hogy hálózati hiba miatt leszakadt a DBlink, aztán egyből invalid lett miatta a package a táblanév@DBlink hivatkozás nem létezik címszóval.
Aztán lehetett rugdosni az üzemeltetőket, hogy nyomjon már egy recompile-t az élesen, mert nekem nincs jogom hozzá.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Udv! Van valamilyen kulcskesz megoldas ketiranyu DB szinkronizaciohoz vagy ki kell fejlesztenunk egyet?

Vannak rá szoftverek, de egyiket sem mondanám "kulcsrakésznek", a konfigurációhoz muszáj kicsit elmélyedni a témában:

[link]

[ Szerkesztve ]

Forget your troubles, c'mon get happy

Koszi mindenkinek, osszegereblyezem az infokat.

HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian

Üdv!
mariadb 10.9.3 re frissítve a 10.5.8 ról nagyon lelassult a többszörös join lekérdezés.
Másnál nem fordult elő ez a hiba? -=A lekérdezés 349.2095 másodpercig tartott=-
Soknak érzem

Tábla méretek: cikktábla: 5930 rekord
Tétel tábla: 36715 rekord
Készletfej tábla: 9599 rekord
Szerintem nem sok.
Lekérdezés:
SELECT t5.cikk_id,t4.menny,t4.cikkszam,t4.megnevezes from cikk as t5
LEFT JOIN
(
SELECT tetel.cikk_id,SUM(IF(tetel.tetel_id < COALESCE(t2.setid, 0),0,IF(tetel.mozgasnem < 200, tetel.menny, 0 - tetel.menny))) AS menny ,cikk.cikkszam , cikk.megnevezes
FROM keszletfej,cikk,tetel
LEFT JOIN
(SELECT cikk_id, MAX(tetel_id) AS setid
    FROM tetel
    WHERE mozgasnem = 100
    GROUP BY cikk_id
) AS t2
ON (tetel.cikk_id = t2.cikk_id)
WHERE
 keszletfej.teljesites<='2022-11-05'
 AND cikk.cikk_id=tetel.cikk_id
 AND keszletfej.keszletfej_id=tetel.keszletfej_id
 AND cikk.keszletre='i'
 AND cikk.status='aru'
GROUP BY tetel.cikk_id
ORDER BY tetel.cikk_id
) AS t4
ON t4.cikk_id=t5.cikk_id
WHERE t4.menny<>0

Cikk tábla ami releváns (cikk_id, cikkszam, megnevezes, keszletre, status)
Készletfej tábla (keszletfej_id, teljesites)
Tétel tábla (tetel_id, keszletfej_id, cikk_id, menny, mozgasnem)
Mozgásnem: Ha 200 alatt van akkor beszerzés ha 200 felett akkor értékesítés ha 100 akkor nyitó azaz akkor onnantól annyi a készlet.
Ezzel a lekéréssel az összes cikk készlete kellene aminek a mennyisége nagyobb mint 0.

Van ötletetek mi lehet a hiba, vagy tudtok valamit mi változott?
Már kezdek megőrülni lassan egy hónapja sz@p@k vele

Köszi!

http://sb-soft.hu - "A" számlázó

Az a sum nekem elsore tul bonyolult, vsz lehet sokkal egyszerubben is. Raadasul a joinolt rablaban nincs ertelme orderbynak, nem fetetlen tartja meg a sorrendet az eredmeny - csak akkor van annak ertelme, ha felgasznalod (pl Limit).

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Igen az order by az felesleges, de nem attól lett lassu.
A sum meg azért ilyen mert ugye a mozgásnemtől függ a sum.

http://sb-soft.hu - "A" számlázó

Generald ujra az indexeket.

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Sziasztok!

Egy valószínűleg nagyon egyszerű kérdésem lenne.
Adott 2 tábla A és B.

A tábla:
A_index (UNIQUE INTEGER)
A_name (TEXT)

B tábla:
B_index (UNIQUE INTEGER)
B_name (TEXT)
A_index (ez hivatkozik az A tábla A_index-ére)

A B táblát máshol is fel szeretném használni így az A_index-et szeretném belőle kivenni és az A táblából hivatkoznék a B táblára valahogy így:

A tábla:
A_index (UNIQUE INTEGER)
A_name (TEXT)
B_index

B tábla:
B_index (UNIQUE INTEGER)
B_name (TEXT)

A kérdésem az lenne, milyen UPDATE SET paranccsal tudnám feltölteni az A táblában a B_index oszlopot?

kb. ezt szeretném:
A
1, alma
2, korte
3, citrom
4, narancs
5, meggy

B
101, zöld, 2
102, sárga, 3
103, vörös, 5

A'
1, alma, NULL
2, korte, 101
3, citrom, 102
4, narancs, NULL
5, meggy, 103

Előre is köszönöm!

Ha jól értem, akkor neked inkább egy új, AB tábla (a_index, b_index) kéne, az kapcsolná össze az A táblában leírt objektumokat, és a B táblában leírt tulajdonságaikat.
Így tetszőleges N:M kapcsolatot le tudnál írni: egy A-hoz több B tulajdonság is tartozhatna (pl. alma lehet piros, zöld és sárga is), és B tulajdonság tartozhatna több A objektumhoz is. (alma és citrom is sárga).

Kapcsoló tábla létrehozása A-ra, B-re mutató külső kulcsokkal:
CREATE TABLE AB (
A_index INTEGER FOREIGN KEY REFERENCES A(A_index),
B_index INTEGER FOREIGN KEY REFERENCES B(B_index)
);
Törölni az AB táblából bármikor tudsz, viszont a külső kulcsok miatt sem az A-ból, sem a B-ből nem fogsz tudni olyan értéket törölni, amire az AB hivatkozik!

Feltöltése a meglévő B táblából:
INSERT INTO AB (A_index, B_index)
SELECT A_index, B_index
FROM B;

(B táblában ezután már felesleges az A_index mező, el lehet dobni:
ALTER TABLE B DROP COLUMN A_index;
Helyette mindig az AB táblát kell majd joinolni.)

Új kombó, pl. zöld alma beszúrása (ha már külön-külön létezik az alma és a zöld is):
INSERT INTO AB (A_index, B_index)
SELECT A.A_index, B.B_index
FROM A
JOIN B
ON 1=1
WHERE A.A_name = 'Alma'
AND B.B_name = 'Zöld';

Milyen színű répa van?
SELECT B.B_name
FROM A
JOIN AB
ON AB.A_index = A.A_index
JOIN B
ON B.B_index = AB.B_index
WHERE A.A_name = 'Répa';

Melyik gyümölcs sárga?
SELECT A.A_name
FROM B
JOIN AB
ON AB.B_index = B.B_index
JOIN A
ON A.A_index = AB.A_index
WHERE B.B_name = 'Sárga';

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Köszi a választ.
Ha van egy C tábla is ami hasonló a B-hez.
Azaz most néz ki a C tábla:
C_index
C_name
A_index

és innen is kiszeretném venni az A_index-et. Akkor is ez a megoldás? Azaz akkor kell az általad írt AB tábla és kell egy AC tábla?

Eléggé félremehetett a DB tervezése, ha mindenhol 1 : N reláció lett implementálva. (1 A objektumhoz tartozhat N féle B tulajdonság, ekkor kerül az A_index oszlop a B táblába.)

Igen, ha az A-C viszonyt/kapcsolatot/relációt is N : M-re akarod átalakítani, akkor oda is kell egy új kapcsolótábla, értelemszerűen A_index és C_index oszlopokkal.

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Ezek valójában 1-1 relációk, nem kell N-M-re átalakítani.
Vannak az A rekordok amik kétfélék lehetnek(b és c), az A-ban vannak azok a tulajdonságok amik a B-nek és a C-nek is közös tulajdonságai.
Tehát egy B vagy egy C az pontosan egyféle A-hoz van hozzárendelve.

Most lenne egy D tábla ami ugyancsak használná a B és C rekordokat. Itt is egy B sor vagy egy C sor pontosan egyféle D-hez kapcsolódna(vagy A-hoz).

pl. vannak az emberek(ez az A)
B - hím tulajdonságok
C - nőstény tulajdonságok

D - ez lenne most az állatok, ami szintén használná a B és C táblákat.

[ Szerkesztve ]

1:1-nél mindegy, melyik oldalon van a külső kulcs, működhet az, amit eredetileg elképzeltél.

(Még mindig nem értem az adatmodelledet, ez valami adatpiac akar lenni csillag sémával, ahol A a hub, B, C meg a különböző dimenziói? Akkor eleve A-ba kellett volna tenni a B_index és C_index oszlopokat.)

Akkor:

A-ba B_index felvétele:
ALTER TABLE A ADD COLUMN B_index INTEGER FOREIGN KEY REFERENCES B(B_index);

A.B_index mező feltöltése
MERGE INTO A
USING B
ON (A.A_index = B.A_index)
WHEN MATCHED THEN
UPDATE SET A.B_index = B.B_index;

Ha nem 1:1 volt eredetileg a kapcsolat, akkor hibaüzenettel el fog szállni!

B-ből a felesleges A_index kidobása:
ALTER TABLE B DROP COLUMN A_index;

[ Szerkesztve ]

Hello IT! Have you tried turning it off and on again?

Sziasztok!

Az alábbi két lekérdezést összelehet gyúrni egybe valahogy?

SELECT nev, count(Fizetes) AS 'hianyzasoknelkul' FROM tabla WHERE jelenlet NOT IN ('99') AND hianyzas NOT IN ('1')
group by nev;

SELECT nev, count(Fizetes) AS 'hianyzasokkal' FROM tabla WHERE jelenlet NOT IN ('99')
group by nev;

köszi

Union all, de az oszlopok neve legyen azonos, mondjuk állapot és abban az egyik fixen 1-et adjon vissza a másik meg 0-át.

Csak egyben akarod látni vagy az összegeket akarod szummázni?

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

3 oszlopot szeretnék látni

név /count 1. lekérdezés/ count 2. lekérdezés

Akkor a két select egy-egy subquery, amiket joinnal kell összekötni. De ebből 3 kell:
- lekérdezés 1 inner join lekérdezés 2, mindent visszaad, ami mindkét lekérdezésben benne van
- lekérdezés 1 left join lekérdezés 2, ahol lekérdezés 2 aznosítója null, minden, ami csak lekérdezés 1-ben szerepel
- lekérdezés 2 left join lekérdezés 1, ahol lekérdezés 1 azonosítója null, minden, ami csak lekérdezés 2-ben szerepel

Ezt a 3 lekérdezést kell union allal összerakni egy selectben, de csak akkor lesz jó, ha van minden sornak egyedi azonosítója, pl. a név mező, ha az garantáltan egyedi, vagy egy egyedi id a névhez.

"Debugging is like being the detective in a crime movie where you're also the murderer."

pár órát elb.sztam de a count case-el simán meglehetett oldani összekapcsolás nélkül.
vannak hinyosságai ennek az sql-nek, bár a favágó módszer alapján meglehet csinálni vele sokmindent

Érdekelne a véleményed... Jól jönne máshol, mert én csak 3 lekérdezésből tudtam megoldani

http://sb-soft.hu - "A" számlázó