Új hozzászólás Aktív témák
-
kezdosql
tag
Sajnos nem jo, mert alapertelmezesben minden jatekos es edzo a szezon kezdetetol a vegeig adott csapathoz tartozik, es a serulesek csak alkalmankent derulnek ki.
Arra jottem ra, hogy nem a szemelyek vagy a csapatok, hanem az esemenyek a fontosak, innen szemlelve lehet kezelni mindent, hiszen minden merkozes es atigazolas, stb. mind-mind esemeny.
Megis, akarhogy allok hozza a kapcsolatokhoz, mindig elakadok a szemelyek es csapatok kezelesenel.:-(
A buktato az, hogy egy esemenyhez tobb csapat ES sok szemely tartozik.
Egy csapathoz a szemelyek kozul egy vagy tobb edzo ES jatekosok tartoznak.
Az edzok kozul egy aktiv, vagy vezeto edzo, ha tobb van, a tobbi segededzo.
A jatekosok az elso merkozesig kerettagok, akkor derul ki, hogy kezdo, csere, tartalek vagy serult a statuszuk, ha egyik sem, akkor maradnak kerettagnak.Egy szemely egy esemenynel edzo VAGY jatekos VAGY biro/partjelzo lehet. (Kizaro vagy kapcsolat)
Az edzok es jatekosok mindig csapatokhoz tartoznak, a birok-partjelzok mindig fuggetlenek.
Egy szemelynek egy esemenyen csak egy szerepe lehet, de esemenyek soran akar az osszes lehetseges szerepe elofordulhat akar egy szezonon belul. Ezert a kesobbi elemzesnel nem szemelyre, hanem szemelyre ES szerepre kell keresni.
(Vagy a szerepet kell elsodlegesnek valasztani, es azon belul kell keresni a szemelyre ugy, hogy mas szerepe ne legyen a talalatok kozott.)Hihetetlen, hogy ket hete ragom a gittet, es akarhogy allok neki, sehogy se jon ossze a kapcsolati halo, pedig nyilvan itt van a megoldas az orrom elott. :-(
-
Ispy
veterán
válasz kezdosql #4101 üzenetére
Szerintem azért vagy bajban, mert nincs olyan, hogy "Az esemény".
Esemény lehet egy mérkőzés, egy átigazolás.
Tehát kell egy olyan tábla, hogy:
- mérkőzések
- átigazolásokMindegyiknek más a struktúrája, de mindegyikből ki lehet nyerni egy dátumot, egy esemény megnevezést, így össze tudsz rakni egy queue-t ami dátum szerint sorba rendezve mutatja a mérkőzéseket és eseményeket.
Ezt a sok csapat és sok személy dolgot meg nem értem vagy te nem érted a relációs adatbázis működését.
Egy mérkőzéshez max. 2 csapat tartozhat, 1 bíró, 1 tartalék bíró és 2 partjelző.
Viszont mivel a játékosok, bírók és partjelzők között bármilyen átfedés lehet, ezért a személyek táblába kellenek flagek, amikkel be lehet állítani, hogy az adott személy melyik halmazoknak a tagja.
Itt már írtam róla bővebben...ezt kell kiegészíteni pár dologgal, elég egyszerűnek néz ki nekem.
Sokkal egyszerűbb lenne az élet, ha feldobnád ide a táblákat, amik már készen vannak, és azok mentén raknád fel a kérdéseket, mert arra lehet gyorsan válaszolni, nincsen időm és kedvem az egészet megtervezni helyetted.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
kezdosql
tag
Esemény lehet egy mérkőzés, egy átigazolás.
Minden esemeny, ami datumhoz kotheto tortenes.
Kezdodik a csapatok kereteivel, annak jovahagyasaval, majd azon belul kijelolik, hogy kik vannak akezdo csapatban es kik a potencialis cserek, majd a meccsen kiderul, kik voltak a tenyleges cserek, stb. mind-mind esemeny.Ezt a sok csapat és sok személy dolgot meg nem értem vagy te nem érted a relációs adatbázis működését.
Szerintem erted, csak nem akarod elfogadni.
A csapatok, ugy latom, egyertelmuek szamodra.
A szemelyek pedig az emberek, akik adott idopontban lehetnek jatekosok, edzok vagy birok.
Az elso ket kategoria mindig adott csapathoz tartozik, az utolso mindig fuggetlen.En a "flag"-et nem ertem, meg sose hallottam rola.
Sokkal egyszerűbb lenne az élet, ha feldobnád ide a táblákat
"Feldobtam", a kerdes a kapcsolatok osszehozasa, mert id szerint csak a csapatok azonosithatok, a szemelyek eseteben esetenkent kell a statusza, hogy jatekos, edzo vagy biro.
Ezzel van problemam, ahogy te is irtad, "atfedes lehet", ezt kell valahogy kezelni. -
Ispy
veterán
válasz kezdosql #4105 üzenetére
A csapatok, ugy latom, egyertelmuek szamodra.
Számomra az egész egyértelmű, csak arra próbálunk rávezetni, hogy jó lenne ezt az egészet, ami már megvan SQL táblákba foglalni és azt felrakni ide.
Az elso ket kategoria mindig adott csapathoz tartozik, az utolso mindig fuggetlen.
Igazából tökmindegy. Kell egy személyek tábla, aminek szintén van ID-ja (meg egyébként minden táblának rendelkeznie kell elsődleges kulccsal). Kell egy csapat tábla és kell egy csapattagok tábla, ami tartalmazza, hogy melyik személy meddig volt a csapat tagja, vagy melyik csapatnak még a tagja.
En a "flag"-et nem ertem, meg sose hallottam rola.
Egy szimpla bit, igen/nem, mindegyiknek egy: játékos, edző, bíró.
Én itt kiszálltam, amíg nincsenek kész táblák és azok kapcsolatai felrakva ide...
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
martonx
veterán
válasz kezdosql #4105 üzenetére
Ez így totál parttalan. Megmutatom miről beszélek, most hogy legalább minimum konkrétumot már kihúztunk belőled. A HELYEDBEN én valahogy így állnék neki az egész beszélgetésnek:
Sziasztok, foci mérkőzéseket, meg egész szezonokat, bennük minden létező eseménnyel szeretnék adatbázisban lemodellezni. Jelenleg itt tartok: sqlfiddle példa (egyszerűség, és a példa adatok minimális száma miatt nem szórakoztam Foreign keyekkel)
Az a problémám, hogy...
Amíg nem sikerül a kérdéseidet ilyen formában megfogalmazni, kár is a fentieknél konkrétabb válaszokat várnod.
Én kérek elnézést!
-
Ablakos
őstag
Home könyvtárban létrehoztam a .pgpass file-t a csatlakozási paraméterekkel, 600-as jogosultsággal.
hyperv-ubuntu-server:5432:dvdrental:postgres:postgres
A psql parancs mégsem olvassa.
Mit kell még beállítani az automatikus authentikációhoz? -
kezdosql
tag
válasz martonx #4107 üzenetére
A helyedben belatnam, hogy nem programrol, hanem tablakrol es kapcsolatokrol beszelunk, es mivel en vizualis tipus vagyok, rajzolgatok.
Raadasul eleg a megnevezes, es nem kell szorakozni a tipusokkal, amirol egyreszt fogalmam sincs, hogy adott verzioju mssql mi a nyavalyat kovetel meg es milyen formaban es milyen hossz kell neki - mind lenyegtelen, az ID, a szoveg es a datum mezo a lenyeg, azok meg egyertelmuen kiderulnek a megnevezesekbol.Amugy eleg erthetoen beirtam a semat, konnyen lehet latni a kapcsolatokat, de majd pontositom, hogy ti is megertsetek.
Nekem egy oldalon kell latnom a tablakat, kozottuk a kapcsolatokat, az akarhanyszaz soros create parancssorbol nehez kihamozni, mi hol van es mivel fugg ossze.
Ha az sql-hez ertes azt jelenti, hogy tobb szaz create.. parancssort beirsz es a vegen raboksz valamire, hogy ezt innen veszem, akkor valoban nem ertek sql-hez, nekem le kell rajzolnom a tablakat es memorizalnom kell, hogy melyik tablaban miket kapcsolok ossze. A hosszu lista nekem nem mond semmit, amig nem rajzoltam le a sok kis (nagyobb) teglalapot.
Most sajnos komolyabb gondokkal kel foglalkoznom, de hamarosan jovok a listaval.
-
-
martonx
veterán
válasz kezdosql #4109 üzenetére
Te meg beláthatnád, hogy segíteni próbáltam, de akkor inkább hagyom. Hidd el, lehet papíron rajzolgatni, meg azt mondani, hogy ez, az lényegtelen, aztán a papíron rajzolt valamiket úgyis SQL-ben kell megvalósítanod - ha egyáltalán megvalósíthatóak (persze csinálhatod papíron is, csak az senkit nem fog érdekelni, ez esetben ebben a topikban is kár az időnket rabolnod tovább).
Eddig az volt a baj, hogy semmi konkrét segítséget nem kaptál, most meg az a baj, hogy kaptál. Részemről én itt szálltam ki. Sok sikert!
Én kérek elnézést!
-
kezdosql
tag
Tisztelt Forum!
En azert jottem ide, hogy informaciot kapjak, es tovabbra is a tenyekre akarok fokuszalni es logikus megoldast keresni.
Ha valaki szakembernek tartja magat, akkor orulnek, ha a logika es realitas alapjan reagalna.
Ami a tablakat illeti, mindenki, aki sertodotten valaszolt, hasonlo megoldast javasolt, mint amin en gondolkodtam.
A lenyeges kulonbseg az, hogy allandoan kezdet-veg datumokra kaptam javaslatokat, ami szerintem nem jo, mert minden datumot csak utolag lehet tenykent kezelni.
Tovabbra is ebben latom a lenyeges kulonbseget, es nagyon nem ertem, hogy amikor a legutobbi javaslatom egy datum+szemely+szervezet alapjan esemeny segedtabla bevezetese volt, miert jonnek folyamatosan tamadasok, hogy szemely+szervezet+kezdodatum+vegdatum kell, amikor egyertelmu, hogy a vegdatum csak feltetelezett, az barmikor valtozhat.
-
Jim74
nagyúr
válasz kezdosql #4112 üzenetére
A végdátum mindaddig 9999.12.31,amíg adott személy, adott szervezethez tartozik, ha átigazol, akkor ezen a rekordon kap egy végdátumot, majd egy új rekortban a végdátum +1 nap kezdeti dátummal kerül a másik csapathoz (ha nincs szünet a két csapattagság között). Így egy mérkőzésnél pl. elég csak a mérkőzés dátumát, és a játékosok ID-ját megadni, a fenti törzstáblából már levezethető, hogy melyik csapat mérkőzött egymással.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz kezdosql #4112 üzenetére
Mindkét megoldásnak van létjogosultsága. A te verziód akkor lenne használható, ha minden egyes napra generálnál egy rekordot, ami a napra vonatkozó aktuális állapotot mutatja. Intervallumok használatával viszont egy csomó erőforrást megspórolsz. Csak akkor van szükség új rekordra, ha valamelyik mező adattartalmában változás történik.
-
Zalanius
tag
"miert jonnek folyamatosan tamadasok"
Ha volna is ilyen, alighanem azért volna, mert egy helikopter már három hónapja köröz a topic felett.
--= Zalán =--
-
martonx
veterán
válasz kezdosql #4112 üzenetére
Ember, ezért küldtem konkrét sql scriptet, amiben a végdátum NULLABLE. Azaz nem kell megadni, majd akkor megadod, amikor valóban végetért.
Könyörgöm, tanulj már meg végre SQL-ezni, és tereld már a szakmaiság, és a konkrét megoldás felé magadat, a rózsaszín ködben papíron rajzolgatás helyett, mert ez így borzalmas.
Idióta vádaskodások, belemagyarázások helyett.Én kérek elnézést!
-
Klub19111
újonc
Üdvözlet a fórumnak!
Excelben van egy nyilvántartásunk, de most már sok probléma van vele, mert sokan jönnek-mennek, és akik vannak, azok se minden hónapban jönnek.
Pláne most kitalálták, hogy havonta kell terembeosztást csinálni, azzal is többet kell foglalkozni.Próbáljuk excelben megoldani, de volt, aki szerint ehhez sql-es segítség kell.
Feltöltöttem egy lebutított excel fájlt, csak a négy fontosabb táblázatot hagytam meg, az lenne a jó, ha valahogyan össze lehetne kapcsolni őket, hogy ne legyen névelírás és más gond.
Előre is köszönök minden ötletet, hogyan lehetne megoldani.
Csak Excelünk van, sql-ben valamilyen ingyenes programra lenne szükségünk.
-
Zalanius
tag
válasz Klub19111 #4117 üzenetére
Összekapcsolás helyett inkább bontás meg átszervezés kell ide, például a Tagok munkalap felbontása -> [Klub]; [Személy]; [Klubtagság] táblákra stb., aztán a Büntetést nyilván egy konkrét teremfoglalásra kell terhelni. Ha rögzített idősávok vannak, akkor azoknak is kell külön tábla, és így tovább. Egy ilyen sémát pikkpakk felír itt bárki, de akkor már nem valamilyen elnagyolt xlstáblából érdemes indulni, ahol a kevésbé fontos részletek hiányoznak, hanem pontosan összeszedve a fogalmakat, igényeket, különben nem éritek el azt a célt, hogy az adattár egyértelmű és áttekinthető legyen, és marad a toldozás-foltozás.
De ez csak az egyik rész. "Ingyenes" adatbáziskezelők akadnak (sqlite, sql express, egyebek), bár üzemeltetni is kell ezeket valahol / valahogy. Oda aztán be is kell tölteni, úgymond migrálni a jelenlegi exceles állapotot, ami nem feltétlen lesz bárki által kivitelezhető. Kínálná magát egy átalakítás Access használatával, egy kicsit az Excelre hasonlító felületen, de az meg nem is annyira ingyenes. Az SQLite például igen barátságosan elfut szinte bármilyen kávédarálón, de valamilyen felhasználói felület azért kellene "fölé". Ezért a felhasználók száma is egy szempont, meg a felhasználás helye (csak lokális vagy valamilyen felhős megoldás kell). Ezek csak az első körös megjegyzések, ha olvassa majd más, hozzáírhat még vagy fél tucatnyit.
Röviden: ez egy első látásra könnyű feladat, ami villámgyorsan el tud durvulni, és hirtelen költségek is lesznek. A kérdés: akkora már az adatmennyiség, és annyira kritikus is a helyzet, hogy megéri áldozni ezekre?
--= Zalán =--
-
xTREem
tag
Sziasztok!
Python37-sqlite3 kombóval dolgoznék, de az istennek nem megy a magyar rendezés.
SQLiteSpy-ban sima ügy a lekérdezés 'COLLATE systemnocase' megoldással, ami teljesen jól működik, ugyanakkor python alatt egy 'no such collation sequence: systemnocase' hibaüzenetet ad.
Értem én a hibaüzenetet, rendben is van, de mi az egyszerű megoldás?Válaszotokat köszönöm!
-
sztanozs
veterán
-
kw3v865
senior tag
Sziasztok!
PostgreSQL-t használok és egy olyan kérdésem lenne, hogy egy adott mezőből (varchar) kellene kiszedni egy stringet, amelynek a pontos hossza nem minden eesetben ugyanannyi, és a pozíciója sem fix, azaz nem mindig egy adott sorszámnál kezdődik és végződik. Csak azt tudom, hogy a számomra szükséges rész mindig így kezdődik:"ref"=>"" (az idézőjelekkel együtt)
A > utáni idézőjelek közötti rész az, ami változó és számomra releváns, de nem tudom, hogy hány karakter hosszú.Az addig okés, hogy kiválasztottam azokat, amelyek tartalmazzák a szükséges részt, így:
LIKE '%"ref"=>"%"
Viszont ebben az oszlopban még mindig sok felesleges infó található. A cél az lenne, hogy a felesleges karakterek kiszűrjem, azaz csak azt tartalmazza az eredmény, ami a kacsacsőr utáni két időzőjel között helyezkedik el. Van valami ötletetek miként lehetne ezt megoldani?[ Szerkesztve ]
-
-
Apollo17hu
őstag
válasz kw3v865 #4122 üzenetére
Így?
SELECT tabla.mezo
,substr(tabla.mezo, instr(tabla.mezo, '"ref"=>""') + length('"ref"=>""')) relevans_adattartalom
FROM (SELECT 'asfasf saf"ref"=>""ez kell' mezo
FROM dual
UNION
SELECT 'asfasf ssadfalksijdfkeefaf "ref"=>""ez is kell, de ez hosszabb' mezo
FROM dual) tablaSubstr utolsó paraméterét elhagyva a mező utolsó karakteréig mindent leválogat. Ha nem jó, akkor mindenképp kell egy ismérv/logika, ami meghatározza a releváns karaktersorozat végét.
-
I02S3F
őstag
Sziasztok!
A következő a szekció címe, amit mysql-ben tanulok: "Ugyanazon tábla többszörös használata". Az alább leírt példakódot nem értem, magyarázatra szorul, ezért kérlet titeket nevezzétek meg, hogy mi ez, hogy rákereshessek a neten részletesebb magyarázatért.
SELECT t1.helysegnev, t2.helysegnev, t1.lakossag, t2.lakossag
FROM telepules AS t1, telepules AS t2
WHERE t1.lakossag=t2.lakossag AND t1.helysegnev<t2.helysegnev
ORDER BY 3;- Mit csinál/jelent a pont ebben a kifejezésben "t1.helysegnev"?
- Azért van kétszer a FROM után a telepules tabla atnevezve, hogy műveletet tudjuk rajta végrehajtani ugyanazon táblán (pl.: összehasonlítás)?
- A t1 egy osztály, azért a pont?
- Tudnátok linkelni olvasnivalót, vagy hogy mire keressek rá, hogy megértsem ezt?[ Szerkesztve ]
-
I02S3F
őstag
Meg is válaszolom a kérdésem. (A MySQL dokumentációjában nem igazodtam ki, de a W3schools weboldala egy egyszerű áttekintést ad. Ott találtam rá a válaszra.)
Ez sima alias azért, hogy rövidítetten lehessen hivatkozni egy "hosszú" nevű táblára. Plusz trükk, hogy ugyanazt a táblát két aliassal látták el, hogy a két tábla között műveletet lehessen végezni.Javítsatok, ha rosszul gondolom!
[ Szerkesztve ]
-
dellfanboy
senior tag
hello
lenne egy mySql kerdesem. adott a script 3 oszloppal, es a mai datumot szeretnem beszurni mint harmadik oszlop.
viszont error uzenetet kapok a curdate-re de nem jovok ra mi a hiba.<?php
include 'library.php';
$link = getDb();
$create = false;
if (isset($_POST['create'])) {
$tagid = mysqli_real_escape_string($link, $_POST['megrendelo_id']);
$autoid = mysqli_real_escape_string($link, $_POST['autok_id']);
$query = sprintf("INSERT INTO kolcsonzes (megrendelo_id, autok_id, kolcsonzes_kezdete) VALUES (%s, %s, CURDATE())", $megrendelo_id, $autok_id);
mysqli_query($link, $query) or die(mysqli_error($link));
$create = true;
}
?>van vkinek vmi tippje mit benazhatok?
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
nagyúr
válasz dellfanboy #4129 üzenetére
kéne az "error uzenet".
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
dellfanboy
senior tag
-
nagyúr
válasz dellfanboy #4131 üzenetére
fura. futtasd le kérlek ezt a db-ben:
describe kolcsonzes;
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
dellfanboy
senior tag
válasz velizare #4132 üzenetére
lefutott
Finished executing script
Field Type Null Key Default Extra
id int(11) NO PRI NULL auto_increment
autok_id int(11) NO MUL NULL
megrendelo_id int(11) NO MUL NULL
kolcsonzes_kezdete date NO NULL
kolcsonzes_vege date YES NULL
fizetendo_osszeg int(11) YES NULL
megjegyzes varchar(45) YES NULL
Operation completed successfullyeladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
bpx
őstag
válasz dellfanboy #4129 üzenetére
Ez nem SQL, hanem PHP probléma.
$tagid, $autoid helyett $megrendelo_id, $autok_id változókat használsz a query-hez, és nem a CURDATE()-tel van baja, hanem az üres változók miatt a "(, , CURDATE())"-tel.
[ Szerkesztve ]
-
SUPREME7
őstag
Sziasztok, segítségre lenne szükségem.
Van 3 táblám,
Nyereményjátékok | résztvevők | nyertesek
Szeretném azokat a nyereményjátékokat lekérdezni amiken X részt vett, de nem nyert. A 3 táblát összeköti a nyereményjáték azonosítója.
Jelenleg ez "sima ügy", hogy megvan, hogy melyik nyereményjátékokon vett részt, hogy kellene kiegészítenem, hogy csak azokat listázza amiken részt vett, de nem nyert? Tehát a nyertesek táblát még valahogy bele kéne vonni, hogy ott létezik-e adott user, adott játék azonosítóval. De ez már nekem sok SQL-ből
SELECT nyeremenyjatekok.* FROM resztvevok INNER JOIN nyeremenyjatekok ON nyeremenyjatekok.id=resztvevok.jid WHERE resztvevok.user=?
[ Szerkesztve ]
-
SUPREME7
őstag
válasz Apollo17hu #4137 üzenetére
Áhh, ennél sokkal bonyolultabb találatokat dobott a gugli, de nem sikerült összesakkozni, rá kéne gyúrni ilyen "komplexebb" lekérdezésekre, csak az a baj ritkán kell Hálás köszönetem
-
-
sztanozs
veterán
válasz bambano #4139 üzenetére
hozzátenném, hogy nagyobb táblákban a
not in
sql formula kerülendő (mert nem hasít, hanem és végig iterál a táblán annyiszor amennyi elemet ellenőrizni kell, és ezen még az indexek jelenléte sem segít)[ 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...
-
válasz sztanozs #4141 üzenetére
explain select * from customer where id not in (select customer_id from <anonimizálva>);
QUERY PLAN
---------------------------------------------------------------------------------
Seq Scan on customer (cost=1174.57..1372.72 rows=3366 width=243)
Filter: (NOT (hashed SubPlan 1))
SubPlan 1
-> Hash Join (cost=395.85..1134.83 rows=15895 width=4)[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
sztanozs
veterán
-
I02S3F
őstag
válasz Apollo17hu #4128 üzenetére
Köszönöm szépen!
-
-
sztanozs
veterán
válasz bambano #4145 üzenetére
ehh, ott maradt az id az elején, megzavart az anonimizálva
szóvalexplain select * from customer c where not exists (select customer_id from <anonimizálva> a where c.id = a.customer_id );
[ 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...
-
válasz sztanozs #4146 üzenetére
megnéztem rendesebben a kérdést, és nem látom értelmét bemásolni az eredményt.
az explain és az explain analyze egymáshoz képest fordított eredményt hoz. az explain szerint a not in 4x gyorsabb, az explain analyze szerint meg az exists gyorsabb.ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz, ami a fő selectben van. egyébként pedig a postgresql-nél ez a probléma régebben felmerült, úgy látom, hogy a query plannere fel van rá készítve és jó eredményt hoz.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
sztanozs
veterán
válasz bambano #4148 üzenetére
ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz
Elméletileg pont fordítva. A NOT IN-hez kell iterálni, az NOT EXISTS anti-joinra konvertálható (csak ebben a formában szebb).Analyse jól írja, mert tényleg pont fordítva van, mert az exists és a left join + null is anti-joinra van optimalizálva, a not in pedig hashed subplan (mert az IN értéket és null-t is visszaadhat, ezért kétszer fut az iteráció - ki elemszámnál ez nem probléma, de nagy elemszámnál már lesz különbség, ráadásul a subplan miatt cache problémák lehetnek).
EXPLAIN ANALYZE
It is possible to check the accuracy of the planner's estimates by using EXPLAIN's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows.[ 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...
-
zek47
csendes tag
Üdv mindenkinek! Nem vagyok SQL felhasználó, épp csak belenéztem az alapokba. Különböző programok (pl. böngésző, android rendszer) SQLite adatbázisokban tartják az adataim, amiket szeretnék általam felhasználható, szöveges formában kinyerni. Kérdéseim: 1. Az sqlite3 .dump utasítás minden információt kimásol, vagy marad még valami elrejtve az adatbázis fájlban? 2. Ez az utasítás a csatolt journal fájt is feldolgozza? 3. Van esetleg jobb mód az adatok teljes körű kinyerésére?
Bónuszként örülnék, ha elmondanátok, az ilyen egyszerű, kis elemszámú adattárolási feladatokra, javarészt szöveges adatokhoz, a fejlesztők miért használnak adatbáziskezelőt és bináris fájlformátumot valamilyen szöveges formátum (pl. json, hagyományos ini) helyett.
Köszönöm.
Új hozzászólás Aktív témák
- Windows 11
- Magga: PLEX: multimédia az egész lakásban
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Facebook és Messenger
- Autós topik
- Mozilla Firefox
- HP notebook topic
- Azonnali VGA-s kérdések órája
- Azonnali informatikai kérdések órája
- A Gigabyte is visszaveszi alaplapjainak alapértelmezett tuningját
- További aktív témák...
- LG NanoCell 55NANO766QA Halvány píxel csík
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- The Last of Us Part I Ps5