SQL-oplossing synchroniseren met een no-sql oplossing?

[roger128]

Hallo iedereen

Ik ben van plan een api met bijbehorende app, website etc te bouwen. Ik doe dit op basis van data die ik van een andere api (externe partij) naar binnen haal. Dit betreft een groot XML file met hierin alle data (ik kan de api vragen om specifieke delen van deze file, ik neem aan dat er een no-sql database achter deze api zit). Dit is een erg handig formaat: stel de data bevat auto's, dan hebben auto's altijd stoelen welke altijd bekleding hebben welke altijd een kleur hebben... et cetera. Deze data is erg mooi om een website op te bouwen: ik kan de XML naar een array parsen en vervolgens door de hele array loopen.

Echter wil ik ook nog andere dingen met de api. In het voorbeeld zou ik graag klanten informeren als er een nieuwe auto beschikbaar komt of een nieuwe stoel (etc). Dit is data die perfect is voor een sql database.

Ik zit dus een beetje in dubio: wat moet ik doen. De no-sql database gebruiken en hier alle andere functionaliteit in verwerken (lijkt me overigens een heel slecht idee)? De no-sql gegevens in een sql database zetten om vervolgens vaak dezelfde informatie op te vragen als relatief dure operatie (joins e.d. terwijl de links altijd hetzelfde zijn)? Of is het een idee de databases aan elkaar te linken? En moet ik dan de ene database naar de andere linken (en in welke volgorde) of allebij updaten vanaf de api?

Een hoop vragen en waarschijnlijk ook een beetje een vaag verhaal maar ik hoop dat jullie me kunnen helpen. Alvast bedankt!

[Amanush]

Kijk eens naar RethinkDB. Met RethinkDB kan je triggeren op nieuwe items die toegevoegd worden aan een tabel/collection.

[BramV]

dure operatie = hoeveel data?

[Creepy]

roger128 schreef op maandag 23 november 2015 @ 17:07:
Hallo iedereen

Ik ben van plan een api met bijbehorende app, website etc te bouwen. Ik doe dit op basis van data die ik van een andere api (externe partij) naar binnen haal. Dit betreft een groot XML file met hierin alle data (ik kan de api vragen om specifieke delen van deze file,

Ok...

ik neem aan dat er een no-sql database achter deze api zit).

Je neemt aan? Mij ben je kwijt. Dat kan ja altijd navragen natuurlijk.. Je doet een aanname, en lijkt daar nogal wat op te baseren.....

Dit is een erg handig formaat: stel de data bevat auto's, dan hebben auto's altijd stoelen welke altijd bekleding hebben welke altijd een kleur hebben... et cetera. Deze data is erg mooi om een website op te bouwen: ik kan de XML naar een array parsen en vervolgens door de hele array loopen.

Echter wil ik ook nog andere dingen met de api. In het voorbeeld zou ik graag klanten informeren als er een nieuwe auto beschikbaar komt of een nieuwe stoel (etc). Dit is data die perfect is voor een sql database.

Want? Omdat? Need more info...

Ik zit dus een beetje in dubio: wat moet ik doen. De no-sql database gebruiken en hier alle andere functionaliteit in verwerken (lijkt me overigens een heel slecht idee)?

Want? Omdat? Need more info... En welke NoSQL DB bedoel je? Die van die externe API?

De no-sql gegevens in een sql database zetten om vervolgens vaak dezelfde informatie op te vragen als relatief dure operatie (joins e.d. terwijl de links altijd hetzelfde zijn)? Of is het een idee de databases aan elkaar te linken? En moet ik dan de ene database naar de andere linken (en in welke volgorde) of allebij updaten vanaf de api?

Want? Omdat? Need more info..

Een hoop vragen en waarschijnlijk ook een beetje een vaag verhaal maar ik hoop dat jullie me kunnen helpen. Alvast bedankt!

Het is nogal vaag ja. Je lijkt een NoSQL db te gebruiken, maar misschien ook niet. Maar je lijkt persee een SQL db te willen gebruiken. Doe eens gek, gooi alles in de db die jij graag wil gebruiken (met uiteraard je database model aangepast naar het type db) en ga gewoon eens testen wat het doet?

