Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- Mr Dini: Mindent a StreamSharkról!
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Munkaügyi helyzet Hajdú-Biharban: észak és dél
- gban: Ingyen kellene, de tegnapra
- MasterDeeJay: i7 4980HQ asztali gépben (vs i7 4770)
Új hozzászólás Aktív témák
-
Lortech
addikt
válasz
pittbaba
#1699
üzenetére
A NULL speciális érték, pl. Oracle-ben nullt bármihez hasonlítod = / != -vel, egyaránt unknown eredményt ad. Null helyett érdemes lehet egy speciális, nullt szimbolizáló értéket adni a mezőnek, vagy ha az nem opció, akkor mindig IS NULL / IS NOT NULL-lal (is) vizsgálni.
-
pittbaba
aktív tag
Sziasztok! Mit rontok el?
Van a kérésemben egy feltétel exception_type <> 2, ha a kérésembe beteszem ezt a feltételt, akkor üres sorok jönnek ki, ha kikommentelem, akkor kijönnek az eredmények, olyanok is, amiknél az exception_type értéke NULL. Miért nem igaz a feltétel mégsem? -
Lortech
addikt
válasz
alratar
#1692
üzenetére
Na és akkor mi lesz, ha már a tényleges, aktív játékosállomány is meghaladja ezt a tartományt, miután megcsináltad ezt a léptetgetést ?
Komolyra fordítva, az id-ket nem módosítgatjuk, főleg nem ilyen ürüggyel. Megfelelően nagy típust kell választani kulcsnak, amelybe belefér minden tervezett adat + ráhagyás.
-
#1694
Sk8erPeter
nagyúr
alratar
#1692
Sk8erPeter
nagyúr
válasz
alratar
#1692
üzenetére
"az id hosszúsága előbb-utóbb több tíz hosszúságú is lehet."
http://dev.mysql.com/doc/refman/5.0/en/integer-types.html
tartományok:signed int: -2147483648 - 2147483647
unsigned int: 0 - 4294967295 -
Akkor leírom, hogy miért is kellene ez.
Egy olyan adatbázist szeretnék csinálni, ahol futball játékosok neveit és adatait lehet felvinni.
És mivel, ugye a játékos állomány folyamatosan változik (eladják őket stb) így az id hosszúsága előbb-utóbb több tíz hosszúságú is lehet.
És ezt szettném kibekkélni! -
-
Bocs nem neked akartam válaszolni...
alratar: Primary ID-t nem lehet "egyszerűen" módosítani, mivel roncsolja az integritást. Ha fontos, hogy növekvő és folyamatos sorrend legyen, ikább érdemes egy generált mezőt használni (vagy egyszerűen kiiratásnál beszámozni a mezőket). AZ ID mezők nem erre valók, hanem hogy az adatkapcsolatokon keresztül az integritás (mi tartozik mihez) megmaradjon.
-
pvt.peter
őstag
Sziasztok!
Adott egy *.sql fájl, amely 723 sorból áll, és kizárólag táblák sémáját tartalmazza, tehát "CREATE TABLE ...".
Elég nehéz átlátni, hogy melyik mező mihez kapcsolódik, elég komplex MySQL adatbázis.
A kérdésem: van-e olyan alkalmazás, amely ezek alapján a tábla sémák alapján képes vizualizálni a kapcsolatokat a táblák között? idegen kulcsok, kulcsok stb.
Tlképpen olyanra gondolok, mint amikot MS Accessben az emberke az egyszerű táblákat összehúzgálja, melyik mező lesz a kulcs, stb. és ilyenkor látszódnak szépen a táblák illetve vonallal a kapcsolatok közöttük.
Itt egy [KÉP] róla, hogy mire is gondolok.Segítséget köszönöm,
Peti -
G.A.
aktív tag
válasz
martonx
#1671
üzenetére
Üdv!
Próbáltam úgy is, hogy a mezőnevek a CSV első sorában voltam, meg úgy is hogy nélküle.(ha ez a fejléc) Úgy is, hogy ha volt, akkor a feltöltéskor hagyja azt ki. Ezek nem jöttek be. Ami talán fontos és kimaradt, hogy ezt a gépemen lévő wamp-on próbáltam. Ezért kipróbáltam egy online adatbázison is, ott meg feltöltötte.
Ezt nem értem....Ha már sikerült feltöltenem lenne egy másik kérdésem.
Amit sikerült feltöltenem, azokban a magyar szöveget, ahol az ékezetes karakterek kezdődnek, onnantól levágja. Feltöltéskor az utf8-as karakterkészletet választottam, mivel a varchar-os mezők utf8_hungarian_ci-re vannak állítva. Itt mi a hiba?A másik, hogy vannak olyan mezők ahol tizedes számok is vannak. Ha jól tudom ott a mezőt decimálra kell állítani? (értékek pl.: 18.2, 5.5, 7.5, 0.5...)
GA
-
G.A.
aktív tag
Üdv!
Van egy kis szenvedni valóm phpmyadminon keresztül az adatbázis feltöltéssel.
SQL-be szeretném átvinni a CSV-ben elkészített táblázatot, de ez a hiba fogad:Érvénytelen oszlopszám a CSV bemenet 1. sorában.
Na nekem ez annyit jelent, hogy több vagy kevesebb oszlopom van valahol, ami nem igaz (csak 235535x számoltam meg).
Így igazából csak arra tudok tippelni, hogy valami baja van a táblázattal (valami hiányzik).
Ez a hibajelentés általában mire utal?
GA
-
#1669
pittbaba
aktív tag
Sk8erPeter
#1664
pittbaba
aktív tag
válasz
Sk8erPeter
#1664
üzenetére
Elég sokszor megtörténik
-
-
Jim-Y
veterán
Sziasztok
Kapok egy ilyen warningot MySQL alatt:
Data truncated for column 'VALAMI' at row 2
Egy osztás eredményét tartalmazza a VALAMI, .. ilyesmit: (A/B)*100
Jól gondolom, hogy ez azt jelenti, hogy sok tizedesjegyig számolja, de "csak" 4 tizedesjegyig írja ki? Ha igen, akkor hogy lehet a warningot kikerülni? -
#1665
martonx
veterán
Sk8erPeter
#1664
martonx
veterán
válasz
Sk8erPeter
#1664
üzenetére
LOL
-
#1663
pittbaba
aktív tag
Sk8erPeter
#1662
pittbaba
aktív tag
válasz
Sk8erPeter
#1662
üzenetére
Sorry, úgy gondoltam, alapból feltételezitek, hogy nem kérdezek olyankor, ha legalább minimálisan nem néztem utána, de legközelebb jelzem ezt.
-
#1662
Sk8erPeter
nagyúr
pittbaba
#1661
Sk8erPeter
nagyúr
válasz
pittbaba
#1661
üzenetére
De nézd meg az eredeti kérdésedet, abból nem az derül ki, hogy megpróbáltál volna minimális kutatómunkát is végezni kérdés előtt. Most érted, tök más, ha úgy kérdezed, hogy ezt meg azt találtam, és az alapján így meg úgy értelmezem, szerintetek így van-e, vagy ha tényleg nem találsz valamit, akkor megírod, hogy nem sikerült erről normális infót találnod, mintha egyszerűen rábízod másra az elméleti fejtegetést, vagy a találatok belinkelését (ahogy én is tettem, segítőszándékkal), hadd töltsön csak vele időt más helyetted...
Ezáltal vész el a dolog szakmaisága, mert onnantól kezdve nem egy dolog jobb/rosszabb megvalósíthatóságáról, lehetőségekről, ötletekről beszélgetünk, hanem szimplán olyan dologról, ami a dokumentációban is kicsi keresgélés alapján megtalálható. Az eredeti kérdésedben ezzel szemben érdekes problémát vetettél fel, kaptál is választ rá bőven. -
#1661
pittbaba
aktív tag
Sk8erPeter
#1660
pittbaba
aktív tag
válasz
Sk8erPeter
#1660
üzenetére
Lesz?
tizenx éve ezzel foglalkozok, és ebből élek, több szálon az rendben, nem egy valamihez értek nagyon, hanem a legtöbb igényelt munkát el tudom látni, és ennyi. Az hogy a msql legbelsőbb bugyraiban nem tudom, hogy a key, és a create index között van e időben vagy eljárásban különbség, nem okozott gondot még A legtöbb programozási nyelvet angolul tanultam én, az megvan, hogy mit kell nézni, meg bambulom a példákat, és ha átírok valamit mi változik szenvedések, viszont egy-egy komolyabban megfogalmazott mondat fölött átsiklik a tekintetem, ezért jobb, ha megkérdezem, de már kezdem megbánni 
-
#1659
pittbaba
aktív tag
Sk8erPeter
#1657
pittbaba
aktív tag
válasz
Sk8erPeter
#1657
üzenetére
Köszi! Az angolom még mindig nem perfect, ezért bizonytalan vagyok, hiába találom meg én is ezeket, de okay.
-
#1657
Sk8erPeter
nagyúr
pittbaba
#1656
Sk8erPeter
nagyúr
válasz
pittbaba
#1656
üzenetére
Javaslat: [link]
http://stackoverflow.com/questions/924265/what-does-the-key-keyword-mean
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
http://stackoverflow.com/questions/1401572/what-are-differences-between-index-v-s-key-in-mysql
http://www.quora.com/MySQL/What-is-the-difference-between-using-KEY-and-INDEX-in-MySQL
http://stackoverflow.com/questions/1071180/is-the-primary-key-automatically-indexed-in-mysql
http://www.quora.com/MySQL/What-is-the-difference-between-using-KEY-and-INDEX-in-MySQLAz a baj, hogy túl kevés az információ a zzzinterneten...
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
pittbaba
aktív tag
Az most fog eldőlni, majd reportolom. Egyébként ha nem is lesz gyorsabb, de legalább létre tudtam hozni egy jóval kisebb táblát, amiben benne vannak azok az adatok amik nekem kellenek. Az indexelés segített, hogy egyáltalán bármit tudjak kezdeni az adatbázissal 10-es limit nélkül
Kérdés:
Indexelésnél van e különbség, melyik a helyesebb:Új tábla hozzáadásánál KEY `stop_id` (`stop_id`),
vagy a tábla létrehozása után a CREATE INDEX trips_tripid_idx ON trips(stop_id) ?
-
pittbaba
aktív tag
Köszi mindenkinek az indexelés miatti nyaggatást, végig azt szúrtam el, tiszta lappal újra kezdtem, indexelve, végre tök gyorsan lefutnak a lekérdezések!
Kaptam a GTFS fórumon egy okosságot, arra a kérdésemre a választ, hogyan lehet kiszedni a GTFS formátumból azt, hogy egy megállón milyen járatok haladnak át (Az összes járat összes megállóját), megosztom veletek:
create table rstops as
select route_id, direction_id, a.stop_id, stop_name from
(select distinct route_id, direction_id, stop_id from stop_times as st, trips as t where st.trip_id=t.trip_id)
as a, stops as b where a.stop_id=b.stop_id order by 1,2; -
Jim-Y
veterán
válasz
Ablakos
#1649
üzenetére
MYSQL..
Értem, de sajnos nekem nem ez kell, hanem nekem annyi sorom kell legyen az eredménytáblában, ahány sorom van az A táblában
ahol a JOINolt érték megegyezik A.id = B.id, ott az eredménytáblában jelenjen meg egy új oszlopban B.int_value értéke.Az eredménytáblában ahol a joinolt értékek nem egyeznek, tehát A.id <> B.id ott az eredménytábla új oszlopában int_value értéke legyen 0, vagy NULL, vagy akármi, vagy ne jelenjen meg semmi.
-
Ablakos
addikt
Úgy értettem a kérdést, hogy az első táblából, minden rekordra szükséged van.
Én azt írtam: Az eredményhalmaz mérete legalább első tábla mérete lesz (feltéve, hogy valamelyik táblában nincs dupla a joinolt ID oszlopban). Ahol talál egyezőséget, ott a második tábla d oszlopát teszi le, ahol nincs egyezőség (null a rowid) ott 0 lesz.
Milyen környezetben kell a script?
-
#1648
Jim-Y
veterán
Apollo17hu
#1647
Jim-Y
veterán
válasz
Apollo17hu
#1647
üzenetére
Szia!
Köszi a választ.
a (+)-ra hibát dobott, enélkül pedig szintén csak 500 sorom lesz.. ergo ez még mindig nem jó
A lenti két táblából szeretnék kapni egy ilyen táblát:
C:
id,somevalue,somevalue2,int_value
1 ... ... 0
2 ... ... 0
3 ... ... 100
4 ... ... 101
5 ... ... 0
6 ... ... 0
7 ... ... 0Sajnos amit írtatok az nem ezt csinálja, hanem ahol A.id egyezik B.id-vel, csak azokat a sorokat eredményezi, így lesz 17000 sorból csak 500
-
Jim-Y
veterán
válasz
Ablakos
#1645
üzenetére
nem, inkább valami ilyesmi
A:
id,somevalue,somevalue2
1 ...
2 ...
3 ...
4 ...
5 ...
6 ...
7B:
id,int_value
3 100
4 101Eredményül egy olyan táblát szeretnék, ahol az A összes sora, és oszlopa benne van, plusz egy új oszlop "int_value"
ami 0, kivéve a 3-as és 4-es id-jű sorokban, ahol "int_value" értéke a B tábla megfelelő értékei, 100,101.
Remélem érthető valamennyire.
Mert most a fenti példára úgy működne
FROM A
JOIN B ON A.id = B.idszintaktika mellett, hogy az eredményben csak a 3,4 idjű sorok vannak benne, üdv
-
Jim-Y
veterán
Sziasztok
Egy olyan problémám lenne, hogy van két táblábám, mondjuk A oszlopaik a kulcsok,
1 táblában 17000 sor van, 2-es táblában ~600
ha simán JOIN-al összekötöm a kettőt a közös A oszlopon keresztül, akkor az eredményben ~ 500 sor lesz, nyílván ennyi sorban egyezik meg az A oszlopok értékei.Én olyat szeretnék csinálni az eredményben, hogy ha
megj:
1 tábla:
A,B,C2 tábla:
A,Daz 1.A = 2.A akkor az eredménybe 2.D kerüljön, egyébként 0. Az elvárásom az, hogy 17000 sorom legyen, ahol egyezik a két tábla A oszlopa ott ugye D értékkel, ahol nem ott 0. üdv
-
#1643
pittbaba
aktív tag
Sk8erPeter
#1642
pittbaba
aktív tag
válasz
Sk8erPeter
#1642
üzenetére
Hallgattam a tanácsokra, de szerintem az indexelés dolgot rosszul csinálom, kezd gyanús lenni.
Egyébként már felpakoltam idegnagy szerverre, szóval a vas része megoldódott, nem bosszantom tovább magam az arm procival,csak ha lesz egy céljaimnak megfelelő adatbázis. ( Bár android okosításba kezdtem, SQL feladat lett belőle ).Az indexeléssel kérdés:
Sajnos az id-k néhol betűt is tartalmaznak, így csak fulltext indexet enged a mysql. Fulltext indexet ráteszem a kellő mezőkre, ez is megvolt, de nem gyorsult érezhetően.
Újra kell indexeltetni valamilyen paranccsal a táblát? Vagy az adatokat is teljesen újra kellene tölteni a táblába?
Fórumon írnak sok mindent itt-ott, azt találtam REPAIR-el valahogy megoldható hogy a már táblában lévő tartalmat újraindexelje a mySQL.Indexelt táblákat dumpoltam ki a saját szerveremről a távoliba, de most ahogy nézem az export file-t nincs benne indexelés, nem hozta az export, így újra kell az egészet.
Végre Mysql-en tudok explain kimenetet adni:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE routes ALL NULL NULL NULL NULL 313
1 SIMPLE trips ALL NULL NULL NULL NULL 134307 Using where; Using join buffer
1 SIMPLE stop_times ALL NULL NULL NULL NULL 2555175 Using where; Using join buffer -
#1642
Sk8erPeter
nagyúr
martonx
#1641
-
#1641
martonx
veterán
Sk8erPeter
#1640
martonx
veterán
válasz
Sk8erPeter
#1640
üzenetére
hú bocs, igaziból kicsit elveszítettem a fonalat. Annyi volt a mellékes információ, hogy bevallom nyugodt szívvel kihagytam a kérdezőtől pár feleslegesnek vélt túl hosszú hszt.
Ez esetben teljesen jogos a felvetés, hogy pillanatok alatt mennie kellene a lekérdezésnek, ahogy ez másnál működik is. Valószínűleg már csak rendesen indexelni kell a db-t, és hasítani fog. -
martonx
veterán
-
pittbaba
aktív tag
Nem szükséges, csak kísérletezek ha már ..
Most egyelőre ott tartok, hogy négy lépésben egyszerűsítem a táblákat:
CREATE TABLE xy AS (SELECT col FROM a JOIN b .... )Minden szépnek és jónak tűnt, de valami mégsem jó, pl a Blahánál nem jár a 7-es busz az én adatbázisom szerint
Még át kell gondolom ezt kicsit...
-
#1635
pittbaba
aktív tag
Sk8erPeter
#1633
pittbaba
aktív tag
válasz
Sk8erPeter
#1633
üzenetére
A "hatalmas SQL adatbázis importálása sql fájlból probléma" megoldódott teljesen! Köszönöm, ez volt a leghelyesebb megoldás!
-
pittbaba
aktív tag
Sziasztok!
Újra itt, még mindig nyitva a [link] kérdésem, sok tanácsot kaptam az óta, de túl sok eredményt nem sikerült elérnem.
Szeretném valamilyen módszerrel leegyszerűsíteni az adatbázist, hogy kezelhetővé váljon.
Sajnos a 2,5 millió soros stop_times tábla az egyetlen módja, hogy összekapcsoljam bármelyik tábla adatait egy másikkal.
Röviden: GPS koordináta alapján szeretném megkapni a koordinátákhoz tartozó megállóhoz tartozó járatokat.
Ehhez az út: stops Join stop_times join trips join routes
Sajnos fél úton máris kiakad a mysql szerver, a routes táblához joinolva, már 1-es limitnél is hibát kapok vissza.
Ha csak a trip id-t akarom a stop_name mellett, 1000-es limitnél már hibát ír:SQL-kérés: Dokumentáció
SELECT stop_name, trips.trip_id
FROM stop_times
JOIN stops ON stop_times.stop_id = stops.stop_id
JOIN trips ON stop_times.trip_id = trips.trip_id
LIMIT 1000MySQL jelzi: Dokumentáció
#1317 - Query execution was interruptedSzerintetek milyen úton lenne érdemes leegyszerűsíteni a táblákat ahhoz, hogy a fent leírt feltételeket tudja az adatbázis teljesíteni.
-
#1632
martonx
veterán
trisztan94
#1605
martonx
veterán
válasz
trisztan94
#1605
üzenetére
De van. Egyrészt az nvarchar(max) enged bármennyit (na jó 2Gb vagy valami ilyesmi korlátja van).
Másrészt az indexlésükben van eltérés. A text-re tudsz tenni full-text search-öt, viszont text-ben nem tudsz olyan lazán like-al keresni mint varchar-ban.
Varchar-ban nem fog működni a full-text search viszont like-al kereshető.
Remélem jól írtam, nem kezdtem most el helyetted MSDN dokumentációt olvasni. -
#1631
trisztan94
őstag
trisztan94
őstag
-
#1630
pittbaba
aktív tag
Sk8erPeter
#1625
pittbaba
aktív tag
válasz
Sk8erPeter
#1625
üzenetére
Köszönöm, hogy rám szóltál, a link alatti kis php script nagyon szépen működik. Gyors, szép kód, jó megoldás!
-
pittbaba
aktív tag
Szia! Ez jónak tűnik, bár hasonlót csináltam én is, most egy egyben sql fájlt szeretnék berántani, hogy már ne kelljen táblákat csinálgatni.
A karakter cseréknél szerintem lenne gond egyébként, ahogy emlékszek, nekem ennyi csere nem volt elég valahol elszállt.
Asszem a stops.txt-ben van olyan állomásnév, ahol pl: "Csepel, Kis csőröge, Nagyállomás" a tartalom, replace után: '"Csepel',' Kis csőröge',' Nagyállomás"' És már rögtön több az érték mint az oszlop a sorban. -
pittbaba
aktív tag
Nem sokkal lőttél alá a teljesítménynek, nincs alám pakolva egy erőmű, és mivel a stop_times tábla 2,5 millió soros ( mint kiderült..
), még azt is megizzasztja. Helyi szerveren annyi előnyöm van, ha csinálok egy 10 perces lekérést, le tudom lőni az sql szervert, és nem kell várnom timeoutig minden alkalommal A szolgáltatóm phpmyadminja nem tud ilyet sajnos, én is ezt kerestem volna
Tudom, hogy csv-t is tud fogadni, viszont nem vágja hogy az első sorából táblát kéne csinálni, így gyorsabb az sql, mint megint kézzel megcsinálni a táblákat... -
#1627
pittbaba
aktív tag
Sk8erPeter
#1625
pittbaba
aktív tag
válasz
Sk8erPeter
#1625
üzenetére
Megnézem, remélem működni fog, köszönöm. Kerülni szerettem volna a plusz patkolásokat, azért írtam, hogy így is olyan messze vagyok az igazságtól, hogy nem szívesen veszek bele még még még plusz lépéseket, eszközöket, de remélem ez működni fog, majd reportolom
A megoldást ahogy írtam is, abban reméltem, hogy ha táblákra szétszedem a fájlokat, akkor már menni fog, mert kevesebb műveletet kell futtatnia egy kérés alatt. Egyel jobb is lett, viszont lett helyette másik korlát:
Got a packet bigger than 'max_allowed_packet' bytesEzért most jön a tipped kipróbálása.
-
válasz
pittbaba
#1623
üzenetére
Ez az én sufni-tuning megoldásom. Otthoni 4 éves gépen 114 mp., szerveren 46 mp. alatt töltötte be mysql-be a 112 mbyte-os fájlt. Indexeket nem állítottam be, mert úgy nagyon lassú volt.
<?php
$sorinsert=10000; // ennyi soronként insert mysql-be
$szerver='127.0.0.1';
$user='gtfsuser';
$pass='';
$adatbazis='gtfs';
$tabla='stop_times';
$file='stop_times.txt';
// kapcsolódás
if ( !mysql_connect($szerver, $user, $pass) ) { echo 'Nem érhetõ el a szerver.'; die(); }
if ( !mysql_select_db($adatbazis) ) { echo 'Nem érhetõ el a '.$adatbazis.' adatbázis.'; die(); }
mysql_query('TRUNCATE TABLE `stop_times`');
mysql_query('FLUSH TABLE `stop_times`');
$query=''; $ido=idopont();
// file betöltés
if ( !$fa=fopen($file, 'r') ) { echo 'Nem nyitható meg: '.$file; die(); }
$sor=fgets($fa, 256); $sorszam=0; // elsõ sor kihagyása
while ( !feof($fa) ) {
@set_time_limit(30);
$sor=fgets($fa, 256);
$sorszam++;
$sor=str_replace(",", "','", $sor);
if ( $query<>'' ) { $query.=', '; }
$query.=" ('".$sor."', '')";
if ( $sorszam==$sorinsert ) {
mysql_query('INSERT INTO '.$tabla.' VALUES '.$query);
echo $sorinsert.' sor beillesztve<br>';
$sorszam=0; $query='';
}
}
if ( $query<>'' ) { mysql_query('INSERT INTO '.$tabla.' VALUES '.$query); }
fclose($fa);
echo '<br>Eltelt idõ: '.idopont($ido);
// eltelt idõ
function idopont($t=0) {
list( $usec, $sec ) = explode(" ",microtime());
$ido=( (float)$usec+(float)$sec );
if ( $t===0 ) { return $ido; }
$s=(float)$ido-$t;
$s=round($s, 4);
return $s;
}
/*
CREATE TABLE IF NOT EXISTS `stop_times` (
`trip_id` varchar(20) COLLATE utf8_hungarian_ci NOT NULL,
`arrival_time` varchar(8) COLLATE utf8_hungarian_ci NOT NULL,
`departure_time` varchar(8) COLLATE utf8_hungarian_ci NOT NULL,
`stop_id` varchar(20) COLLATE utf8_hungarian_ci NOT NULL,
`stop_sequence` varchar(20) COLLATE utf8_hungarian_ci NOT NULL,
`shape_dist_traveled` varchar(20) COLLATE utf8_hungarian_ci NOT NULL,
`kulcs` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`kulcs`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci;
*/
?> -
#1625
Sk8erPeter
nagyúr
pittbaba
#1622
Sk8erPeter
nagyúr
válasz
pittbaba
#1622
üzenetére
Elolvastad a leírását annak, amit linkeltem?
A hsz.-edből nem úgy tűnt.Azt sem értem, miért feltételezed, hogy na majd a következő hsz.-edben írt scripted megoldja, ami csak annyit csinál, hogy egy az egyben beolvassa az egész dumpot, és megpróbálja lefuttatni a query-t. Miért feltételezed, hogy ennél majd nem ütközöl ugyanazokba a korlátokba?
-
modder
aktív tag
válasz
pittbaba
#1620
üzenetére
miért nem jó az otthoni lomhább szerveren sebességet tesztelni? gondolom nem egy 600Mhz-ces intel pentium III-ad van
A phpmyadminnak van olyan lehetősége, hogy bemásolsz egy fájlt az egyik könyvtárába a szerveren, és onnan veszi fel, így feltöltheted FTP-n a megfelelő könyvtárba, majd importnál kiválasztod a webes felületen. Azért még így is gondot fog okozni a valószínűleg 30 másodperces default php max execution time.
Egyébként nem kell konvertálni csv-ből sql-re, csv-t is tud importálni, és azt lehet, hogy könnyebben szétdarabolod egy egyszerű szkripttel.
Persze ha localhoston tesztelnél, akkor kényed-kedvedre állíthatnál a php exec timeon, és egyszerűbben bemásolhatnád a fájlt a phpmyadmin megfelelő könyvtárába. Felteszel egy Easy PHP-t, abban alapból van phpmyadmin, mysql szerver is, működik out of the box.
Ha tényleg nem egy tízéves az "otthoni lomhább gép", én inkább azon próbálkoznék, nem kell ehhez egy über szerver.
-
pittbaba
aktív tag
válasz
pittbaba
#1622
üzenetére
Megvan
db név után tábla névvel kell paraméterezni a mysqldump parancsot.
Kíváncsi vagyok így már megeszi e.
Amit próbálok php-ból, megosztom, hátha segít, vagy kiderül hogy rossz ( most kb 40 perc míg feltöltődik az új sql fájl, addig nem tudom tesztelni )$query = file_get_contents("filename.sql");
$ret = mysql_query($query) or die(mysql_error()); -
#1622
pittbaba
aktív tag
Sk8erPeter
#1621
pittbaba
aktív tag
válasz
Sk8erPeter
#1621
üzenetére
Jah csak az a bajom h az eredeti feladattól már annyira eltértem, hogy ilyen még az életben nem volt, most már ott tartok h a 100. szálon most adatbázis darabolós fájlonként egyesével importálgatósat kell játszani, ez botrány, hogy nem tud az ember egy 150 megás adatbázist átmozgatni szerverről szerverre. Megérteném 100 gigánál, de így...
Épp keresem, de hátha gyorsabban érkezik a válasz: mysqldump-nál van olyan, hogy táblánként dumpolja fájlba, mert találtam egy megoldást, de a maximum memóriaméretet 3 megával túl lépem, úgyhogy elég az egyik táblát külön venni, és elvileg megoldható lesz ( aztán lehet hogy tévedek ).
-
pittbaba
aktív tag
Sziasztok!
Na a fentebb említett problémával még mindig küzdök, nézem mi lehetne jó megoldás. Meguntam a 10 perces lekéréseket, serveren tesztelnék sebességet mysql-el hogy tudjak haladni, viszont a GTFS adatbázisát sehogy nem bírom betolni a távolni server adatbázisába.
Sajnos sima havidíjas tárhelyem van, semmi ssh lehetőség, így nem tudom megoldani azt, hogy a 150 mb-os adatbázist beimportáljam. A phpmyadmin lenne az egyetlen lehetőségem, de az sem tudja fogadni a 120 megás stops_times.txt-t. Csináltam az itthoni lomhább serveren egy adatbázist a GTFS-ből, SQL formátumban exportáltam, ezt a fájlt szeretném valahogy a távoli serverbe bepasszírozni, milyen megoldásokat tudtok ajánlani?
Próbáltam a LOAD DATA-val de nincs jogosultságom írni az adatbázist ezzel. Gondolom külön acc vonatkozik arra ami lenyúl a winyóra.Találtam olyan megoldást, hogy csinálok egy php fájlt, és mysql_query("source db.sql") parancsal beszippantom a file-t, de szintaktikai hibát ír:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SOURCE db.sql' at line 1
Elvileg ennek mennie kell? Hol a szintaktikai hiba? Vagy az elérési úttal lehet gondja? Csak az meg io hiba nem szintaktika.
Hogy lehetne ezt a 150 megát php-n keresztül megetetni vele? Már kifogyok az ötletekből
-
pittbaba
aktív tag
szerintem semmit sem gyorsított, valószínűleg ezért.. nem is értettem hogy működhet ilyen gyorsan az indexelés.. most már értem
tábla létrehozáskor kell indexelni és úgy nyomni a konvertálást. Akkor belepötyögöm a konverter appba, hogy indexeljen és lefekvés előtt elindítom, hátha gyorsabb lesz a db.Szerinted ha csinálok egy selectet where nélkül, összejoinolva a táblákat, majd a kimenetet feldolgozom úgy, hogy építek belőle egy újabb összegző táblát az nagyon gáz lesz, vagy az is egy lekérésnyi időt vesz majd igénybe? Nem tudom ez a része hogy működik.
-
modder
aktív tag
válasz
pittbaba
#1615
üzenetére
hát az, hogy a csv-t szépen betöltötted az adatbázisba korábban. Utána ahogy ajánlottuk rátettél a különféle mezőkre indexeket. Ez gyorsított valamit a dolgon? Arra akarok kilyukadni, hogy lehet nem fogja indexelni a már bent lévő adatokat, hanem ki kell ürítened a táblákat és újra betöltened ahhoz, hogy szépen felépítse az indexeket.
De ez csak egy erős tipp, egyáltalán nem értek az SQLitehoz
-
pittbaba
aktív tag
Szia!
Igen, pont ezzel kísérleteztem az elmúlt órában, hogy külön vettem a lekérdezéseket megnézem mi mennyi idő, de sajnos egy sima alap select is 10-30mp míg lefut a fájlban, nincs más választás.
Az indexel kapcsolatban sajnos nem értem a kérdésedet? Betöltöttem az adatokat? (Azok benne vannak már az indexelés előtt )
Hogy érted ezt? -
#1614
McSzaby
őstag
Andoidtibi
#1612
McSzaby
őstag
válasz
Andoidtibi
#1612
üzenetére
-
modder
aktív tag
válasz
pittbaba
#1611
üzenetére
ha csak egy szimpla szelektet csinálsz a stop_times táblában pl az időpontra vagy a stop_id-ra vonatkozóan az is lassú? Miután beállítottad az indexelést, újra betöltötted az adatokat a táblába? Azért járj utána egy kicsit hogyan működik az SQLite, ha nem töltötted be újra az adatokat, lehet nem is építette föl az indexet.
-
#1612
Andoidtibi
csendes tag
Andoidtibi
csendes tag
Helló jó estét ! valaki valamit erre a problémára tudna valamit mondani? Válaszotokat előre is köszönöm
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NOT NULL) ENGINE = myisam' at line 1
-
pittbaba
aktív tag
-
Jim-Y
veterán
válasz
martonx
#1608
üzenetére
Csak ha nincs az embernek mobilnete?
Én valahol a kettőt ötvözném, alapból egy webszolgáltatás lenne, amit mobilnettel teljes értékűként lehetne használni, de pl lehetne olyat, hogy az ember letöltse lokális adatbázisba az őt érdeklő járatokat, így offline is lehetne követni azokat a járatokat amit az ember használ.. talán..
-
martonx
veterán
válasz
pittbaba
#1606
üzenetére
Én is belebeszélhetek? Koncepcionálisan hibáztál.
Ne pöcsölj SQLite-al, egyszerűen nem erre való. Az egész DB-t told fel valahova a felhőbe, tegyél rá egy webszolgáltatást, vagy web api-t, és az android-os alkalmazásod meg hívogassa azon keresztül. Most komolyan te egy 600-1000 mhz-s kis fos telefon procitól várod el, hogy többszázezer soros, join-olt SQLite db-ből találjon meg bármit is pillanatok alatt? Indexelheted ezt akárhogy, akkor is megfőzöl egy kávét, amíg szegény kis proci végignyálazza akár csak az indexeket. -
modder
aktív tag
válasz
pittbaba
#1606
üzenetére
Értem, igazad van. Ezt már nincs kedvem végiggondolni, hogy pontosan hogyan lenne érdemes megcsinálni a kereséseket úgy, hogy a legközelebbi olyan megállót adja meg, ahol adott járat szám megáll, de szerintem adtam ötleteket. A lényeg, hogy mindig jól gondold végig, hogy mi kell, és fölöslegesen ne joinolj táblákat, fölösleges infot ne tegyél bele a selectbe.
Ja, az indexelést se állítsd be minden oszlopra, hátha kell alapon, mert az plusz tárhely, és nem fog mindig gyorsulást okozni a lekérdezésekben.A tábladarabolással kicsit elszaladt velem a ló, csak akkor kezdj bele, ha látod, hogy egyébként lassúak a lekérdezéseid. Szívesen!
-
pittbaba
aktív tag
Wow! Köszönöm a rengeteg infót, átrágom rajta magamat részletesen is.
Első körben annyit, hogy azért lenne jobb a három tábla összekapcsolása, mert nekem GPS alapján az lenne jó, ha a a lehetséges járatnevek jönnének ki, ne kelljen megállót választania külön. Általában az ember azt tudja mire akar, mire kell felszállni és nem a megálló pontos nevét.A group-ban teljesen bizonytalan voltam, azt köszönöm hogy tisztáztad a fejemben.
Az indexelésekkel kezdem, majd a stop_times feldarabolása lesz következő lépés az optimalizálás terén, én is azt találtam jónak,ha stop_id alapján szedem széjjel.Még egyszer nagyon köszönöm! Ha bármilyen ötleted van még ,írd meg.
-
#1605
trisztan94
őstag
trisztan94
őstag
Sziasztok!
MsSql-be szeretnék nagy stringet, akár 10.000 karaktereset bevinni. Eddig ntext adattípust használtam, de több helyen is olvastam, hogy a nvarchar sokkal jobb, biztonságosabb. Ez igaz? A baj vele az, hogy az nvarchar az 4000 karaktert engedélyez maxon, míg az ntext az akármennyit (ha jól tudom).
Mit lehet használni ezeken kívül?Köszi,
T -
modder
aktív tag
válasz
pittbaba
#1596
üzenetére
kíváncsiságból én is feltettem notin mysql-be betöltöttem, és elkezdtem futtatni a lekérdezésedet. Nem tudtam végigvárni
1) Ez egy viszonylag normalizált adathalmaz, de nem feltétlenül lesz jó keresések szempontjából
2) mivel az adatbázis csak lekérdezésre lesz használva, simán megcsinálhatod, hogy létrehozol különböző táblákat, amik a keresést megkönnyítik: a relációkat denormalizálod, azaz egy adat, és az adatok közötti függőségek többszörösen lesznek letárolva. Ezzel azt nyered, hogy gyorsabban fogsz tudni keresni.
A "csak lekérdezéseket" azért emeltem ki, mert így nem kell majd azzal foglalkoznod, hogy az újonnan beszúrt adatok elrontják-e az adatbázist. Például az egyik táblába beszúrod, de a másikba elfelejted, satöbbi.3) Igen, az indexelés, amit már említettek. A megálló nevére rá kell tenned egy indexet mindenképpen, ha így keresel, viszont nem hiszem, hogy SQLiteban van fulltext index: azaz szövegen belüli indexelés. Mivel LIKE %valami%-kal keresel, mindenképpen be fogja olvasni a rekordot, belemászik a szövegbe, és rákeres a szövegrészletre, szóval hiába indexeled, semmit nem fog érni. Max akkor, ha tökéletes egyezést keresel.
Többi indexelés:
-- stops.stop_id elsődleges kulcs, állítsd be annak, vagy tegyél rá egy indexet;
-- stop_times.trip_id -ra és stop_times.stop_id -ra külön-külön tegyél egy indexet;
-- trips.trip_id -ra tegyél egy indexet
azért ezekre, mert ezek azok az oszlopok, amik mentén te joinolsz, és ezek által az id-k alapján fog keresni az adatbázis.ezekkel az indexekkel nekem a keresés 3 másodperc alatt lefutott laptopon. telefonon nem tudom milyen lesz...
Konkrétizálva:
Te most azt csinálod, hogy rákeresel a megálló nevére, majd megálló id alapján groupolod egy másik tábla oszlopa alapján, hogy ha egy utcában több megálló is van, azokat is megkapd. Ezzel még csak a megállókat találod meg, de nem nyersz információt az áthaladó trippekről. Az információ amire valójában szükséged van az a megálló_neve, megálló_id.Ehhez képest te összejoinolod mind a három táblát. tegyük fel, hogy a stops táblából megtalálja a megfelelő sorokat amik pl az Örs vezér tere-re stimmelnek, ez lesz pl 10 sor, akkor szépen elkezdi végigkeresni a másik két táblában a hozzájuk tartozó sorokat, de a trip_id és a departure_time nem fog információt hordozni, mert groupoltad az egészet stop_id alapján, szóval egy megállóhoz csak egy trip_id-t fog kiadni... szóval ez így teljesen rossz.
Ami neked kell ebben az esetben:
SELECT stop_name,stops.stop_id FROM stops WHERE stops.stop_name LIKE '%Örs%' GROUP BY stops.stop_idViszont te GPS alapján akarod megtalálni, ez is jó lesz. Indexelned kell a stop_lat és stop_lon mezőket, és lekérdezed úgy, ahogy írtad. Csak a megállót! Akkor felhasználó kiválasztja a pontos megállót, így az átmenő trip-eket már csak az alapján kell keresned (fölösleges a közelben lévő megállókon átmenő tripeket is megkeresni).
Átmenő trippek:
SELECT * FROM `stop_times` WHERE stop_times.stop_id = valami and `departure_time` > "06:00:00"Optimalizálás:
Visszatérve ahhoz, amit a legelején írtam a denormalizálásról. Nekem ezek a lekérdezések a belinkelt adathalmazon elég gyorsan lefutottak, de telefonon lehet, hogy más lesz a helyzet. Először próbáld ki rendesen indexekkel, hogy milyen eredményeket kapsz, és ha nem jók, akkor el lehet kezdeni szétdarabolni pl. a stops táblát 10 külön táblára, ezt hívják particionálásnak. Feltéve, hogy az SQLite van olyan intelligens, hogy nem olvassa be a memóriába az egész adatbázis fájlt, hanem beindexeli hogy melyik tábla hol kezdőik a fájlban, ezzel rendesen meg tudod gyorsítani a dolgokat.Például szétdarabolod a stops táblát 10 táblára a stop_name szerint egyenletes eloszlásban, alfabetikusan növekvő sorrendben. Amikor név alapján akar keresi, tudni fogod egyből, hogy melyik táblában keress, mert tudod, hogy melyik tábla mettől meddig tartalmaz stop_name elemeket. Ez ugye csak név alapján keresésnél hasznos, úgy ha a felhasználótól elvárod, hogy a begépelt megállónévnek az eleje egyezzen valamelyik megállónévvel.
A stop_times feldarabolása. Mivel ez a tábla rohadt nagy, ezzel is tudsz nyerni időt. Én a stop_id alapán darabolnám fel szintén alfabetikusan hasonlóan ahogy az előbb írtam, el tudod dönteni már a stop_id alapján, hogy melyik táblában keress.
miért stops.stop_name és stop_times.stop_id alapján darabolj, és ne pl stops.stop_lan és stop_times.departure_time alapján? Azért mert az SQLite valószínűleg BTREE indexelést alkalmaz, ami nagyon jó intervallum keresésre. Alkalmazható számon, dátumon, talán még szövegen is! Viszont nem találtam , hogy lenne SQLiteban hash indexelés, ami arra jó, ha szeretnél megtalálni egy elemet konkrét értékkel. Ilyen az, amikor id-k alapján joinolsz. Amikor meg akarod keresni az adott stop_id-n áthaladó járatokat a stop_times táblában adott időponton belül, akkor megkönnyíted az adatbáziskezelő dolgát azzal, ha a particionálással 200e sor helyett csak 20e-ben kell keresnie.
Persze ez csak elmélet. az egész attól is függ, hogy a stop_times táblában először intervallumkeresést hajt végre az időpontra, és utána választja ki stop_id alapján a sorokat, vagy fordítva, de ezt már nem tudom, ki kell próbálni.
Azért jó lehetőség ez az adathalmaz optimalizálásra, mert nincsenek komplikált lekérdezések, csak egy-két féle, így ki lehet alakítani úgy a struktúrát, hogy ezeknek teljesen megfeleljen. Még ami eszembe jutott, hogy az adatbázisok általában elsődleges kulcs szerint teszik sorrendbe az adatokat fizikailag. Szóval ha a stop_times táblában (stop_id, trip_id) -t adsz meg elsődleges kulcsnak ebben a sorrendben, akkor megegyszerűsítheted az adatbáziskezelő dolgát, amikor stop_id alapján keresel, mert az ugyanahhoz a stop_id-hoz tartozó rekordok egymás mögött lesznek elhelyezkede, tehát szekvenciálisan gyorsan ki tudja olvasni az összeset.
De amúgy az is lehet, hogy simán az indexekkel tökéletesen gyorsan fog működni telefonon is, és az egész novella, amit leírtam teljesen fölösleges
-
#1603
pittbaba
aktív tag
Sk8erPeter
#1599
pittbaba
aktív tag
válasz
Sk8erPeter
#1599
üzenetére
Az explain kimenetéből mire vagy kíváncsi? Nem tudom copyzni a kezelőprogrammal sajnos, de ami fontos azt bepötyögöm.
-
#1602
pittbaba
aktív tag
Sk8erPeter
#1601
pittbaba
aktív tag
válasz
Sk8erPeter
#1601
üzenetére
Rendben
az Explain kimenetét majd mutatom, ha egyszer kikergeti.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- DELL PowerEdge R740 rack szerver - 2xGold 6130 (16c/32t, 2.1/3.7GHz), 64GB RAM, 10Gbit HBA330, áfás
- GYÖNYÖRŰ iPhone 12 Mini 128GB Blue-1 ÉV GARANCIA -Kártyafüggetlen, MS4209, 94% Akksi
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
- KARÁCSONYI AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24
- Jawbone Up okoskarkötő, aktivitásmérő
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi