Normaal gesproken niet natuurlijk, maar je moet altijd kijken naar de specifieke use case.quote:Op vrijdag 3 oktober 2014 17:37 schreef totalvamp het volgende:
[..]
Hoevaak herlaad jij data per dag dan?
De database leeggooien is geen goed idee, gewoon updaten is het beste.
Ja alleen als je voorderest geen koppelingen doet in je database kan het alhoewel kentekens altijd hetzelfde blijven natuurlijk.quote:Op vrijdag 3 oktober 2014 17:43 schreef Monolith het volgende:
[..]
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.
Ik heb er andere velden aan toegevoegd die niet in de RDW database staanquote:Op vrijdag 3 oktober 2014 17:35 schreef Monolith het volgende:
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?
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:Op vrijdag 3 oktober 2014 17:47 schreef Monolith het volgende:
Bij voorkeur trek je alleen de mutaties uit die API. Want daar ligt je bottleneck in dit scenario natuurlijk.
Zelfs dat zou je nog in een aparte tabel kunnen zetten en koppelen op kenteken.quote:Op vrijdag 3 oktober 2014 17:47 schreef qu63 het volgende:
[..]
Ik heb er andere velden aan toegevoegd die niet in de RDW database staan
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 ; |
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:Op vrijdag 3 oktober 2014 17:43 schreef Monolith het volgende:
[..]
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.
T nadeel is dus dat ik niet weet wanneer de records van de RDW geupdate zijn . Ik zou alle 10k records zelf moeten controleren op wijzigingen, en dan pas wel of niet aan mijn database toevoegen.quote: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.
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:Op vrijdag 3 oktober 2014 17:54 schreef qu63 het volgende:
[..]
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.
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 ; |
Niet helemaal, ik wil ook de voertuigen die gexporteerd/gesloopt zijn behouden.quote:Op vrijdag 3 oktober 2014 18:04 schreef Monolith het volgende:
[..]
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.
Als dat de use case is, dan zou ik gewoon voor de insert met on duplicate key update gaan.quote:Op vrijdag 3 oktober 2014 18:06 schreef qu63 het volgende:
[..]
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?
INSERT INTO voertuigen (columns) VALUES (values) ON DUPLICATE KEY UPDATE c1=v1, c2=v2, etcquote:Op vrijdag 3 oktober 2014 18:09 schreef Monolith het volgende:
[..]
Als dat de use case is, dan zou ik gewoon voor de insert met on duplicate key update gaan.
Maar dan dus wel mijn tabel splitsen zoals hier Monolith zei? DIG / [PHP/(My)SQL] voor dummies #118quote:Op vrijdag 3 oktober 2014 18:09 schreef slacker_nl het volgende:
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.
Waarom zou je dat zo vreselijk omslachtig doen?quote:Op vrijdag 3 oktober 2014 18:09 schreef slacker_nl het volgende:
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.
Nee, dat was meer in de veronderstelling dat je ook wilde verwijderen. Negeer dat maar.quote:Op vrijdag 3 oktober 2014 18:15 schreef qu63 het volgende:
[..]
Maar dan dus wel mijn tabel splitsen zoals hier Monolith zei? DIG / [PHP/(My)SQL] voor dummies #118
Hoezo omslachtig? Je kan anders namelijk niet zien wanneer de laatste wijziging heeft plaatsgevonden.quote:Op vrijdag 3 oktober 2014 18:15 schreef Monolith het volgende:
[..]
Waarom zou je dat zo vreselijk omslachtig doen?
Je kunt in je insert en on update gewoon de curdate() meegeven.quote:Op vrijdag 3 oktober 2014 18:19 schreef slacker_nl het volgende:
[..]
Hoezo omslachtig? Je kan anders namelijk niet zien wanneer de laatste wijziging heeft plaatsgevonden.
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:Op vrijdag 3 oktober 2014 18:22 schreef Monolith het volgende:
[..]
Je kunt in je insert en on update gewoon de curdate() meegeven.
Die geeft de API van de RDW zelf al mee, maar dat is het moment van opvragen van de gegevens, niet van de laatste actualisatiequote:Op vrijdag 3 oktober 2014 18:22 schreef Monolith het volgende:
[..]
Je kunt in je insert en on update gewoon de curdate() meegeven.
Ah je bedoelt daadwerkelijke wijzigingen ipv een update met dezelfde data. Ik weet niet of dat vereist is.quote:Op vrijdag 3 oktober 2014 18:25 schreef slacker_nl het volgende:
[..]
Maar als je gewoon klakkeloos importeert zijn de gegevens zonder te checken of de data veranderd is staat curdate altijd op het import-moment.
Dat is wel hoe ik de vraag interpreteerde.quote:Op vrijdag 3 oktober 2014 18:27 schreef Monolith het volgende:
[..]
Ah je bedoelt daadwerkelijke wijzigingen ipv een update met dezelfde data. Ik weet niet of dat vereist is.
quote: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
Een update wordt niet uitgevoerd als de data die in de tabel staat hetzelfde is.quote:Op vrijdag 3 oktober 2014 18:25 schreef slacker_nl het volgende:
[..]
Maar als je gewoon klakkeloos importeert zijn de gegevens zonder te checken of de data veranderd is staat curdate altijd op het import-moment.
Bij MySQL wel, ik weet niet hoe andere databases hiermee omgaan.quote:Op vrijdag 3 oktober 2014 18:51 schreef totalvamp het volgende:
[..]
Een update wordt niet uitgevoerd als de data die in de tabel staat hetzelfde is.
Dan heb je daar dus geen last van.
Bovendien geef je de curdate mee bij de update dus dan is ie altijd anders.quote:Op vrijdag 3 oktober 2014 19:00 schreef slacker_nl het volgende:
[..]
Bij MySQL wel, ik weet niet hoe andere databases hiermee omgaan.
Nee bij MySQL niet, letterlijk net getest.quote:Op vrijdag 3 oktober 2014 19:00 schreef slacker_nl het volgende:
[..]
Bij MySQL wel, ik weet niet hoe andere databases hiermee omgaan.
Hij update de values niet, maar hij triggert mogelijk wel de iets als je die update doet.. Wij doen bijv dit: last_modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP, waardoor de last_modified aanpast na een update. Of de waardes daadwerkelijk zijn aangepast is niet van belang, de call werd gedaan en wordt zo zichtbaar. Dus..
1 2 3 4 5 6 7 8 9 | Veranderd de update tijd niet: INSERT INTO test (name, username) VALUES ('b', 'b') ON DUPLICATE KEY UPDATE name = 'b', username='b' Veranderd hem wel: INSERT INTO test (name, username) VALUES ('b', 'a') ON DUPLICATE KEY UPDATE name = 'b', username='a' |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | CREATE TABLE IF NOT EXISTS `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `username` varchar(255) NOT NULL, `last_update` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ; -- -- Gegevens worden uitgevoerd voor tabel `test` -- INSERT INTO `test` (`id`, `name`, `username`, `last_update`) VALUES (1, 'a', 'a', '0000-00-00 00:00:00'), (2, 'b', 'a', '0000-00-00 00:00:00'); |
1 2 3 4 5 6 7 8 9 10 11 | Deze zal niks doen: INSERT INTO test (name, username) VALUES ('a', 'a') ON DUPLICATE KEY UPDATE name = 'a', username='a' Deze wel: INSERT INTO test (name, username) VALUES ('b', 'a') ON DUPLICATE KEY UPDATE name = 'b', username='a' |
Niet alleen DEFAULT, ook ON UPDATE CURRENT_TIMESTAMP.quote:Op vrijdag 3 oktober 2014 19:00 schreef slacker_nl het volgende:
[..]
Bij MySQL wel, ik weet niet hoe andere databases hiermee omgaan.
Hij update de values niet, maar hij triggert mogelijk wel de iets als je die update doet.. Wij doen bijv dit: last_modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP, waardoor de last_modified aanpast na een update. Of de waardes daadwerkelijk zijn aangepast is niet van belang, de call werd gedaan en wordt zo zichtbaar. Dus..
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | <?php $columns = implode(", ",array_keys($code)); $escaped_values = array_map(NULL, array_values($code)); $values = implode(", ", $escaped_values); $sql = "SELECT kenteken FROM voertuigen WHERE kenteken='".$item["M:PROPERTIES"]["D:KENTEKEN"]."1'"; $result = mysqli_query($con, $sql); if(mysqli_num_rows($result)>0) { $sql = "UPDATE voertuigen SET Updated='".$item['UPDATED']."', Datumaanvangtenaamstelling='".strtotime($item["M:PROPERTIES"]["D:DATUMAANVANGTENAAMSTELLING"])."', VervaldatumAPK='".strtotime($item["M:PROPERTIES"]["D:VERVALDATUMAPK"])."', Wachtopkeuren='".$item["M:PROPERTIES"]["D:WACHTOPKEUREN"]."' WHERE kenteken='".$item["M:PROPERTIES"]["D:KENTEKEN"]."'"; $query = mysqli_query($con,$sql); } else { $sql = "INSERT INTO `voertuigen` ($columns) VALUES ($values)"; $query = mysqli_query($con,$sql); list($klasse, $category, $EigenarenP, $EigenarenZ, $CarrosserieOmschrijving, $Type, $Variant, $Uitvoering, $Typegoedkeuring, $VervalDatTachograaf, $TijdAanvangTenaamstelling, $Gestolen, $Geexporteerd, $WAVerzekerd, $BijzonderheidTekst, $Lengte, $Breedte, $AantalAssen, $AantalWielen, $Wielbasis, $AfwijkendeMaxSnelheid, $AfstandVoorzijdeVrtgTotHartkoppeling) = get_ovi($item["M:PROPERTIES"]["D:KENTEKEN"]); $sql = "Update voertuigen SET klasse='".$klasse."', Categorie='".$category."', EigenarenP='".$EigenarenP."', EigenarenZ='".$EigenarenZ."', CarrosserieOmschrijving='".$CarrosserieOmschrijving."', Type='".$Type."', Variant='".$Variant."', Uitvoering='".$Uitvoering."', Typegoedkeuring='".$Typegoedkeuring."', VervalDatTachograaf='".strtotime($VervalDatTachograaf)."', TijdAanvangTenaamstelling='".$TijdAanvangTenaamstelling."', Gestolen='".$Gestolen."', Geexporteerd='".$Geexporteerd."', WAVerzekerd='".$WAVerzekerd."', BijzonderheidTekst='".$BijzonderheidTekst."', Lengte='".$Lengte."', Breedte='".$Breedte."', AantalAssen='".$AantalAssen."', AantalWielen='".$AantalWielen."', Wielbasis='".$Wielbasis."', AfwijkendeMaxSnelheid='".$AfwijkendeMaxSnelheid."', AfstandVoorzijdeVrtgTotHartkoppeling='".$AfstandVoorzijdeVrtgTotHartkoppeling."' WHERE Kenteken = '".$item["M:PROPERTIES"]["D:KENTEKEN"]."'"; $query = mysqli_query($con,$sql); ?> |
Tip: gebruik PDO.quote:Op zaterdag 4 oktober 2014 01:26 schreef qu63 het volgende:
Dit lijkt mij nu wel een redelijke oplossing:
[ code verwijderd ]
$con en $code worden eerder al gedefineerd
Waarom?quote:
Als je wilt switchen van database is het veel makkelijker.quote:
Of je gebruikt gewoon de INSERT en dan ON DUPLICATE KEY UPDATEquote:Op zaterdag 4 oktober 2014 01:26 schreef qu63 het volgende:
Dit lijkt mij nu wel een redelijke oplossing:
[ code verwijderd ]
$con en $code worden eerder al gedefineerd
Wat is PDO?quote:
Optimalisatie was de volgende stap jaquote:Op zaterdag 4 oktober 2014 13:36 schreef Monolith het volgende:
Je kunt ook een Stored procedure schrijven en zo zijn er nog 101 opties. Kies gewoon iets dat werkt, aangezien het voor zover ik kan zien toch niet een of ander enorm project is waarbij de architectuur enorm belangrijk is. Hooguit moet je op een gegeven moment naar performance gaan kijken, maar zolang je nog hele datasets uit een API trekt ligt de bottleneck niet bij wat database interacties.
http://bit.ly/1uJOkmdquote:
Volgens mij kun je dat allemaal in je .htaccess regelen.quote:Op zaterdag 4 oktober 2014 14:08 schreef pascal08 het volgende:
Ik zit met een vaag probleem. Ik heb een production server waarop ik een website live wil gooien. Ik heb de bestanden in de root van de webserver geüpload.
De folder structure ziet er ongeveer zo uit:
/ root
- application
- system
- public
---- assets
---- index.php
---- .htaccess
Als ik nu naar het domein ga krijg ik de melding dat er geen content geüpload is. Ik snap dat er geen index.php in de root staat en dat dat wel nodig is, maar hoe hou ik dan de private en public content gescheiden? Ik gebruik CodeIgniter trouwens.
Er moet dus ook een .htaccess in de root komen?quote:Op zaterdag 4 oktober 2014 14:10 schreef robin007bond het volgende:
[..]
Volgens mij kun je dat allemaal in je .htaccess regelen.
1 2 3 4 | [..] RewriteEngine On RewriteBase /public/ [..] |
Dat bedacht ik me gisteravond ook, maar toen vond ik een reden om dat niet te doen.quote:Op zaterdag 4 oktober 2014 13:30 schreef totalvamp het volgende:
[..]
Of je gebruikt gewoon de INSERT en dan ON DUPLICATE KEY UPDATE
waarom zou je daar omheen werken met een constructie die alleen maar meer queries oplevert...
De melding is nu weg. Ik heb enkel nog een lege witte pagina nu. Ik heb de bestanden gewoon 1:1 gekopieerd vanuit m'n local environment. Ik snap niet wat er nou fout gaat.quote:Op zaterdag 4 oktober 2014 14:13 schreef pascal08 het volgende:
[..]
Er moet dus ook een .htaccess in de root komen?
[ code verwijderd ]
Zoiets?
Luiheid ?quote:Op zaterdag 4 oktober 2014 14:30 schreef qu63 het volgende:
[..]
Dat bedacht ik me gisteravond ook, maar toen vond ik een reden om dat niet te doen.
Geen idee meer wat die reden was
Nee, want ik dacht juist eerst aan INSERT ON DUPLICATE UPDATEquote:
Ah, ik weet t al!quote:
Met mysqli kun je ook gewoon parameters binden, en wie switcht er in de praktijk nou echt van database?quote:Op zaterdag 4 oktober 2014 12:29 schreef robin007bond het volgende:
[..]
Als je wilt switchen van database is het veel makkelijker.
Plus er zitten handige dingen in injecties te voorkomen. BindParam etc.
Bij mijn vorige werkgever gebruikte we sqlite voor de testsuite en postgres voor het echte werk. Of je hebt apps waarbij je een db nodig hebt en die moeten werken of je nu mysql, berkely, postgres of Oracle hebt... shit must work yo.quote:Op zaterdag 4 oktober 2014 17:46 schreef mstx het volgende:
[..]
Met mysqli kun je ook gewoon parameters binden, en wie switcht er in de praktijk nou echt van database?
Ik heb het al degelijk wel eens meegemaakt. Switchen van database (van MySQL naar Postgres) en helaas was er geen gebruik gemaakt van PDOquote:Op zaterdag 4 oktober 2014 17:46 schreef mstx het volgende:
[..]
Met mysqli kun je ook gewoon parameters binden, en wie switcht er in de praktijk nou echt van database?
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |