De tabel waar die regel in staat heeft een foreign key constraint met de unieke naam image_fk. De waarde in de kolom image_id verwijst naar een waarde in de kolom image_id in de tabel image. Je kunt dus geen waarde opslaan die niet ook in image.image_id staat.quote:Op maandag 19 januari 2015 20:18 schreef Chandler het volgende:
-- gelijk een vraagje
Kan iemand mij deze regel uitleggen?
CONSTRAINT `image_fk` FOREIGN KEY (`image_id`) REFERENCES `image` (`image_id`),
1 2 3 | 1 SIMPLE t range PRIMARY,name,id name 34 NULL 2 Using index condition; Using temporary; using filesort 1 SIMPLE bt ref PRIMARY,video_id video_id 4 asexfilmzoeker1.t.id 488020 Using index 1 SIMPLE b eq_ref PRIMARY PRIMARY 4 asexfilmzoeker1.bt.video_id 1 NULL |
1 2 3 4 5 | Actie Sleutelnaam Type Unieke waarde Gecomprimeerd Kolom Kardinaliteit Collatie Leeg Opmerking Wijzigen Wijzigen Verwijderen Verwijderen PRIMARY BTREE Ja Nee video_id A Nee tag_id 48802076 A Nee Wijzigen Wijzigen Verwijderen Verwijderen video_id BTREE Nee Nee tag_id A Nee video_id A Nee |
1 2 3 4 5 | Actie Sleutelnaam Type Unieke waarde Gecomprimeerd Kolom Kardinaliteit Collatie Leeg Opmerking Wijzigen Wijzigen Verwijderen Verwijderen PRIMARY BTREE Ja Nee id 44810 A Nee Wijzigen Wijzigen Verwijderen Verwijderen name BTREE Ja Nee name 44810 A Nee Wijzigen Wijzigen Verwijderen Verwijderen id BTREE Nee Nee id 44810 A Nee name 44810 A Nee |
1 2 3 4 5 | Actie Sleutelnaam Type Unieke waarde Gecomprimeerd Kolom Kardinaliteit Collatie Leeg Opmerking Wijzigen Wijzigen Verwijderen Verwijderen PRIMARY BTREE Ja Nee id 7158720 A Nee Wijzigen Wijzigen Verwijderen Verwijderen seconds BTREE Nee Nee seconds 73801 A Nee Wijzigen Wijzigen Verwijderen Verwijderen tags FULLTEXT Nee Nee tags 1 Nee Wijzigen Wijzigen Verwijderen Verwijderen title FULLTEXT Nee Nee title 1 Nee |
Die staat in mijn 1e quote.quote:Op vrijdag 23 januari 2015 18:47 schreef TwenteFC het volgende:
Een ander type database gebruiken?
Zou je ook eens een explain van je query kunnen posten?
7 miljoen? beetje te veel, maar je zit aardig in de buurtquote:
Welke storage engine gebruik je? Heb je bijvoorbeeld al InnoDB geprobeerd?quote:Op vrijdag 23 januari 2015 19:47 schreef Chandler het volgende:
[..]
Die staat in mijn 1e quote.
Het rare is namelijk dat zoeken in tabel videos, veld tags (like %tag%) vele malen sneller is dan het uitlezen van tags tabellen (normaliseren).op dit moment geen mogelijkheid om een andere server/scripts te gebruiken anders dan MySQL.......
Wil wel even een dump maken hoorstrip ik alle onnodige informatie, heb je een import sql bestand van 4GB
![]()
En waarom zou dat gaan helpen? Zoals al aangegeven is de beste optie om gewoon een fatsoenlijk zoekplatform te gebruiken, maar die mogelijkheid heeft hij niet.quote:Op zaterdag 24 januari 2015 11:47 schreef robin007bond het volgende:
Sowieso MariaDB in plaats van MySQL
Het was meer een zijspoor.quote:Op zaterdag 24 januari 2015 11:58 schreef Monolith het volgende:
[..]
En waarom zou dat gaan helpen? Zoals al aangegeven is de beste optie om gewoon een fatsoenlijk zoekplatform te gebruiken, maar die mogelijkheid heeft hij niet.
1 2 3 4 5 6 7 8 | explain SELECT * FROM videos o LEFT OUTER JOIN video_tag_link ot ON ot.video_id = o.id LEFT OUTER JOIN tags t ON t.tag_id = ot.tag_id WHERE t.name IN ('home','alone') GROUP BY o.id HAVING COUNT(DISTINCT t.name) = 2 |
quote:Op zaterdag 24 januari 2015 13:28 schreef Chandler het volgende:
Jeej,
Volgende query doet het best
[ code verwijderd ]
Doet ook aan filesort maar vind in totaal 5638 resultaten in ruim 1 seconde...
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.The people who lost my respect will never get a capital letter for their name again.
Like trump...
Inmiddels een workaround gevonden, nu blijf ik weer hangen bij de melding "Notice: Array to string conversion". Als iemand dat bekend voor komt, laat even weten hoe je dat hebt opgelostquote:Op zondag 25 januari 2015 00:10 schreef henrivo het volgende:
Jeuw. Symfony2 kenners hier?
Wanneer ik form_row a en b oproep in een view, worden direct eronder ook meteen form_row c en d weergegeven. Terwijl ik die niet wil laten zien in die view.
{{ form_start(form) }}
{{ form_row(form.a) }}
{{ form_row(form.b) }}
{{ form_end(form) }}
Even als voorbeeldje hoe ik het heb
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.
quote:Op zondag 25 januari 2015 11:09 schreef henrivo het volgende:
[..]
Inmiddels een workaround gevonden, nu blijf ik weer hangen bij de melding "Notice: Array to string conversion". Als iemand dat bekend voor komt, laat even weten hoe je dat hebt opgelostDat komt door de regel:SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.De documentatie schrijft voor:
1 {{ form_end{form) }} Array to string conversion notice komt simpelweg doordat je ergens een array als argument meegeeft terwijl er een string wordt verwacht (zonder code gaan wij niet kunnen uitvinden waar dat vandaan komt).quote:form_end()
Renders the end tag of the form and any fields that have not yet been rendered, in case you rendered each field yourself. This is useful for rendering hidden fields and taking advantage of the automatic CSRF Protection.
Helemaal overheen gelezen, domdomdomquote:Op zondag 25 januari 2015 17:59 schreef Diabox het volgende:
[..]
Dat komt door de regel:
[ code verwijderd ]
Zo ver was ik alquote:De documentatie schrijft voor:
[..]
Array to string conversion notice komt simpelweg doordat je ergens een array als argument meegeeft terwijl er een string wordt verwacht (zonder code gaan wij niet kunnen uitvinden waar dat vandaan komt).
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.
Nee, want MySQL is totaal niet de plaats om allerlei logica in te gaan dumpen.quote:Op donderdag 29 januari 2015 23:52 schreef TwenteFC het volgende:
Gewoon omdat ik het hier eigenlijk nooit voorbij zie komen,
maar wie hier gebruikt er wel eens op regelmatige basis triggers, functies en dergelijke in mysql?
Soms kan het vanuit performance oogpunt handig zijn. Zeker ORM is lang niet altijd optimaal efficiënt. Nou merk je dat bij een gemiddeld websiteje niet, maar als het om wat grootschaligere applicaties gaat, dan zijn dat soort zaken wat belangrijker.quote:Op vrijdag 30 januari 2015 13:16 schreef Intrepidity het volgende:
[..]
Nee, want MySQL is totaal niet de plaats om allerlei logica in te gaan dumpen.
15 is imo te weinig, ik zit daar een paar euro boven met 6 jaar ervaring. Het werk is op HBO niveau maar ik ben er tussen gerold met een MBO4 diploma.quote:Op zaterdag 31 januari 2015 01:43 schreef Diabox het volgende:
Botte vraag en niet geheel on-topic (maar hier redelijke kans op antwoorden): wat verdienen jullie ongeveer als webprogrammeur? Ik heb een salarisaanbod gekregen die ik maar moeilijk kan plaatsen. Ik heb bijna 4 jaar professionele werkervaring als web developer, en heb daarnaast een BSc en MSc (informatica en SE); 15 eu p/u. Leek mij niet in verhouding met mijn ervaring en opleidingen (werk momenteel daar op freelance basis voor een veelvoud van dat bedrag).
nou dat 'crisis'-verhaal gaat echt niet in elke sector op hoor. Ik ben twee jaar geleden geswitched van werkgever en had gewoon keuze... En wij willen op het werk al geruime tijd en goede programmeur erbij maar die zijn heel lastig te vindenquote:Op zaterdag 31 januari 2015 06:16 schreef Iwanius het volgende:
Anderzijds moet Diabox ook rekening houden dat in deze tijd het hebben van een vaste baan ook wel een lekker zekerheidje is want wil jij niet, dan neemt men met gemak (gezien het gigantische aanbod van werklozen in alle sectoren) een ander.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |