Az elsővel inkább az a gond, hogy a feljesztés előtt ha nincs rendes specifikáció, akkor az adattartalom és adat-reprezentáció komolyan változhat a fejlesztés során. Ilyen helyzetben tényleg hátrány lehet az adatbázis oldal verziókezelése. Azonban az adatbázis felépíthető tisztán text alapú utasításokon keresztül, amit már kezel a verziókezelő. Egyszerűen csak a szöveg alapú reprezentációt kell frissíteni és verziónként új adatbázist készíteni - nem pedig az aktuálist hozzáhegeszteni a fejlesztői verzióhoz. Ilyen módon az adatbázis felépítés (és a tárolt eljárásoik is) is egyszerűen verziókövethetővé válik.

A második szerintem csak sírás. Adatbázis oldalon bőven elég szerintem az a WSWG megoldás, ami a piacon elérhető - ha az nem felelne meg, amit a motorhoz adnak.

Ráadásul amint adatbázis szintű jogosultságkezelésre kerül sor nagyon nehéz bekorlátozni egy felhasználó tevékenységét, ha bármilyen tevékenységre kell jogának legyen bármelyik táblán, mert közvetlen adatbázis műveletekkel megy a lekérdezés, frissítés.

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...

A verziókezelés használata önfegyelem kérdése. Nem is értem miért ne lehetne a tárolt eljárásokat verziókezelni, hiszen végül is azok is csak sima szöveges "fájlok".

A második résszel meg egyszerűen nem értek egyet. Vagy mit nevez ő a XXI. század fejlesztői eszközének?

=Kilroy was here============================ooO=*(_)*=Ooo=======

Más kérdés persze, hogy a keretrendszerek gyakran (?) nem készítenek tárolt eljárásokat, csak összehegesztik az adatstruktúrát és legenerálják a műveleteket közvetlen SQL utasításokként.

De végül is nem mindegy, hogy az ember keretrendszert haszál, vagy speciális környezetet fejleszt. Természetesen egy kis fejlesztésnél keretrendszer használatával az ember nem fog minden adat-reprezentációt kézzel megvalósítáani, mivel pont azért használ keretrendszert, hogy ezzel ne kelljen foglalkozni.

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...

Örökös vita a tárolt eljárás használata vagy nem használata.
Én egyik mellett sem kardoskodnék, mert ezer + 1 körülménytől függ, hogy adott fejlesztésben / ellenjavalt, érdemes / kell használni tárolt eljárásokat.
Csak egy a számtalan, neten fellelhető cikkből, threadből, ahol ez a téma: [link]
Szinte minden érvre lehet ellenérvet találni ebben a témakörben. Szerintem az a fontos, hogy jól ismerjük a lehetőséges megoldásokat, ezek előnyeit, hátrányait, így lehet jó döntéseket hozni a tervezés, implementáció során.

Thank you to god for making me an atheist

"- A tárolt eljárásként írt kódot nehézkes verziókövetővel használni"
Butaság, miért ne lehetne, bár valóban nem annyira triviális. Én pl. TFS-ben egy külön mappát tartok fenn a DB scripteknek, amik ugyanúgy verziókezelődnek.

"- Az adatbázisok által biztosított fejlesztői eszközök a 60-as évek színvonalát idézik"
Ez mondjuk nagyon függ attól, hogy milyen DB-t használunk. Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn), MySql vonalon szeretem a Toad for MySql-t (mysql-hez van kismillió jó SQL IDE), PostgreSQL-hez meg egészen használható a PgAdmin.

Klasszikus hibás programozói attitűd, amikor valaki nem akar megtanulni SQL-ezni (pedig gyakran nagyon hasznos), hanem mindent java-ban, c#-ban, php-ben akar programozni. Én használok ORM-et (sőt mostanra csak ezt), de az ORM-el ha a feladat azt kívánja meg akkor tárolt eljárást hívok meg. Sokan az ORM-et is félreértik.
Attól, hogy ORM-et használ valaki, miért ne lehetne összerakni DB oldalon egy view-t, vagy egy tárolt eljárást, és azt használni ORM-mel?

Én kérek elnézést!

"Vagy mit nevez ő a XXI. század fejlesztői eszközének?"
Ezeket a kérdéseket miért nem teszitek fel közvetlenül neki a belinkelt topicban?
(Szerk.: tisztább is lenne, mint a háta mögött beszélni a hozzászólásáról...)

[ Szerkesztve ]

Sk8erPeter

mert az egy php-s topik, minek offolni benne SQL fejlesztő eszközökről. Annak meg nem látom értelmét, hogy egy szemmel láthatóan nem képben lévő, ám annál arrogánsabb embert, megpróbáljunk picit is képbe hozni.

Én kérek elnézést!

Ez nem kibeszélés, csak megvitatás. Egy rossz szót nem szóltam. .

Hát ez is igaz, hogy ott nagyon OFF lenne. Rájöttem, hogy a legtisztább az lenne, ha az illető jönne inkább ide témázni a dologról, talán végre konstruktív vita is kialakulhatna, "nem arról szólna végre a topic, hogy nááám múúúkodik az, hogy lekérjem a termékek táblából a 123-as id-jú termék nevét, mééé' neeem?"

Sk8erPeter

Sziasztok!

Hátha tud segíteni valaki. Adott egy ubuntu 12.10 szerver, amin fut a PostgreSQL 9.1. Ennek a mentését szeretném, hogy automatikusan lefusson. Erre a script megvan ill. a cron is működne, de amikor eléri a pg_dump ... leáll. Ha WinScp-vel belépek és a scriptet kézzel próbálom futtatni akkor sem fut le. Terminálban root-ként a pg-hez jelszó beírása után indul is a backup és lefut. Amit eddig találtam, ott valami olyat írtak, hogy csatolni kellene az pg_backup.sh-t. Na ezt, hogy tudnám megcsinálni? (gondolom jelszó a probléma, nem tud hozzáférni az adatbázishoz)
Előre is köszönöm a segítséget.

..........""..........

Nyilván hibás az ütemezett scriptben megadott autentikáció, de ezt innen nem fogjuk tudni helyetted megoldani.

Én kérek elnézést!

Egyszerűen csak a szöveg alapú reprezentációt kell frissíteni és verziónként új adatbázist készíteni - nem pedig az aktuálist hozzáhegeszteni a fejlesztői verzióhoz. Ilyen módon az adatbázis felépítés (és a tárolt eljárásoik is) is egyszerűen verziókövethetővé válik.
Igen, ez így van. Lehet adatbázis deploy scripteket írni, nincs ezzel semmi gond. Az eredeti kérdésfelvetés viszont a php topikban volt, méghozzá azzal kapcsolatban, hogy a php kódban implementált alkalmazáslogikát megérné tárolt eljárásként megírni. Na ezzel így már problémák vannak:
- A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz. Tárolt eljárásokkal elvesződik az előny.
- A legtöbb php-s projekt olyan kis léptékű, amin már egy adatbázis deploy script elkészítése és karbantartása is túlmutat.

Nem azt mondom, hogy a tárolt eljárások ne lennének alkalmanként hasznosak, de abban a kontextusban, ahol felmerült a kérdés, egyáltalán nem tartom jó ötletnek.

A második szerintem csak sírás. Adatbázis oldalon bőven elég szerintem az a WSWG megoldás, ami a piacon elérhető - ha az nem felelne meg, amit a motorhoz adnak.
Mi az a WSWG?

