[PHP] Userinfo uit database halen en importeren in andere DB

[Verwijderd]

Ik wil uit een userdatabase (databse1) wat userinfo halen als er een nieuwe user bij gekomen is en deze toevoegen in database2.

De query om de userdata op te halen is niet zo'n groot probleem, deze query heb ik al, alleen het importeren van de userdata in Database2 kan volgens mij op verschillende manieren.

Ik wil, omdat me dit het handigste lijkt, een cronjob iedere 5-10 minuten laten draaien welke met een phpscript (de sqlquery dus) eerst moet controleren of de userid al bestaat, als deze bestaat lijkt het me gewoon een kwestie van INSERT ?

Nu is het alleen zo dat userdata gewijzigd kan worden, naam, adres, enz. Hoe vaak ga je dit syncen ?

De situatie is namelijk als volgt:

De user vult een formulier in en is bekend in Database1, deze DB wordt voor verschillende doeleinden gebruikt en is niet te mergen met database2, kan gewoon niet, de ene DB is PgSQL (database1) en de andere MySQL (database2).

De cron (1x per 5-10 min) zal database1 queryen en controleren op nieuwe ID's en in geval van een nieuwe ID Database2 bijwerken met alle info van deze nieuwe ID.

Nu wil een user zijn info aanpassen. Het lijkt me het slimste om dit te doen in Database1 met een simpel update script en wanneer dit gedaan is een script te executen dat voor deze user de info uit de Database1 haalt en weer update in Database2.

Of, zal ik beide DB's tegelijk updaten met dezelfde info ? Ik prefereer zelf voor het syncen vanaf Database1 nadat deze is bijgewerkt en dat alleen de userID bijwerkt in Database2 welke je net weggeschreven hebt naar Database1 in plaats van beide DB's te update at the same time.

Wat is common voor een dergelijke situatie ? Naar beide wegschrijven of syncen ? Dumpen lijkt me een beetje teveel van het goede.

[storeman]

Je zoekt nu naar een oplossing voor een probleem die er imo niet had mogen zijn. Als data op twee verschillende plekken staat, heb je sowieso kans op inconsistente data. Wellicht heb je er een goede reden voor, die kan ik atm niet bevatten .

Ik zou de data wijzigen als de gebruiker de data wijzigt. Syncen zou ik een rare manier vinden om ze gelijk te houden. Ongeacht de enige verandering ga je een script runnen. Ik zou het zelf event bases (user-submit) ipv mbv timeouts.

Daarnaast is je data altijd een tijdje ongelijk (10 minuten in worst case). De gevolgen hiervan moeten ook te overzien zijn.

[ Voor 11% gewijzigd door storeman op 11-09-2007 22:04 ]

[Verwijderd]

het plan is alleen een cron te draaien voor het importeren van een nieuwe user. Zodra je een user zo update in DB1 zou je hierna direct een script aan kunnen roepen dat DB1 leeg trekt voor die bepaalde user en update in DB2

[Verwijderd]

Het slimste lijkt me een insert/update trigger op die user tabel in DB1 die een veld voorziet van een 'ik ben nieuw/vernieuwd!' vlaggetje. Dat kan een tellertje zijn, maar een timestamp wordt ook vaak gebruikt.
Je cronjob hoeft dan alleen te checken of er records zijn met een hogere teller/timestamp dan de laatste die 'ie heeft verwerkt en kan dan de gegevens in DB2 updaten.

[Verwijderd]

Waarom zou je eigenlijk 2db's nodig hebben?

Het lijkt me dat je met wat kunstwerk ook 1 database kan hebben om vanuit daar alles centraal te halen
Nu doe je in DB1 schrijven om daarna exact dezefde data over te zetten naar DB2

Dit kan dus allemaal in 1 db naar mijn inzien?
Anders als je toch al DB1 volschrijft, kan je in je script ook gelijk db2 inserten, moet je ook geen db's overpompen met een scriptje en cronjob

[Verwijderd]

Verwijderd schreef op dinsdag 11 september 2007 @ 22:12:
Het slimste lijkt me een insert/update trigger op die user tabel in DB1 die een veld voorziet van een 'ik ben nieuw/vernieuwd!' vlaggetje. Dat kan een tellertje zijn, maar een timestamp wordt ook vaak gebruikt.
Je cronjob hoeft dan alleen te checken of er records zijn met een hogere teller/timestamp dan de laatste die 'ie heeft verwerkt en kan dan de gegevens in DB2 updaten.

Ik kan aan DB1 weinig aanpassen, tenminste... dat is niet mijn code en ik weet niet in hoeverre een extra colom de boel in de war gaat gooien, aan het eind van de tabel zou weinig uit moeten maken opzich.

Ik kan ook altijd in DB2 een vlaggetje zetten, hoewel dit niet echt je van het is, maarja... beetje workarounden is wel vereist.

Houdt het leuk

Een database, een gemergde is dus NIET mogelijk, ander had ik dat wel gedaan

[ Voor 5% gewijzigd door Verwijderd op 11-09-2007 22:26 ]

[BCC]

Verwijderd schreef op dinsdag 11 september 2007 @ 22:25:
[...]


Ik kan aan DB1 weinig aanpassen, tenminste... dat is niet mijn code en ik weet niet in hoeverre een extra colom de boel in de war gaat gooien, aan het eind van de tabel zou weinig uit moeten maken opzich.

Zet dan een timestamp wanneer hij het laatst is geupdate. Kun je nog een beetje intelligent syncen.

[Verwijderd]

Extra kolom en een triggertje die alleen maar iets met die extra kolom doet zal de rest van 't systeem niet gaan omgooien.
Een vlaggetje in DB2 bijhouden heeft niet zo gek veel zin, omdat je dan nog steeds niet kunt weten welke BESTAANDE records in DB1 ondertussen gewijzigd zijn.

[Verwijderd]

Verwijderd schreef op dinsdag 11 september 2007 @ 22:30:
Extra kolom en een triggertje die alleen maar iets met die extra kolom doet zal de rest van 't systeem niet gaan omgooien.
Een vlaggetje in DB2 bijhouden heeft niet zo gek veel zin, omdat je dan nog steeds niet kunt weten welke BESTAANDE records in DB1 ondertussen gewijzigd zijn.

Je zou dan een extra query vooraf moeten draaien, wil je niet.

Aan het eind van een tabel maak sowiezo weinig uit, als er met $row[3] en dergelijke gewerkt wordt in een script dat ik niet in kan zien en ik zou het er tussen plakken ben ik zeker wel de sjaak natuurlijk

[FragFrog]

Verwijderd schreef op dinsdag 11 september 2007 @ 22:25:
Ik kan aan DB1 weinig aanpassen, tenminste... dat is niet mijn code en ik weet niet in hoeverre een extra colom de boel in de war gaat gooien, aan het eind van de tabel zou weinig uit moeten maken opzich.

En waarom zou het niet mogelijk zijn voor het script wat DB2 gebruikt om voor user-gegevens te connecten naar DB1? Of is dat ook software waar je niet bijkan? Zoja blijven triggers je vriend gok ik

[Japius]

FragFrog schreef op dinsdag 11 september 2007 @ 22:43:
[...]

En waarom zou het niet mogelijk zijn voor het script wat DB2 gebruikt om voor user-gegevens te connecten naar DB1? Of is dat ook software waar je niet bijkan? Zoja blijven triggers je vriend gok ik

Werken triggers ook cross-db dan?

[FragFrog]

Japius schreef op dinsdag 11 september 2007 @ 22:51:
Werken triggers ook cross-db dan?

Hangt van de db af Meen dat je met MSSQL wel een trigger kan maken die een transactionlog shipping aanroept, maar je zal wel een punt hebben als het over PgSQL gaat

* FragFrog wijst subtiel op het 'gok ik' in zijn post

[ Voor 7% gewijzigd door FragFrog op 11-09-2007 22:54 ]

[Verwijderd]

FragFrog schreef op dinsdag 11 september 2007 @ 22:43:
[...]

En waarom zou het niet mogelijk zijn voor het script wat DB2 gebruikt om voor user-gegevens te connecten naar DB1? Of is dat ook software waar je niet bijkan? Zoja blijven triggers je vriend gok ik

Omdat de userdata in DB1 een beetje lastig gedistribueerd staat vind ik.

Dit heb ik in DB2 wat beter gedaan vind ik zelf... dat is overigens mijn eigen code.

[Japius]

FragFrog schreef op dinsdag 11 september 2007 @ 22:53:
[...]

Hangt van de db af Meen dat je met MSSQL wel een trigger kan maken die een transactionlog shipping aanroept, maar je zal wel een punt hebben als het over PgSQL gaat

* FragFrog wijst subtiel op het 'gok ik' in zijn post

Als ik het goed begrijp, is DB 1 een MySQL en zou de trigger daar moeten draaien. Wordt volgens mij lastig, als ik de manual over triggers lees.

Zelf zou ik het met een cron oplossen denk ik, niet het meest elegant maar wel het meest eenvoudig te realiseren.

Fuk, te snel gelezen 't is inderdaad PG....

[ Voor 4% gewijzigd door Japius op 11-09-2007 23:42 ]

[FragFrog]

Japius schreef op dinsdag 11 september 2007 @ 23:01:
Als ik het goed begrijp, is DB 1 een MySQL en zou de trigger daar moeten draaien.

Nou...

de ene DB is PgSQL (database1)

Ik heb totaal geen ervaring met PgSQL though, dus geen idee wat wel en niet mogelijk is

