No, neither table would have unqiueness constraints (besides the primary keys).
2013/7/29 Sean Pringle <[email protected]> > On Tue, Jul 23, 2013 at 1:42 AM, Denny Vrandečić < > [email protected]> wrote: > > > > > * EntityUsage: one table per client. It has two columns, one with the > > pageId and one with the entityId, indexed on both columns (and one column > > with a pk, I guess, for OSC). > > > > * Subscriptions: one table on the client. It has two columns, one with > the > > pageId and one with the siteId, indexed on both columns (and one column > > with a pk, I guess, for OSC). > > > > EntityUsage is a potentially big table (something like pagelinks-size). > > > > On a change on Wikidata, Wikidata consults the Subscriptions table, and > > based on that it dispatches the changes to all clients listed there for a > > given change. Then the client receives the changes and based on the > > EntityUsage table performs the necessary updates. > > > > We wanted to ask for input on this approach, and if you see problems or > > improvements that we should put in. > > > > Sounds OK to me. > > Will (or could) pageId/entityId and pageId/siteId have unique constraints? > > BR > Sean > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
