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.
Maar natuurlijk heb ik dat gechecked, draaide namelijk normaal wel.
100GB ruimte vrij
Run als admin
Het moet ergens in de tabellen zitten, daar crasht hij op, maar welke is niet duidelijk, en uitzoeken is best vervelend. Is er geen tool die de database bestanden zonder mysql server kan controleren?
100GB ruimte vrij
Run als admin
Het moet ergens in de tabellen zitten, daar crasht hij op, maar welke is niet duidelijk, en uitzoeken is best vervelend. Is er geen tool die de database bestanden zonder mysql server kan controleren?
Just say hi!
Nee, het rare is het werkte altijd, ik ben echt bang dat 1 corrupte database / tabel voor gezeur zorgt, ga opzoek naar het probleem!!! 
lolerdelol heb de originele versie van usbwebserver gedownloaded en daarvan alles uit de data dir van mysql naar mijn data dir gekopieerd, daarna gestart en hoppa werkte gelijk!
daarna al mijn databases terug gekopieerd en hoppa, werkte weer!
[ Bericht 43% gewijzigd door Chandler op 02-10-2014 20:09:56 ]
lolerdelol heb de originele versie van usbwebserver gedownloaded en daarvan alles uit de data dir van mysql naar mijn data dir gekopieerd, daarna gestart en hoppa werkte gelijk!
daarna al mijn databases terug gekopieerd en hoppa, werkte weer! [ Bericht 43% gewijzigd door Chandler op 02-10-2014 20:09:56 ]
Just say hi!
InnoDB tabellen zou je als het goed is niet moeten kunnen kopiëren door de bestanden in het filesystem te kopiëren. Althans, misschien kan het goed gaan maar het wordt uitdrukkelijk afgeraden en niet ondersteund.
Dummie hier 
Ben aan t experimenteren met de API van de RDW om alleen een bepaald type voertuig uit hun database te trekken. Dit lukt allemaal prima en opslaan in mijn eigen database ook. Alleen houdt de RDW niet bij wanneer er een record is aangepast. Iedere dag uploaden ze de complete tabel opnieuw. Hoe kan ik nu de ongeveer 10.000 records uit hun API plukken, checken of het kenteken (het enige unieke record) al bestaat en if so, checken of er wijzigingen zijn, en if so de wijzigingen doorvoeren in mijn tabel. Ik kan dan zelf mijn eigen 'updated on' veld wel aanpassen
Iemand tips/trics? Kan dit bijvoorbeeld ook met ON DUPLICATE KEY UPDATE?
-edit- En dan zijn er natuurlijk ook kentekens die uit de databse van de RDW verdwijnen (export, sloop), dan zou ik moeten kijken welke van mijn kentekens niet meer bij de RDW bekend staan, maar met 10.000 records is dat ook best lastig, lijkt me.. Ik heb wel een veld in mijn db voor sloop (ja/nee) en export (ja/nee), dus alleen dat veld aanpassen is voldoende..
Ben aan t experimenteren met de API van de RDW om alleen een bepaald type voertuig uit hun database te trekken. Dit lukt allemaal prima en opslaan in mijn eigen database ook. Alleen houdt de RDW niet bij wanneer er een record is aangepast. Iedere dag uploaden ze de complete tabel opnieuw. Hoe kan ik nu de ongeveer 10.000 records uit hun API plukken, checken of het kenteken (het enige unieke record) al bestaat en if so, checken of er wijzigingen zijn, en if so de wijzigingen doorvoeren in mijn tabel. Ik kan dan zelf mijn eigen 'updated on' veld wel aanpassen
Iemand tips/trics? Kan dit bijvoorbeeld ook met ON DUPLICATE KEY UPDATE?
-edit- En dan zijn er natuurlijk ook kentekens die uit de databse van de RDW verdwijnen (export, sloop), dan zou ik moeten kijken welke van mijn kentekens niet meer bij de RDW bekend staan, maar met 10.000 records is dat ook best lastig, lijkt me.. Ik heb wel een veld in mijn db voor sloop (ja/nee) en export (ja/nee), dus alleen dat veld aanpassen is voldoende..
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Als het kenteken je ID is zou je hier een PRIMARY KEY van kunnen maken anders een UNIQUE KEY.quote:
Je zou een datumveld kunnen toevoegen wanneer een record in jouw database is aangepast. Records die ouder zijn komen dan niet meer voor in die van de RDW. Dit is ook als archief te gebruiken.
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.
Je kunt inderdaad een insert doen met een on duplicate update erin.quote:Op vrijdag 3 oktober 2014 17:08 schreef qu63 het volgende:
Dummie hier
Ben aan t experimenteren met de API van de RDW om alleen een bepaald type voertuig uit hun database te trekken. Dit lukt allemaal prima en opslaan in mijn eigen database ook. Alleen houdt de RDW niet bij wanneer er een record is aangepast. Iedere dag uploaden ze de complete tabel opnieuw. Hoe kan ik nu de ongeveer 10.000 records uit hun API plukken, checken of het kenteken (het enige unieke record) al bestaat en if so, checken of er wijzigingen zijn, en if so de wijzigingen doorvoeren in mijn tabel. Ik kan dan zelf mijn eigen 'updated on' veld wel aanpassen
Iemand tips/trics? Kan dit bijvoorbeeld ook met ON DUPLICATE KEY UPDATE?
-edit- En dan zijn er natuurlijk ook kentekens die uit de databse van de RDW verdwijnen (export, sloop), dan zou ik moeten kijken welke van mijn kentekens niet meer bij de RDW bekend staan, maar met 10.000 records is dat ook best lastig, lijkt me.. Ik heb wel een veld in mijn db voor sloop (ja/nee) en export (ja/nee), dus alleen dat veld aanpassen is voldoende..
Je kunt ook een subquery maken die kijkt of er verschillen zijn, maar lijkt me niet nodig.
Gewoon sowieso alles updaten.
en 10000 records is een peuleschilletje
dit moet sowieso welquote:Op vrijdag 3 oktober 2014 17:20 schreef Aether het volgende:
[..]
Als het kenteken je ID is zou je hier een PRIMARY KEY van kunnen maken anders een UNIQUE KEY.
Je zou een datumveld kunnen toevoegen wanneer een record in jouw database is aangepast. Records die ouder zijn komen dan niet meer voor in die van de RDW. Dit is ook als archief te gebruiken.
Zoals ik het lees kun je net zo goed de database weer leeg kieperen en de nieuwe data erin zetten.
Of is er specifiek een reden in bestaande database records te behouden?
Of is er specifiek een reden in bestaande database records te behouden?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Hoevaak herlaad jij data per dag dan?quote:
Zoals ik het lees kun je net zo goed de database weer leeg kieperen en de nieuwe data erin zetten.
Of is er specifiek een reden in bestaande database records te behouden?
De database leeggooien is geen goed idee, gewoon updaten is het beste.
Normaal gesproken niet natuurlijk, maar je moet altijd kijken naar de specifieke use case.quote:
[..]
Hoevaak herlaad jij data per dag dan?
De database leeggooien is geen goed idee, gewoon updaten is het beste.
Het punt is dat hij elke dag data voor dezelfde set kentekens uit een API trekt. Daarbij moeten dan de verwijderingen, wijzigingen en toevoegingen in hun geheel worden doorgevoerd. Dan is verwijderen en de gehele set opnieuw toevoegen de meest efficiënte en makkelijke optie.
Als je die data wilt gaan koppelen ligt dat weer iets anders, maar de use case is niet echt duidelijk.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Ja alleen als je voorderest geen koppelingen doet in je database kan hetquote:
[..]
Normaal gesproken niet natuurlijk, maar je moet altijd kijken naar de specifieke use case.
Het punt is dat hij elke dag data voor dezelfde set kentekens uit een API trekt. Daarbij moeten dan de verwijderingen, wijzigingen en toevoegingen in hun geheel worden doorgevoerd. Dan is verwijderen en de gehele set opnieuw toevoegen de meest efficiënte en makkelijke optie.
Als je die data wilt gaan koppelen ligt dat weer iets anders, maar de use case is niet echt duidelijk.
alhoewel kentekens altijd hetzelfde blijven natuurlijk.of anders Nosql gebruiken en de letterlijke json er zo in gooien
Bij voorkeur trek je alleen de mutaties uit die API. Want daar ligt je bottleneck in dit scenario natuurlijk.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Ik heb er andere velden aan toegevoegd die niet in de RDW database staanquote:
Zoals ik het lees kun je net zo goed de database weer leeg kieperen en de nieuwe data erin zetten.
Of is er specifiek een reden in bestaande database records te behouden?
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Ja, dattum. Ik kan kijken naar de laatste tennaamstellingen, maar daarmee mis ik bijvoorbeeld of een voertuig nog een geldige APK heeft, als gestolen geregistreerd staat, etc.quote:
Bij voorkeur trek je alleen de mutaties uit die API. Want daar ligt je bottleneck in dit scenario natuurlijk.
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Zelfs dat zou je nog in een aparte tabel kunnen zetten en koppelen op kenteken.quote:
[..]
Ik heb er andere velden aan toegevoegd die niet in de RDW database staan
Dan kun je de RDW data als leidend houden.
Of wil je ook data bewaren / tonen over kentekens die al verwijderd zijn uit de RDW data?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Laat ik iets meer uitleggen over mijn database
SQL dump:
Tot en met Wachtopkeuren trek uit de RDW API, de rest wordt via andere wegen aangevuld.
Dan heb ik ook nog een andere tabel die bestaat uit bedrijfsgegevens zodat ik straks per bedrijf kan zien welke voertuigen ze hebben.
SQL dump:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | CREATE TABLE IF NOT EXISTS `voertuigen` ( `Updated` int(11) NOT NULL, `Aantalcilinders` int(16) NOT NULL, `Aantalstaanplaatsen` int(16) NOT NULL, `Aantalzitplaatsen` int(16) NOT NULL, `Cilinderinhoud` int(16) NOT NULL, `Datumaanvangtenaamstelling` int(11) NOT NULL, `Datumeersteafgiftenederland` int(11) NOT NULL, `Datumeerstetoelating` int(11) NOT NULL, `Handelsbenaming` varchar(255) NOT NULL, `Hoofdbrandstof` varchar(255) NOT NULL, `Kenteken` varchar(10) NOT NULL, `Merk` varchar(255) NOT NULL, `Milieuclassificatie` varchar(255) NOT NULL, `Vervaldatumapk` int(11) NOT NULL, `Wachtopkeuren` varchar(255) NOT NULL, `Voertuig_ID` int(11) NOT NULL AUTO_INCREMENT, `Bedrijf_ID` int(11) NOT NULL, `EigenarenP` varchar(255) NOT NULL, `EigenarenZ` varchar(255) NOT NULL, `Klasse` varchar(255) NOT NULL, `Categorie` varchar(255) NOT NULL, `CarrosserieOmschrijving` varchar(255) NOT NULL, `Type` varchar(255) NOT NULL, `Variant` varchar(255) NOT NULL, `Uitvoering` varchar(255) NOT NULL, `Typegoedkeuring` varchar(255) NOT NULL, `VervalDatTachograaf` varchar(255) NOT NULL, `TijdAanvangTenaamstelling` varchar(255) NOT NULL, `Gestolen` varchar(255) NOT NULL, `Geexporteerd` varchar(255) NOT NULL, `BijzonderheidTekst` varchar(255) NOT NULL, `Lengte` varchar(255) NOT NULL, `Breedte` varchar(255) NOT NULL, `AantalAssen` varchar(255) NOT NULL, `AantalWielen` varchar(255) NOT NULL, `Wielbasis` varchar(255) NOT NULL, `AfwijkendeMaxSnelheid` varchar(255) NOT NULL, `AfstandVoorzijdeVrtgTotHartkoppeling` varchar(255) NOT NULL, `WAVerzekerd` varchar(255) NOT NULL, PRIMARY KEY (`Voertuig_ID`), UNIQUE KEY `Kenteken` (`Kenteken`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=9740 ; |
Dan heb ik ook nog een andere tabel die bestaat uit bedrijfsgegevens zodat ik straks per bedrijf kan zien welke voertuigen ze hebben.
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Ik zoek niet op kenteken, ik zoek op voertuigtype, dus ik weet nooit vantevoren hoeveel records ik terug ga krijgen. Het kunnen er meer, minder of evenveel zijn als vandaag.quote:
[..]
Normaal gesproken niet natuurlijk, maar je moet altijd kijken naar de specifieke use case.
Het punt is dat hij elke dag data voor dezelfde set kentekens uit een API trekt. Daarbij moeten dan de verwijderingen, wijzigingen en toevoegingen in hun geheel worden doorgevoerd. Dan is verwijderen en de gehele set opnieuw toevoegen de meest efficiënte en makkelijke optie.
Als je die data wilt gaan koppelen ligt dat weer iets anders, maar de use case is niet echt duidelijk.
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
T nadeel is dus dat ik niet weet wanneer de records van de RDW geupdate zijnquote:
[..]
Als het kenteken je ID is zou je hier een PRIMARY KEY van kunnen maken anders een UNIQUE KEY.
Je zou een datumveld kunnen toevoegen wanneer een record in jouw database is aangepast. Records die ouder zijn komen dan niet meer voor in die van de RDW. Dit is ook als archief te gebruiken.
. Ik zou alle 10k records zelf moeten controleren op wijzigingen, en dan pas wel of niet aan mijn database toevoegen.
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Maakt op zich niet zo heel veel uit. Het relevante aspect is dat je de hele dataset via de API opvraagt, niet enkel mutaties bijvoorbeeld.quote:
[..]
Ik zoek niet op kenteken, ik zoek op voertuigtype, dus ik weet nooit vantevoren hoeveel records ik terug ga krijgen. Het kunnen er meer, minder of evenveel zijn als vandaag.
Wat je dan vervolgens wil, als ik het goed begrijp, is het volgende:
• Voeg rijen toe aan de eigen database voor alle kentekens in de dataset die nog niet in de eigen database stonden
• Verwijder alle rijen uit de eigen database waarbij het kenteken niet voorkomt in de nieuwe dataset
• Update alle informatie voor al bestaande kentekens
Klopt dat?
Zo ja, dan is deze opzet ook een optie:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | CREATE TABLE IF NOT EXISTS `voertuigen_RDW` ( `Updated` int(11) NOT NULL, `Aantalcilinders` int(16) NOT NULL, `Aantalstaanplaatsen` int(16) NOT NULL, `Aantalzitplaatsen` int(16) NOT NULL, `Cilinderinhoud` int(16) NOT NULL, `Datumaanvangtenaamstelling` int(11) NOT NULL, `Datumeersteafgiftenederland` int(11) NOT NULL, `Datumeerstetoelating` int(11) NOT NULL, `Handelsbenaming` varchar(255) NOT NULL, `Hoofdbrandstof` varchar(255) NOT NULL, `Kenteken` varchar(10) NOT NULL, `Merk` varchar(255) NOT NULL, `Milieuclassificatie` varchar(255) NOT NULL, `Vervaldatumapk` int(11) NOT NULL, `Wachtopkeuren` varchar(255) NOT NULL, PRIMARY KEY (`Kenteken`), ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=9740 ; CREATE TABLE IF NOT EXISTS `voertuigen_other` ( `Voertuig_ID` int(11) NOT NULL AUTO_INCREMENT, `Bedrijf_ID` int(11) NOT NULL, `EigenarenP` varchar(255) NOT NULL, `EigenarenZ` varchar(255) NOT NULL, `Klasse` varchar(255) NOT NULL, `Categorie` varchar(255) NOT NULL, `CarrosserieOmschrijving` varchar(255) NOT NULL, `Type` varchar(255) NOT NULL, `Variant` varchar(255) NOT NULL, `Uitvoering` varchar(255) NOT NULL, `Typegoedkeuring` varchar(255) NOT NULL, `VervalDatTachograaf` varchar(255) NOT NULL, `TijdAanvangTenaamstelling` varchar(255) NOT NULL, `Gestolen` varchar(255) NOT NULL, `Geexporteerd` varchar(255) NOT NULL, `BijzonderheidTekst` varchar(255) NOT NULL, `Lengte` varchar(255) NOT NULL, `Breedte` varchar(255) NOT NULL, `AantalAssen` varchar(255) NOT NULL, `AantalWielen` varchar(255) NOT NULL, `Wielbasis` varchar(255) NOT NULL, `AfwijkendeMaxSnelheid` varchar(255) NOT NULL, `AfstandVoorzijdeVrtgTotHartkoppeling` varchar(255) NOT NULL, `WAVerzekerd` varchar(255) NOT NULL, `Kenteken` varchar(10) PRIMARY KEY (`Voertuig_ID`), UNIQUE KEY `Kenteken` (`Kenteken`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=9740 ; |
Daarbij kieper je dan bij elke nieuwe dataset uit de API de tabel voertuigen_RDW weer leeg en insert je de gehele dataset.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Niet helemaal, ik wil ook de voertuigen die gexporteerd/gesloopt zijn behouden.quote:
[..]
Maakt op zich niet zo heel veel uit. Het relevante aspect is dat je de hele dataset via de API opvraagt, niet enkel mutaties bijvoorbeeld.
Wat je dan vervolgens wil, als ik het goed begrijp, is het volgende:
• Voeg rijen toe aan de eigen database voor alle kentekens in de dataset die nog niet in de eigen database stonden
• Verwijder alle rijen uit de eigen database waarbij het kenteken niet voorkomt in de nieuwe dataset
• Update alle informatie voor al bestaande kentekens
Klopt dat?
Zo ja, dan is deze opzet ook een optie:
[ code verwijderd ]
Daarbij kieper je dan bij elke nieuwe dataset uit de API de tabel voertuigen_RDW weer leeg en insert je de gehele dataset.
Maar dat maakt verder niet uit voor de tabellen geloof ik.
Hoe zou ik de SQL-query dan moeten maken?
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Als dat de use case is, dan zou ik gewoon voor de insert met on duplicate key update gaan.quote:
[..]
Niet helemaal, ik wil ook de voertuigen die gexporteerd/gesloopt zijn behouden.
Maar dat maakt verder niet uit voor de tabellen geloof ik.
Hoe zou ik de SQL-code dan moeten maken?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Ik zou het volgende doen. reken de md5sum uit van elk dataset. Vergelijk die md5sum (digest) van je eigen DB tegen die van het RDW: Verschil, record updaten/inserten (incl de digest). Geen verschil, volgend record. En dan kan je via on update ook nog een last_modified oid hebben, dan ben je klaar. En date_created, voila. Dan kan je denk ik redelijk snel door je records heen gaan zonder overal afzonderlijk complete sets te vergelijken.
In theory there is no difference between theory and practice. In practice there is.
INSERT INTO voertuigen (columns) VALUES (values) ON DUPLICATE KEY UPDATE c1=v1, c2=v2, etcquote:
[..]
Als dat de use case is, dan zou ik gewoon voor de insert met on duplicate key update gaan.
Zoiets?
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Maar dan dus wel mijn tabel splitsen zoals hier Monolith zei? DIG / [PHP/(My)SQL] voor dummies #118quote:
Ik zou het volgende doen. reken de md5sum uit van elk dataset. Vergelijk die md5sum (digest) van je eigen DB tegen die van het RDW: Verschil, record updaten/inserten (incl de digest). Geen verschil, volgend record. En dan kan je via on update ook nog een last_modified oid hebben, dan ben je klaar. En date_created, voila. Dan kan je denk ik redelijk snel door je records heen gaan zonder overal afzonderlijk complete sets te vergelijken.
It's Time To Shine
[i]What would life be like without rhethorical questions?[/i]
[i]What would life be like without rhethorical questions?[/i]
Waarom zou je dat zo vreselijk omslachtig doen?quote:
Ik zou het volgende doen. reken de md5sum uit van elk dataset. Vergelijk die md5sum (digest) van je eigen DB tegen die van het RDW: Verschil, record updaten/inserten (incl de digest). Geen verschil, volgend record. En dan kan je via on update ook nog een last_modified oid hebben, dan ben je klaar. En date_created, voila. Dan kan je denk ik redelijk snel door je records heen gaan zonder overal afzonderlijk complete sets te vergelijken.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Nee, dat was meer in de veronderstelling dat je ook wilde verwijderen. Negeer dat maar.quote:
[..]
Maar dan dus wel mijn tabel splitsen zoals hier Monolith zei? DIG / [PHP/(My)SQL] voor dummies #118
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Hoezo omslachtig? Je kan anders namelijk niet zien wanneer de laatste wijziging heeft plaatsgevonden.quote:
[..]
Waarom zou je dat zo vreselijk omslachtig doen?
In theory there is no difference between theory and practice. In practice there is.
Je kunt in je insert en on update gewoon de curdate() meegeven.quote:
[..]
Hoezo omslachtig? Je kan anders namelijk niet zien wanneer de laatste wijziging heeft plaatsgevonden.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Maar als je gewoon klakkeloos importeert zijn de gegevens zonder te checken of de data veranderd is staat curdate altijd op het import-moment.quote:
[..]
Je kunt in je insert en on update gewoon de curdate() meegeven.
In theory there is no difference between theory and practice. In practice there is.