Blijf er wel bij dat, zoals ookal hierboven gezegd, het niet wenselijk is om meerdere versies van dezelfde data te gebruiken. Het ontwerp van DB1 mag dan niet handig zijn, ik vraag me af hoeveel handiger het is om met crons / triggers te gaan werken, maar dat is een keuze die je zelf moet maken. Mocht je toch met crons gaan werken is het waarschijnlijk simpelweg een kwestie van timestamp kolom toevoegen met het PgSQL equivalent van on_update_current_time en de updates bijwerken, maar elegant is anders

[Verwijderd]

Naja, de data mag best verschillend zijn, het gaat alleen om de naw gegevens.... voor de rest is alles echt application based data.

[Verwijderd]

of je maakt een aparte tabel in DB1 welke de user-id en de timestamp bevat. zodoende hoef je de originele tabel niet aan te passen en hoewel je dan wel met 2 insert/update queries is dit niet zo'n probleem aangezien ik niet het idee heb dat dit soort queries bij de duizenden per minuut gebeuren.

je kan dan met een cron job inderdaad snel in deze aparte tabel zien welke user-id's zijn veranderd/ingevoerd en deze inserten/updaten in DB2.

mijn voorkeur zou ook zijn om gewoon een 2e connectie naar DB2 te maken en meteen ook daar de query uit te voeren(let op de subtiele verschillen tussen PqSQL en Mysql. dus echt een 2e query opbouwen) maar ik heb de indruk dat de TS bang is om met de huidige code en DB1 te sollen dus als hier geef ik dan ook wel voorang aan het motto: if it ain't broken, don't fix it. cron job met 2e tabel dus.

[Niemand_Anders]

Ik weet niet hoeveel kennis je van de taal C hebt, maar ik heb enkele maanden geleden een soort gelijk probleem opgelost door een MySQL engine te schrijven. Ik had deze engine de naam 'Orchestrator' gegeven. Het enigste wat deze engine doet is 1 query naar verschillende tabellen/engines schrijven op basis van een mapping ([tablename].map in directory waar ook [tablename].frm zich bevind). Mijn engine is momenteel zover dat deze zelfs een cross update kan uitvoeren

In jouw geval zou jou engine de normale MyIsam/InnoDB engine aanroepen EN de CSV engine (export naar postgres). Postgres heeft namelijk de optie om via 'copy' de CSV te verwerken. Je hebt dan alleen maar een cronjob nodig welke de 'COPY users from mysql-user-export.csv' query doorgeeft aan psql (echo 'query' | psql).

Een goed begin is de Example storage engine van MySQL

Extra bonus: Engines blijven werken in MySQL clusters, waar in ons geval andere oplossingen vaak te kort kwamen.

[Verwijderd]

OK, de mogelijkheden zijn bekend:

Ik kan een relatie tabel aan maken in de Postgres database en hier in een colom in maken voor een timestamp of een 1 zetten wanneer data is bijgewerkt.

Run het script en ziet het een 1 dan selecteert deze de info van de user met het bijbehorende id en werkt de data bij.

Ik vroeg mij alleen 2 dingen af:

- Wat is het voordeel van een timestamp ? Zou ik dan een WHERE moeten maken min een aantal minuten dat het script zelf uitrekent of de data ouder is dan zoveel minuten en dus niet bijgewerkt hoeft te worden ? een 1-tje zetten lijkt me makkelijker. Opzich zou ik het zetten van een timestamp sowiezo wel uit willen pluizen omdat ik dit nog ergens anders wil gebruiken.

- Als ik een 1 zou zetten, wat is de beste manier om hier weer een 0 van te maken wanneer het record gecheckt is ? Dit zijn redelijk realtime op het moment van uitlezen gedaan moeten worden omdat er op een dergelijk ogenblik ergens anders weer wat bijgewerkt kan worden.

Probleem is dan dus dat als je aan het eind van alle selecties en bijwerken de 1-tjes naar 0-tjes gata zetten dat je een record meepakt welke niet bijgewerkt is en wel op 0 wordt gezet.

Conclusie is dus... Timestamp is wellicht handig

[Verwijderd]

een timestamp is gewoon een integer getal van het aantal secondes sinds 1 januari 1970. je houdt dus gewoon een timestamp bij wanneer het script het voor het laatst heeft gedraaied en gebruikt gewoon een enkele query met een where waarvan de timestamp groter of gelijk aan is met de laatste keer dat het script heeft gedraaied. ook voor het verwijderen kun je dan een simpel where gebruiken met kleiner dan de huidige timestamp.

deze kun je gewoon wegscrhijven in een bestand en de volgende keer weer inlezen. niet vergeten een lock te zetten zodat je ook meteen voorkomt dat het script 2 keer tegelijk draait. de 2e instantie wacht dan tot het eerste script de lock opheft en leest dan dus ook meteen de meeste recente timestamp.