22. april 2002 - 01:34Der er
16 kommentarer og 1 løsning
Synkronisering af tabeller
Hej eksperter
Jeg har lavet et kalender-/aftaleprogram som jeg har kørende lokalt på min computer. Aftalerne gemmes i en MySQL tabel, med følgende struktur:
CREATE TABLE phpmyplanner ( id int(10) unsigned NOT NULL auto_increment, title varchar(255) NOT NULL default '', description text NOT NULL, link varchar(255) NOT NULL default '', datecreated datetime NOT NULL default '0000-00-00 00:00:00', datedeadline datetime default NULL, datefinished datetime default NULL, PRIMARY KEY (id), UNIQUE KEY id (id), KEY datedeadline (datedeadline) ) TYPE=MyISAM;
Nu var det så, at jeg godt kunne tænke mig at få adgang til mine aftaler via internetttet, hvor åbningstiden er lidt mere fleksibel end på min egen maskine. Jeg ønsker dog ikke at den udgave af programmet som kører lokalt benytter en mysql-db ude på nettet - den skal stadig bruge den lokale udgave.
Derfor har jeg behov for at kunne synkronisere to tabeller med aftaler i - jeg har tænkt lidt over problemstillingen, men kan ikke finde noget forkromet svar. Ligegyldigt hvilken løsningsmetode jeg finder på, kan jeg også finde hullerne i den. En synkronisering af to tabeller burde jo være en standardopgave, så der er sikkert klogere folk som har overvejet problemstillingen før mig.
Har du nogle ideer til hvordan man laver sådan en synkronisering eller evt. links til nogle steder, hvor der er lidt forklaring?
Sådan som jeg ser det vil det være ligeså usikkert at synkronisere de to tabeller som at have det liggende på nettet. Hvis du ligger en PHPfil som synkronisere med en database på nettet og på din lokale computer kan dette da på alle måder brydes ligesom din tabel på nettet kan brydes... mon jeg forstår forkert?
Jeg vil primært bruge programmet hjemmefra og pga. hastighed vil jeg gerne have, at min hjemmeudgave bruger mysql basen på min egen computer.
Derudover kan det hænde at jeg ind i mellem har behov for at se mine aftaler, redigere dem, slette dem eller oprette nye - mens jeg er væk hjemmefra - så der ville jeg gerne have mulighed for at koble op til mit webhotel og logge ind på kalenderen. Den udgave af kalenderen skal så benytte en MySQL db som ligger på samme server som kalenderen.
Jeg vil så gerne have muligheden for, at synkronisere de to tabeller når jeg kommer hjem - således at de ændringer der er sket på den eksterne db kommer ned på min computer og de ændringer der er sket på min lokale db kommer op på webhotellet - kort og godt at de bliver synkroniseret.
sthen: Ja - jeg havde forestillet mig en løsning vha et php-script.
cpfrande: Det med at have to udgaver af db'en er udelukkende på grund af hastighed og ikke pga. et ønske om sikkerhed.
jeg ville foreslå dig at lave en kolonne til at indeholde besked om en række er ændret. feks tinyint hvor 0=ingen rettelser, 1=rettet, 2=nyoprettet, eller noget lignende. denne kolonne sætter du så til 1 ved update, 2 ved insert og 0 ved synkronisering
når du skal synkronisere vælger du alle rækker med 1 i kolonnen og update'r i den anden DB, alle rækker med 2 og insert'er.
det kræver lidt diciplin fra brugerne at den DB man arbejder på skal være synkroniseret, således at der ikke lige pludselig er sket ændringer i samme række i begge DB'er, men da det lyder som om det kun er dig selv der bruger den kunne det være en løsning
Selvom det kun er mig, som bruger db'en kunne følgende situation godt opstå:
1. Jeg synkroniserer 2. Jeg opretter ny aftale i db på webhotel 3. Jeg opretter ny aftale i db på lokalmaskine 4. Jeg synkroniserer
-hvordan skal jeg så tage højde for at der rent faktisk er to nye aftaler - som vel at mærke skal have samme id på tværs af db'erne efter synkronisering.
du kunne programmere dig ud af det ved manuelt at indsætte ID og så bruge ulige tal til dem der oprettes det ene sted og lige tal det andet sted
i det eksempel du angiver, vil du heller ikke kunne se aftalen oprettet i 2. når du opretter aftalen i 3. ...aftalen i 3. vil derved kunne overlappe aftalen i 2. tidsmæssigt
og hvis samme aftale nu redigeres begge steder mellem synkronisering, så vil du, anden gang du redigerer, redigere i en 'uotdated' version af aftalen
jeg vil umiddelbart mene at du skal synkronisere din hjemmeDB inden du arbejder på den og synkronisere din webDB når du tager hjemmefra og får brug for adgang udefra, for at undgå de omtalte overlap mv.
Vi er enig om at det er den ideelle løsning, men jeg er også så meget realist, at jeg må indse, at det bare er et spørgsmål om tid inden jeg glemmer det - så jeg bliver nødt til at have en løsning der kan tage højde for det!
under alle omstændigheder tror jeg du må ud i manuel ID-tildeling for at kunne oprette aftaler i begge DB'er og kunne beholde det oprindelige ID ved synkroniseringen.
du kunne så i din synkroniseringsrutine kontrollere for overlappende aftaler - desuden kunne du kontrollere for om en aftale skulle være redigeret begge steder og hvis der er det, så manuelt vælge hvilken af dem der skal være gældende
Posterne behøver ikke nødvendigvis beholde deres oprindelige ID, men efter synkronisering skal posterne selvfølgelig have matchende ID-numre på tværs af db'erne - dvs. post nr 21. er den samme begge steder!
Jeg har kun lavet systemet, så en aftale har en deadline - dvs. den består ikke af et start- og et sluttidspunkt - så problemet med overlap styres af mig selv.
Du kommer til at opgive kravet om "saame id" skal kunne være 2 forskellige entries. Det holder simpelthen ikke.
Tag istedet en microtime hver gang du opretter og brug den som id. Sålænge det kun er dig der bruger databasen skulle det være unikt nok til at synkromiseringen blot bliver at hente de entries du ikke har fra den anden.
Der kan du så lege hash-tabel og incrementere indtil der er et hul.
men det kræver en 2-bit sync status i hver række
00 => nyoprettet, hash den ind 01 => nyoprettet, redigeret, hash den ind. 10 => syncroniseret. no action 11 => redigeret efter sync. overskriv i anden deb.
Nej lad være med det ( ja OK det skader ikke :-). Men hashing er langt mere end den del af det der skal bruges her.
Alt det af hashing du behøver her er adfærden når hash-key genererer en kollision: forøg id (fra microtime) med en indtil du kommer til et ledigt id nummer. og brug så det idnummer for den entry i begge databaser.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