En dubbelcheck dat je de data uit je externe API mag herpubliceren, vaak mag dat simpelweg niet.

Amanush schreef op maandag 23 november 2015 @ 19:23:
Kijk eens naar RethinkDB. Met RethinkDB kan je triggeren op nieuwe items die toegevoegd worden aan een tabel/collection.

Dat kan ook prima met andere (sql) databases trouwens.

[ Voor 11% gewijzigd door Creepy op 23-11-2015 20:53 ]

[pedorus]

Ik snap het ook niet helemaal, waarom zou je nu zo graag een database willen hebben waar je niet met Structured Query Language op kan querien? In je datamodel schets je nu juist allemaal vaste relaties en zeer gestructureerde data..

[page404]

Een NoSQL database is vooral zinvol als je a) vooral key-value pairs hebt en weinig structurele data en b) als je van plan bent een distributed architecture in te zetten om grote datasets parallel te verwerken.

[Morrar]

NoSQL kan ook een document store zijn. Je zou kunnen kijken naar iets als elastic search. Dat slaat documenten op als JSON en bouwt indices op de individuele attributen. Je kunt er vervolgens heel makkelijk queries en filters op loslaten, wat me gezien je app best handig lijkt.

Je kunt ook de unieke waardes opvragen van de attributen (zie term en cardinality aggregation). Daarmee zou je bijvoorbeeld dus kunnen achterhalen welke kleuren of uitvoeringen er zijn.

Wellicht kun je de API die je aanroept ook JSON laten uitpoepen, scheelt je dan weer een conversieslag.

[ Voor 16% gewijzigd door Morrar op 27-11-2015 18:31 ]

[MSalters]

Document store? Elastic search? JSON? Nuttige technologie, maar niet voor dit probleem domein.

[MSalters]

roger128 schreef op maandag 23 november 2015 @ 17:07:
De no-sql gegevens in een sql database zetten om vervolgens vaak dezelfde informatie op te vragen als relatief dure operatie (joins e.d. terwijl de links altijd hetzelfde zijn)?

waarschijnlijk ook een beetje een vaag verhaal

Yup, vaag verhaal. Joins zijn verschikkelijk efficient, in vergelijking met bijna elke andere zoekmethode. Er zijn eigenlijk maar twee efficientere methoden: direct indexed (meest efficient, vereist dat je alleen zoekt op een index. O(1) performance, 0 flexibiliteit in key) en key-value (erg efficient, O(1) tot O(log N) maar ondersteunt exact 1 simpele query).

Aangezien jouw probleem ingewikkelder is dan je met 1 query opgelost gaat krijgen, maar je data wel gestructureerd is, is een RDBMS dus de meest efficiente methode. Maak je geen zorgen over de JOINs, zorg alleen dat die JOINs een index kunnen gebruiken.

[Gomez12]

MSalters schreef op dinsdag 01 december 2015 @ 12:32:
Document store? Elastic search? JSON? Nuttige technologie, maar niet voor dit probleem domein.

Gewoon even ter mijner info, waarom niet geschikt voor dit probleem domein?

Ik overzie het probleem domein namelijk nog niet helemaal, is die xml vast gestructureerd of kan die veranderen.
Vallen al de TS zijn wensen wel binnen de velden van de xml of moeten er nog custom functies aangehangen worden?
Wat is de grootte van de data, moet er fulltext gezocht kunnen worden?

Imho is het voornamelijk afhankelijk van de xml, maar daar wordt geen gegeven over verstrekt dus kan ik het probleem domein niet overzien...

[MSalters]

Gomez12 schreef op dinsdag 01 december 2015 @ 13:49:
[...]
Ik overzie het probleem domein namelijk nog niet helemaal, is die xml vast gestructureerd ...

Uit de TS: "Dit is een erg handig formaat: stel de data bevat auto's, dan hebben auto's altijd stoelen welke altijd bekleding hebben welke altijd een kleur hebben... et cetera"

Kortom, alles behalve ongestructureerde data.