[MSSQL] Agenda's Gewoon, Facebook en LastFM combineren?

[Verwijderd]

Bedankt, ik ben eruit

Voor een ipone app ben ik de database aan het opzetten. Zelf ga ik de app niet bouwen. Momenteel zit ik met een situatie waarvan ik niet goed weet wat de beste aanpak is...

Ik moet een agenda opzetten. Nu zit ik met 3 datasources.

A: de publisher voert een eigen agenda in
B: de publisher gebruikt zijn Facebook events
C: de publisher gebruikt zijn LastFM events

Users van de app moeten kunnen aangeven "i'm going" en foto's e.d. aan een event/agenda item kunnen toevoegen

Via de api's van facebook en lastfm zou ik de data kunnen binnentrekken. Vraag is nu of ik het best 3 losse tabellen aanmaak voor dit doel (gewone agenda, Facebook agenda en LastFM agenda), of alles combineer in 1 tabel. De feeds van lastfm en facebook zijn grotendeels gelijk.

Voordeel alles-in-1 is dat ik makkelijk i'm going en foto relaties leg. Bovendien hoeven de developers niet talloze if-then-else constructies te maken. Nadeel is dat ik aan de andere kant bij het syncen van de data weer talloze van dergelijke constructies moet maken.

Dit is overigens de data zoals ik het zo ongeveer zal binnenkrijgen:
http://wiki.developers.facebook.com/index.php/Events.get
http://www.last.fm/api/show?service=117
Wat zou de beste oplossing zijn?

[P_de_B]

Ik zou zorgen dat je intern een en dezelfde structuur voor 'events' aanhoud. Wat als je straks Hyves wilt ondersteunen? Ga je dan nog een nieuwe tabel aanmaken?

[Verwijderd]

Bedankt voor je reacties. True, maar iedere datasource heeft zo zijn eigen bijzonderheden. LastFM bijvoorbeeld kan meerdere artists bevatten per event (zie link). Zou ik dat netjes oplossen, dan zou ik een aparte artists tabel moeten aanleggen, of alle artistrows mergen of iets dergelijks. Wie weet heeft een hyves agenda ook weer zijn uitzonderingsgevallen. Dat is mijn argument om het toch gescheiden te houden.

Overigens, als een publisher nu dezelfde events heeft staan op zijn LastFM en FaceBook, dan zit ik met dubbele gegevens, tenzij ik de publisher verplicht om 1 datasource te kiezen.

Maar ik zie ook de voordelen in van een alles-in-1 tabel. Denk dat ik dat dan ook maar zo ga doen, tenzij er nog reacties volgen die ervoor pleiten om het vooral niet zo op te lossen.

[Janoz]

Ik zou zeker niet een tabel per bron aanhouden. Dat lijkt voor het synchronizeren misschien leuk, maar voor alle andere dingen is het een redelijke hel en dan heb ik het nog niet eens over de 4e tabel die je dan toe moet voegen voor hyves.

Het synchronizatie probleem is relatief simpel op te lossen door per item ook de bron op te slaan. Meer dan een kolom met hierin facebook, LastFM of wat je dan ook maar als bron hebt is niet nodig. Sowieso is het niet heel ingewikkeld aangezien het maar 1weg synchronisatie is.

Op zich is je punt mbt artists valide, maar imhop redeneer je verkeerd om. Je moet eerst beginnen met wat jij voor jouw app belangrijk vindt. Is het daadwerkelijk nodig om de artists uit te normaliseren, of is het binnen de context van jouw applicatie niet meer dan een regeltje in de description van het event? Bekijk dus eerst welke gegevens jij binnen jouw applicatie graag appart wilt zien, en kijk daarna of de verschillende bronnen dit ook zo aan kunnen leveren.

[Verwijderd]

Bedank voor je goede inhoudelijke reactie, Janoz, ik waardeer het enorm. Je hebt een paar goede punten. Ik ben nu over mijn twijfel heen en ga het inderdaad zo oplossen.