DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
En een ORDER BY ID voor het geval dat niet de default is.quote:Op maandag 1 december 2014 17:24 schreef KomtTijd... het volgende:
als je gewoon een query maakt met LIMIT(0,100), dan heb je dat toch?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
quote:Op maandag 1 december 2014 17:24 schreef Monolith het volgende:
[..]
Je wilt dus gewoon 'de eerste 100' hebben?
Het probleem daarmee is dat er dan onnodige gegevens behouden blijven, en dat is niet wat ik wil bereiken.quote:
als je gewoon een query maakt met LIMIT(0,100), dan heb je dat toch?
100.000 katjes
Fuck the EBU!
Fuck the EBU!
Welke onnodige gegevens blijven er behouden?quote:
[..]
[..]
Het probleem daarmee is dat er dan onnodige gegevens behouden blijven, en dat is niet wat ik wil bereiken.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Ik ben altijd groot voorstander van het zoveel mogelijk bewaren van (onnodige) gegevens. Waarom weggooien als je er geen last van hebt.
Inderdaad.quote:
Ik ben altijd groot voorstander van het zoveel mogelijk bewaren van (onnodige) gegevens. Waarom weggooien als je er geen last van hebt.
Vooral in een database waar alles toch netjes gestructureerd is.
quote:Op maandag 1 december 2014 17:14 schreef KomtTijd... het volgende:
Goftedomme zeg. Moet ineens hals over kop wat klussen aan een oude applicatie (die er over een paar maanden hopelijk uit gaat), blijkt gewoon 3 kwart van de tabellen geen enkele index te hebben. Goh, dus daarom duren de queries een halve seconde
Ik ben altijd wel blij als het zo iets banaals is, klik klik klik, klaar.
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.
Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
100.000 katjes
Fuck the EBU!
Fuck the EBU!
Je data kun je super makkelijk selecteren met query's, dus de hoeveelheid maakt niet zoveel uit.quote:
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.
Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Gewoon softdeleten, heeft bij mij vaak ook de voorkeur boven verwijderen.quote:
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.
Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Dat wel ja. Gelukkig loop ik nog tegen genoeg andere problemen aan om dat weer te compenserenquote:Op maandag 1 december 2014 18:09 schreef TwenteFC het volgende:
[..]
Het is ook niet de bedoeling dat je dagelijks via database-management tools in de database gaat kijken of je data er niet slordig uit ziet. Databases zijn er niet om er netjes uit te zien, daar heb je je queries voor.quote:
Denk dat ik die makkelijke oplossing van het niet verwijderen maar neem.
Voor mijn gevoel staat dat juist slordig, maar ik ben dan nog niet erg into de php/mysql.
Dit moet ik mijn baas ook nog wel eens uitleggen
Nou ja, het kan natuurlijk wel degelijk voor traagheid zorgen wanneer overbodige data niet wordt opgeruimd.quote:
[..]
Dat wel ja. Gelukkig loop ik nog tegen genoeg andere problemen aan om dat weer te compenseren
[..]
Het is ook niet de bedoeling dat je dagelijks via database-management tools in de database gaat kijken of je data er niet slordig uit ziet. Databases zijn er niet om er netjes uit te zien, daar heb je je queries voor.
Dit moet ik mijn baas ook nog wel eens uitleggen
Zeker bij grotere hoeveelheden data wordt archiveren of aggregeren op een gegeven moment gewoon noodzaak.
Het voordeel van niet verwijderen maar bijvoorbeeld met een deleted flag te werken is dan weer dat je de data gewoon weer zichtbaar kunt maken.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Wat is nou een relaxte databasetool voor als je PHPMyAdmin zat begint te raken?
Webbased of linux, en een beetje eenvoudig en overzichtelijk. Heb wel eens wat met HeidiSql maar die vond ik ook irritant (en lelijk).
[ Bericht 48% gewijzigd door KomtTijd... op 09-12-2014 15:41:18 ]
Webbased of linux, en een beetje eenvoudig en overzichtelijk. Heb wel eens wat met HeidiSql maar die vond ik ook irritant (en lelijk).
[ Bericht 48% gewijzigd door KomtTijd... op 09-12-2014 15:41:18 ]
Gewoon MySQL workbench?quote:
Wat is nou een relaxte databasetool voor als je PHPMyAdmin zat begint te raken?
Webbased of linux, en een beetje eenvoudig en overzichtelijk. Heb wel eens wat met HeidiSql maar die vond ik ook irritant (en lelijk).
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Alleen jammer dat het zo'n vreselijk trage en buggy applicatie is. Vind Sequel Pro ook wel fijn werkenquote:
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik doe zelf eigenlijk erg weinig DBA werk de laatste jaren, zeker op SQL gebied. Hooguit wat met RoboMongo en dergelijke.quote:Op dinsdag 9 december 2014 16:31 schreef robin007bond het volgende:
[..]
Hier heeft het de bijnaam MySQL CrashBench gekregen.
Kun je wel mooie ERD's in maken.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo.
Op zich is PhpStormPhpMyAdmin prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.
[ Bericht 5% gewijzigd door KomtTijd... op 09-12-2014 17:55:19 ]
Op zich is PhpStormPhpMyAdmin prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.
[ Bericht 5% gewijzigd door KomtTijd... op 09-12-2014 17:55:19 ]
Waarom ben je phpmyadmin zat dan?quote:
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo.
Op zich is PhpStorm prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.
Leuk dat je PHPStorm wegstreept, je kan in PHPStorm je database sources toevoegen en dan heb je daar ook een autocomplete op.quote:
Ik hoef niets ingewikkelds, moet gewoon af en toe kunnen zien wat er in de database gebeurt als ik mijn code uitvoer. Of wat testrecords verwijderen ofzo.
Op zich is PhpStormPhpMyAdmin prima, maar het zit zó ongelooflijk vol met allerhande glitches... pfft je wordt er gewoon moe van.
Verder gebruik zelf ook HeidiSQL zoals Rockfire zegt.
ik wil graag uit verschillende folders 1 image halen
heb nu dit, maar dan krijg ik toch alle foto's te zien
met toevoegen van => $value kom ik er ook niet aan uit
Hie kan ik dit het beste oplossen?
heb nu dit, maar dan krijg ik toch alle foto's te zien
met toevoegen van => $value kom ik er ook niet aan uit
Hie kan ik dit het beste oplossen?
| 1 2 3 4 5 6 7 8 9 | <?php $dirname = "fotoalbum/fotoalbum/*/"; $images = glob($dirname."*.JPG"); foreach($images as $image) { if ($image == 0) { echo '<img src="'.$image.'" />'; } } ?> |
Je checkt niet op index.quote:
ik wil graag uit verschillende folders 1 image halen
heb nu dit, maar dan krijg ik toch alle foto's te zien
met toevoegen van => $value kom ik er ook niet aan uit
Hie kan ik dit het beste oplossen?
[ code verwijderd ]
Value is de index. Je wil altijd alleen de eerste index hebben, dus moet je value checken op 0.quote:
[..]
[ code verwijderd ]
iets in deze richting?
[ Bericht 1% gewijzigd door #ANONIEM op 29-12-2014 22:10:35 ]
quote:
[..]
Value is de index. Je wil altijd alleen de eerste index hebben, dus moet je value checken op 0.
| 1 2 3 4 5 6 7 8 9 10 | <?php dan zou ik verwachten zoiets $dirname = "fotoalbum/fotoalbum/*/"; $images = glob($dirname."*.JPG"); foreach($images as $image => $value) { if ($value == 0) { echo '<img src="'.$image.'" />'; } } ?> |
maar dan krijg ik alle indexen te zien volgens mij
nog even doorspelen
nog een duidelijk tip?
als ik dit aanpas
| 1 2 3 4 | <?php if ($image == 0) { echo '<img src="'.$value.'" />'; ?> |
dan krijg ik wel de eerste foto, maar alleen van de folder
bijna een snelle edit gedaan...heb ik dus gedaanquote:
value => image in plaats van andersom.
maar dan krijg ik alleen de eerste foto van de eerste folder
Ja of je echo't gewoon $images[0] 
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
dan moet je eerst een readdir doen van de root map, door de mappen loopen en per map de afbeeldingen ophalen en de eerste tonen.quote:
[..]
bijna een snelle edit gedaan...heb ik dus gedaan
maar dan krijg ik alleen de eerste foto van de eerste folder
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Even uitzoeken hoe globs werken en dan toepassen op je directory structuur. In een glob matcht ** alles inclusief directory separators en * alles behalve directory separators.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Die had ik al eens geprobeerd, maar dan krijg ik een loop van foto1 uit folder1, geen andere foldersquote:
Zeker waarquote:Laat TS ff lekker kutten met arrays, anders snapt hij het nooit
Voor als iemand testgegevens nodig heeft:
http://www.generatedata.com/
http://www.generatedata.com/
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
When the student is truly ready, the teacher will disappear.
https://github.com/fzaninotto/Fakerquote:Op maandag 12 januari 2015 11:44 schreef Aether het volgende:
Voor als iemand testgegevens nodig heeft:
http://www.generatedata.com/
Korte vraag mbt zoeken op grote tabellen.
Voor een vriend mag ik een importeer scriptje schrijven voor het importeren van ruim 7 miljoen videos met oa de volgende gegevens titel, tags, duur
Nu heb ik al een scriptje geschreven die dit alles importeert in een database tabel waarbij ik titel, tags als fulltext indexeer en wil apart daarvan de duur (lengte van het filmpje) ook nog gaan indexeren (zodat de gebruiker daar ook op kan zoeken)
Nu heb ik net een query uitgevoerd op deze tabel en dat duurde echt erg lang
Tabel: 7,217,116 MyISAM latin1_swedish_ci 4,8 GiB
Nu duurt de volgende query:
erg lang (zo'n 10 seconden).
Met limit 0,30 duurt deze query 0.0240 secs
Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
Voor een vriend mag ik een importeer scriptje schrijven voor het importeren van ruim 7 miljoen videos met oa de volgende gegevens titel, tags, duur
Nu heb ik al een scriptje geschreven die dit alles importeert in een database tabel waarbij ik titel, tags als fulltext indexeer en wil apart daarvan de duur (lengte van het filmpje) ook nog gaan indexeren (zodat de gebruiker daar ook op kan zoeken)
Nu heb ik net een query uitgevoerd op deze tabel en dat duurde echt erg lang
Tabel: 7,217,116 MyISAM latin1_swedish_ci 4,8 GiB
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | CREATE TABLE IF NOT EXISTS `videos` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `site_id` int(10) unsigned NOT NULL, `video_id` varchar(64) NOT NULL, `tags` varchar(255) NOT NULL, `uploaddate` datetime NOT NULL, `title` varchar(255) NOT NULL, `description` text NOT NULL, `thumbnail` varchar(255) NOT NULL, `url` varchar(255) NOT NULL, `embed` varchar(255) NOT NULL, `seconds` int(10) unsigned NOT NULL, `lastview` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `ratingcount` int(10) unsigned NOT NULL, `ratingtotal` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `site_id` (`site_id`), FULLTEXT KEY `tags` (`tags`), FULLTEXT KEY `title` (`title`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=7217117 ; |
Nu duurt de volgende query:
| 1 2 | SELECT COUNT( 1 ) FROM (SELECT * FROM `videos` WHERE `tags` LIKE '%home%') t |
Met limit 0,30 duurt deze query 0.0240 secs
Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Ik zou sowieso de tags los opslaan in een andere tabel, in plaats van als één string in een kolom. Dus tag-video_id paren. Dat zal inderdaad al een stuk sneller worden.
Smile like you mean it
www.wefut.com
www.wefut.com
Een LIKE beginnend met % is altijd traag. Tags in een aparte tabel en een koppeltabel tussen tags en videos is de beste oplossing. Dat scheelt je ook nog een boel dubbele data.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Ik heb zelf slechte ervaringen met zoeken in grote tabellen, zowel MyISAM als InnoDB.quote:
Korte vraag mbt zoeken op grote tabellen.
Voor een vriend mag ik een importeer scriptje schrijven voor het importeren van ruim 7 miljoen videos met oa de volgende gegevens titel, tags, duur
Nu heb ik al een scriptje geschreven die dit alles importeert in een database tabel waarbij ik titel, tags als fulltext indexeer en wil apart daarvan de duur (lengte van het filmpje) ook nog gaan indexeren (zodat de gebruiker daar ook op kan zoeken)
Nu heb ik net een query uitgevoerd op deze tabel en dat duurde echt erg lang
Tabel: 7,217,116 MyISAM latin1_swedish_ci 4,8 GiB
[ code verwijderd ]
Nu duurt de volgende query:
[ code verwijderd ]
erg lang (zo'n 10 seconden).
Met limit 0,30 duurt deze query 0.0240 secs
Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
Is dit misschien een optie? http://astellar.com/2011/(...)-search-with-sphinx/
Ik ga eens een import draaien die tags in een apart tabel zetten + een tabel voor video/tag links. Eens kijken hoe lang dit gaat duren...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
LIKE negeert sowieso de fulltext index. Wil je daar gebruik van maken, dan kun je bijvoorbeeld MATCH gebruiken, zie ook de documentatie.
Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
quote:
Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
Een tijd terug voor het eerst met ElasticSearch gewerkt 
gaat inderdaad écht bloedsnel. Automatisch aanvullen en suggesties geven snel.
Het duurde ff maar dan heb je ook wat.
304k aan tags
kleine 69miljoen tag links
Nu nog een leuke query browsen...
304k aan tags
kleine 69miljoen tag links
Nu nog een leuke query browsen...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Je kunt het iets beter krijgen door geen subquery te gebruiken:quote:
Nu duurt de volgende query:
[ code verwijderd ]
erg lang (zo'n 10 seconden).
Met limit 0,30 duurt deze query 0.0240 secs
Is er een mogelijkheid om deze query sneller te maken? eventueel tags in een apart tabel?
| 1 | SELECT COUNT( * ) FROM `videos` WHERE `tags` LIKE '%home%' |
Da's zeker een optie die het overwegen waard is, helemaal omdat het over redelijk grote datasets gaat.quote:
Zoals echter al aangegeven kun je beter een search platform gebruiken als SOLR, ElasticSearch, Sphinx, etcetera.
Klopt Light!
Echter heeft de hosting waar dit straks moet gaan draaien blijkbaar geen zoekplatformen of de mogelijkheid daarvoor, ik ga eerst eens spelen met tags en kijken hoe ik daar het meeste uit kan halen. Eventueel het tijdelijk opslaan van data sets... zodat hergebruik stukken sneller gaat...
Echter heeft de hosting waar dit straks moet gaan draaien blijkbaar geen zoekplatformen of de mogelijkheid daarvoor, ik ga eerst eens spelen met tags en kijken hoe ik daar het meeste uit kan halen. Eventueel het tijdelijk opslaan van data sets... zodat hergebruik stukken sneller gaat...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Die tags in een aparte tabel opslaan is alvast een stap, mits je de indexes goed zet en gebruikt.quote:
Klopt Light!
Echter heeft de hosting waar dit straks moet gaan draaien blijkbaar geen zoekplatformen of de mogelijkheid daarvoor, ik ga eerst eens spelen met tags en kijken hoe ik daar het meeste uit kan halen. Eventueel het tijdelijk opslaan van data sets... zodat hergebruik stukken sneller gaat...
Maar je zit tegen de grenzen van wat met MySQL mogelijk is en als je spannendere dingen wilt, moet je op zoek naar een hoster die wel een zoekplatform aanbiedt (of zelf de hosting doen).