(#1555) martonx
Szvsz SQL fejlesztői környezetek közül a legjobb az SSMS, de Oracle vonalon a Toad for Oracle is jó (csak ronda, mint a bűn)...
Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van.

A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást.

[ Szerkesztve ]

"A php előnye, hogy a verziókövetőben található fileok halmaza és a futtatható kód egy és ugyanaz."
Ez miért előnye a php-nak? Miért más nyelveken mit tárolnak a verziókövetőben? Szerelmes verseket?

"Félreérthető voltam, amire utalni szerettem volna, az a programozási nyelv (mondjuk PL/SQL) és annak a szolgáltatáskínálata, na ez az, aminek 60-as évekbeli hangulata van."
A relációs SQL az egy rohadt nagy halmaz, rengeteg alhalmazzal, amik között halmaz műveleteket tudsz elvégezni rohadtul gyorsan. Hol akarsz ebben fejlődést? Legyenek örökölhetőek, interfészelhetőek a tárolt eljárások? Legyen bennük lambda, meg generikus függvények??? Ráadásul vicces pont PHP oldalról fanyalogni az SQL nyelv egyszerűsége miatt...

"A többire kb. válaszoltam feljebb. A lényeg, hogy nem azt állítom, hogy tárolt eljárást írni rossz ötlet lenne, hanem hogy az esetek többségében nem ad semmilyen előnyt, cserébe növeli a komplexitást."
Ne általánosítsunk már ennyire. Lehet, hogy a te eseteid kimerülnek abban, hogy egy darab adattábla van a weboldalad alatt. De hidd el, amikor komoly adatlogikákat kell kivitelezni, és komoly algoritmusokat kell kivitelezni, akkor azt próbáld már meg webszerver oldalon kivitelezni. És ha készen vagy vesd össze a futásidőket. Tudnék mutatni olyan tárolt eljárásokat, amik több ezer sorosak, és percek alatt lefutnak. Az egyikkel konkértan egy 4 óra futásidejű webszerver oldali tákolmányt váltottunk ki.
Csak gondolj bele. Minden egyes db-hez fordulás idő. Ha van egy komplexebb feladat, amihez több db hívás kell, hívásonként visszad az sql szerver pár millió adatot. Utána for-al megforgatod az adatokat, megcsócsálod, majd visszaírod db-be, akkor az nagyságrendekkel könyebben, gyorsabban, optimalizáltabban elvégezhető db oldalon.
Az én eseteim pl. szinte minden esetben ilyenek. Mégse mondom azt, hogy az esetek többségében tárolt eljárást kell írni. Ehelyett maradjunk abban, hogy a helyzet dönti el, melyik megoldás a hatékonyabb a rendszer futása, terhelhetősége szempontjából.

Én kérek elnézést!

Tegyük hozzá, ha jól értelek, hogy te a webes programozásról beszélsz, nem a klasszikus adatbáziskezelési feladatokról, ugye?

=Kilroy was here============================ooO=*(_)*=Ooo=======

Ez miért előnye a php-nak? Miért más nyelveken mit tárolnak a verziókövetőben? Szerelmes verseket?
Annyi előny, hogy nem kell lefordítani, megszabadulsz a Make/Ant szkriptektől, vagy az xml-ek turkálásától Mavenben, stb. . (Meg persze bizonyos szempontból ez hátrány is, tudom jól, ne akadj fenn ezen)

A relációs SQL az egy rohadt nagy halmaz, rengeteg alhalmazzal, amik között halmaz műveleteket tudsz elvégezni rohadtul gyorsan. Hol akarsz ebben fejlődést? Legyenek örökölhetőek, interfészelhetőek a tárolt eljárások?
Ha alkalmazáslogikára szeretnéd használni, akkor szélesebb körű beépített libeket, és igen, több nyelvi eszközt.

Ráadásul vicces pont PHP oldalról fanyalogni az SQL nyelv egyszerűsége miatt...
Az egy dolog, hogy a php egy nem túl jól kitalált nyelv, csomó furcsasággal, viszont a beépített eszközkészlete (magyarul a standard lib) igencsak jól használható és jól dokumentált.

De hidd el, amikor komoly adatlogikákat kell kivitelezni, és komoly algoritmusokat kell kivitelezni, akkor azt próbáld már meg webszerver oldalon kivitelezni.
Emlékeztetlek, az eredeti hozzászólás a php topikban keletkezett, arra a felvetésre, hogy a php kódba nem kéne egyáltalán sql-t beágyazni/összerakni, hanem minden hasonló feladatot tárolt eljárással kéne megoldani. A php topikban pedig jellemzően nem a szakma krémje szokott kérdéseket feltenni, hanem kezdők.
Szóval igyekezz ennek tükrében értelmezni, amiket írtam. Én is pontosan jól tudom, hogy komplex projekteknél és nagy adatmennyiségnél az adatbázis szerver és kliens közötti kapcsolat overhead-je elszaladhat. Ennek ellenére nem fogom egyik kezdő php fejlesztőnek sem tanácsolni, hogy dobja ki a php-vel legyártott dinamikus sql-t és kezdjen inkább tárolt eljárásokat írni ezek kiváltására.

[ Szerkesztve ]

Úgy gondoltam, hozzátok fordulok a kérdésemmel:
Nem konkrétan SQL a téma, hanem MS Acces. Az lenne a lényeg, hogy van egy táblám, benne személyekkel, és van egy Neme mező, ahol 0 vagy 1 található (0 ha nő, és 1 ha férfi). Ehhez készítek egy jelentést, és hogy tudnám megcsinálni azt, hogyha a Neme értéke 0, akkor Nőt írjon ki, ha pedig 1, akkor Férfit, mert egyébként ugye a számokat írja ki, de úgy meg elég csúnya.

:D Semmi :D

Csinálj egy kétrekordos dimenziótáblát, amiben 1-1 rekordja lesz a nőknek és a férfiaknak. Kulcs a 0 és az 1, a dimenziótáblában meg felveszel egy "férfi" és egy "nő" értéket, majd ezeket pakolod a jelentésbe.

MS Access SQL nyelvében nincsen case when, helyette IIF()-et kell használni.
Nem próbáltam ki, de valami ilyesmi kellene neked:

Select mezo1, mezo2, mezo3, IIF(mezo4 = 0 , 'Nő', 'Férfi') from tabla

Én kérek elnézést!

[link], [link]

[ Szerkesztve ]

Köszi, ezzel sikerült megoldani!

:D Semmi :D

Örülök.

Segítséget szeretnék kérni olyan embertől akinek Oracle DW és/vagy MSSQL BI fejlesztői tapasztalata van. Kérem keressen privátban a részleteket ott megírom.

Valamelyikőtök találkozott már ilyesmivel? Incorrect key file for table '/tmp/#sql_3c7_0.MYI'; try to repair it.

Mysql-ről van szó.

Nem, de a hibaüzenet alapján újra kellene indexelni a táblát.

Én kérek elnézést!

Töröltem az indexet, és újrageneráltam. A számosságra 204-et ír a ~37000 helyett, miközben az utóbbinak kéne ott állnia. InnoDb a tábla.

sziasztok

3 táblából szeretnék lekérdezni, mysql-ben, az elején csak két táblából kérdeztem le, az futott rendesen, így:

SELECT table_1.id as ROW_1, SUM(table_1.VALAMI) as ROW_2, SUM(table_1.VALAMI) as ROW_3, SUM(table_1.VALAMI) as ROW_4, [B]table_2[/B].akarmi as isAKARMI
[B]FROM EGYTABLA as table_1, MASIKTABLA as table_2
WHERE table_2.id = table_1.id[/B]
GROUP BY 1
ORDER BY 3

A kiemelt részek a fontosak, mert így működött, ellenben ha a

FROM EGYTABLA, MASIKTABLA, HARMADIKTABLA -sorra kicserélem a fentit, akkor egy ilyen hibát dob:

#42000The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay

A kérdés tehát: hogy lehet három táblát összekapcsolni egy selectben? van egy oszlop, amivel a három táblát össze tudom kapcsolni, ez az "id".

Próbáltam így is:

SELECT ...
FROM [B]EGYTABLA_CI [/B]as tabla_1
INNER JOIN [B]MASIKTABLA [/B]as tabla_2 ON tabla_1.id = tabla_2.id
INNER JOIN [B]HARMADIKTABLA [/B]as tabla_3 ON tabla_1.id = tabla_3.id
...

üdv

megj: rákerestem a hibára, de nem lettem okosabb amit ír az error, azt pedig nem tudom hova kéne beilleszteni a queryben.

[ Szerkesztve ]

2013-ban nem illik ilyen old school join-okat csinálni. Írd át modern sql szintaktikára:

from egytabla t1
join kettotabla t2 on t1.id = t2.id
join haromtabla t3 on t1.id = t3.id

A hiba pedig elég egyértelmű. A három tábla descartes szorzata túl sok sort adna vissza, és (shared hosting környezetben jellemzően direkt) le van korlátozva a mysql memória használata, join-ok mérete.

Ezt elkerülni úgy tudod, hogy vagy megpróbálod átkonfigurálni a mysql-t, ha nem vagy hosting környezetben akkor ez menni fog.
Vagy alselecteket használsz, és megpróbálod csökkenteni a join-olt táblák visszaadott sorainak számát. Erre jó lehet akár egy szigorúbb feltételes join is. Az is lehet, hogy az id kapcsolat nem jó, és ez miatt többszörőződik meg indokolatlanul a join.
Vagy átmész egy rendes hosting-hoz, ahol nincs ilyen korlátozás.

Én kérek elnézést!

Nálam az alselectek sokkal több erőforrást elvittek, mint a join-ok. Esetleg úgy lehet egyszerűsíteni, hogy a join jobb oldalán egy alselect van. Így sokszor lehet a 3-ból 2-t csinálni.

bocsánat, nem fogalmaztam pontosan, természetesen a join-ban használt alselectre gondoltam, azt hittem ez a szövegből egyértelműen kiderül. De ezek szerint nem. Senkit nem szeretnék félrevezetni!
Szóval az egyértelműség kedvéért: A select-be ágyazott alselect a legrosszabb megoldás (még ha gyarkan az engine ki is tudja optimalizálni, de erre ne építsünk!). A join-ba ágyazott alselect viszont nagyon hasznos tud lenni.

Én kérek elnézést!

Nálam is félreérthető volt, de ugyanarra gondoltunk.

haha,
Nem tudom melyik adatbázisra gondoltál, de hivatalos Oracle oktatáson mégis elhangzott (a tapasztalt Oracle szakértő szájából), hogy szép-szép az új join szintaktika, de ha biztosra akarunk menni akkor használjuk a régi módszert....

=Kilroy was here============================ooO=*(_)*=Ooo=======

hehe, ezen tényleg csak nevetni lehet.
Mondjuk ezt többször is hangoztattam, hogy leginkább MS SQL, PostgreSQL vonalon mozgok, néha egy kis MySQL-el, Oracle-el fűszerezve. Azért megkérdezném azt az oktatót, hogy mire alapozza amit mond (évtizedes berögzülés nem számít, illetve az Oracle 9i-re hivatkozást sem fogadom el érvként), és ugyan mutasson már egy példát.

Én kérek elnézést!

Nyilván az optimalizáló miatt. Amíg pár százezer soros adatokat dolgozik fel biztos mindegy, a pár milliónál már érdekes lehet.

=Kilroy was here============================ooO=*(_)*=Ooo=======

MS SQL optimalizációit ismerve nagyon nem mindegy, hogy az sql motornak néhány soros (hangsúlyozom néhány), vagy ennél több, mondjuk pár százezer adattal kell dolgoznia. De hogy 100.000 vagy 100.000.000 az már édesmindegy. Klasszikus optimalizálási hiba tud lenni, hogy pár sornyi teszt adatokkal az sql-t beoptimalizálja a motor, majd amikor mindezt ráengeded 100.000-re akkor csodálkozol, hogy miért lassú.
De hogy jön ez a join-olás régi vagy új szintaktikájához? Nehogy már a használt join szintaktika határozza meg az sql motor optimalizálását.

Én kérek elnézést!

Ó, én az Oracle optimalizáló fejlesztőiből bármit ki tudok nézni, annyi minden "faszsággal" érthetetlen dologgal találkoztam már. Ebbe belefér az is, hogy a joint rosszul (értsd: nagyobb költséggel) értelmezi egyik illetve másik esetben.
De lehet, hogy csak a rosszindulat beszél belőlem, és mostanra már tényleg szép és jó az Oracle join szintaxisokkal.

[ Szerkesztve ]

=Kilroy was here============================ooO=*(_)*=Ooo=======

Ezért is hangsúlyoztam mindenhol, hogy az Oracle-el felületesek (mondjuk azok nem túl pozitívak) az ismereteim, és egy szinte ismeretlen rendszerről nem volna etikus véleményt mondanom. Pláne, hogy történelmi okok miatt máig a legelterjedtebb db, annyira nem lehet rossz.
Őszintén én is bármit el tudok képzelni az Oracle db motor működéséről, de mivel az Oracle-höz bevallottan nem igazán értek, és db motor flame-be se akarok belemenni, maradjunk abban, hogy Oracle esetén akár igaz is lehet, hogy biztos ami biztos alapon érdemes a régi join szintaktikát használni.

Én kérek elnézést!

Sziasztok!

Erre a régi meg új szintaktikára tudnátok egy-egy nagyon rövid példát írni? Miben jobb az új és miért? Van előnye a régi használatának? Köszi!

Ez az SQL szabvány szerinti, de csak az Oracle esetén új, más adatbáziskezelőkben ez volt a megszokott
from egytabla t1
join kettotabla t2 on t1.id = t2.id
join haromtabla t3 on t1.id = t3.id

Ez a leegyszerűsített, az Oracle optimalizáló állítólag ezt jobban szereti:
from haromtabla t3, kettotabla t2, egytabla t1
where t3.id = t1.id
and t2.id = t1.id

Mellesleg az új Oracle esetén azt jelenti, hogy kb. 10-12 éve került bele....

[ Szerkesztve ]

=Kilroy was here============================ooO=*(_)*=Ooo=======

Meg szemmel elolvasni is mennyivel kulturáltabb az utobbi. De lehet csak szokatlan a vénebbeknek a modern írás.

[ Szerkesztve ]

Csak ugye, ha a több-join-os táblán van még egy rakat where feltétel, akkor mindjárt könnyeben olvasható az első rész, ahol a join "feltételek" és a query feltételek szépen elkülönülnek egymástól.

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...

Házi feladat: Hogy nézne ki mindez outer joinnal?
Na úgy már jóval olvashatóbb a szabvány szerinte szerintem.

=Kilroy was here============================ooO=*(_)*=Ooo=======

Igen, így van. Neked

Sziasztok!

Androidra fejlesztek BKV programot, ennek az adatbázisához kellene finomításhoz segítség, tipp nekem.
A BKV kiadja a teljes menetrendet a Google GTFS adatbázis formátumban.
Ebből készítek egy programmal egy SQLite adatbázisfájlt, amit az alkalmazás felhasznál az adatok kivételére.
Ez egy 159Mb-os adatbázis file, egy telefonnak elég leterhelő, sajnos egy lekérdezés több perc jelenleg.

Gps koordináták alapján próbálom kiszedni a user melyik megállóban áll, és milyen járatok haladnak át azon a megállón.
Három táblát kell ehhez felhasználnom:
stops táblában vannak a megálló nevei és a GPS koordináták
stop_times táblában az időpontok vannak megadva, melyik percben melyik megállóban melyik járat megy(id)
trips táblában vannak a trip id-hoz tartozó nevek.

Egyértelmű, hogy a stop_times tábla nagyon nagy, úgy emlékszem, hogy 200 000 sor körül van, e miatt nagyon lassú lesz a lekérdezésem. JOIN-al összekapcsoltam a három táblát, az eredmény több perc után, de megérkezik helyesen egyébként.

Hogy lehetne gyorsítani a lekérdezést?
Az adatbázis feldarabolása nem jó, mert megállókra lehetne szétbontani, de az is 4000 fájlt jelentene, ami megint nem megoldás.

Mivel létre kell hozni egy külön SQLite adatbázis fájlt, nehéz bármit is változtatni az eredeti formátumon, mivel a GTFS fájlok sima CSV formátumú fájlok, nem könnyű dolgozni velük.

Milyen tippekkel tudtok segíteni?

PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM

érdekes probléma, és ebből nem tudjuk meg, hogy miért lassú.

Azt mondod gps koordináták alapján akarod kiszedni, hogy melyik megállóban áll. Be tudnád írni a pontos lekérdezést, és egy-egy sor példát a három táblából? Feltételezemm, hogy a telefon nem pont ugyanazt a gps koordinátát fogja visszaadni, amit a táblában tárolsz, tehát ilyen kisebb-nagyobb összehasonlításokat végzel, ami elég költséges lehet.

Plusz nem értem, hogy miért nehéz bármit is változtatni az eredeti formátumon. Gondolom úgy működik, hogy az ember wifi közelben updateli az adatbázist, ekkor akármilyen transzformációt csinálhatsz rajta, majd úgy mented el az SQLite adatbázsiban, ahogy akarod. Keresésénél kell gyorsan működnie, nem updatenél

[ Szerkesztve ]

Itt a BKK GTFS db, csak hogy ne kelljen keresgélni:
[link]

Példák:
stops:
stop_id,stop_name,stop_lat,stop_lon,location_type,parent_station,wheelchair_boarding
F00001,"Mihály utca",47.486079,19.034561,,,2

stop_times:
trip_id,arrival_time,departure_time,stop_id,stop_sequence,shape_dist_traveled
A651191,03:46:00,03:46:00,F04679,010,0

trips:
_id,service_id,trip_id,trip_headsign,direction_id,block_id,shape_id,wheelchair_accessible,trips_bkk_ref
6100,A65119ASZGPP-021,A651191,"Örs vezér tere M+H",1,A65119ASZGPP-021_10A,1226,2,61001

A gps koordináta kerekítés elve megvan, de mivel az szerintem még lassabb lesz, egyelőre megálló névre keresek rá:

SELECT stop_name,stops._id,stop_times._id,trips._id FROM "+MYDATABASE_TABLE+" JOIN stop_times ON stops.stop_id= stop_times.stop_id JOIN trips ON stop_times.trip_id = trips.trip_id WHERE stops.stop_name LIKE '%"+searchstr[0]+"%' GROUP BY stop_times.stop_id"

Ha azt kérem: Deák tér, meg is kapom vissza, szóval megleli, de kb 10 perc alatt, mert a stop_times tábla nagyon nagy és végig kell nyálazza. Olvastam, hogy létre lehet hozni index-et a tábla oszlopaihoz, milyen oszlopokhoz érdemes? Ez után az eredeti lekérdezést kell használni továbbra is, csak az adatbázison gyorsít valamennyit?

Nem tudtam jól megfogalmazni a módosítással mit akartam mondani. A lényeg, hogy lenne olyan megoldás is, hogy a három táblából csinálok egy leegyszerűsítettet, melyik GPS koordinátákhoz mely járatok tartoznak, viszont mivel az alapformátum CSV és a célformátum mysqlite db fájl, nehéz olyan scriptet írni ilyen sok sorú fájlnál, ami nekem ezeket összemergeli egy táblába logikusan. A kész db táblákból csinálni egy újat is lassú, mert ugyanúgy soronként kell haladni.

UI: A GPS koordináták kerekített lekérdezését így oldom meg, hogy legyen hibahatár:
SELECT * FROM "+MYDATABASE_TABLE+" WHERE ( stop_lat > '"+latstart+"' AND stop_lat < '"+latend+"' ) AND (stop_lon > '"+lonstart+"' AND stop_lon < '"+lonend+"')

Egyszerű, működik, de gondolom bazi lassú lesz :S

[ Szerkesztve ]

PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM

sziasztok! tudnátok segíteni abban, hogy egy mysql adatbázisban milyen paranccsal tudom azt megoldani, hogy ha beírok egy elemet, akkor kiírja hogy az az adatbázis melyik oszlopában található? előre is köszönöm a segítséget!

azaz én visszafele szeretnék keresni, hogy adott elem egy táblán belül hol található. ezt megoldható valahogy?

Látatlanban? Ott van minden már, épphogy az adatbázist nem csatoltam
Indexelni melyik táblákat érdemes? Egyelőre csak a stop_times.stop_id-t, és a stops.stop_name -t indexeltem. Explain-t nem vágom, guglizom, nézem, de jöhet tipp!

PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM