JSON data uit SQL Server 2014

[Verwijderd]

Voor een interne website met wat AngularJS zou ik als brondata het liefst gebruik maken van JSON bestanden, aangezien dat formaat native is voor Angular. (waarom Angular vraag je je misschien af? puur als experiment om kennis op te doen)

De data staat momenteel in een SQL Server 2014 database en het betreft redelijk eenvoudige datasets voor een dashboard. (de complexiteit om de datasets te vergaren zit al in de SQL queries)

Nu heeft SQL Server 2016 de geweldige 'FOR JSON' functie die er voor zorgt dat de output netjes in JSON formaat is, 2014 heeft die niet maar overigens wel de 'FOR XML' functie.

Nu zit ik zelf tegen een aantal scenario's aan te hikken, maar ze lijken me nogal complex voor zo'n 'eenvoudige vraag'.
- XML converten naar JSON met behulp van b.v. Python
- XML gebruiken in Angular (wat ik zo snel heb gelezen werkt dat niet of niet ideaal)
- Database komt voort uit een Python-Django project, Angular in de Django templates gebruiken zou een optie kunnen zijn maar kan ik dan de views van Django gebruiken als bron voor Angular? (nog niet echt iets duidelijks voor kunnen vinden)
- datasets van MSSQL importeren naar een SQLite3 database, om JSON uit een SQLite3 database te halen heb ik al wat voor gevonden.

Er is geen noodzaak dat de data live moet zijn, een update per uur zou voldoende moeten zijn dus wellicht dat ik het een of ander kan automatiseren in cronjobs.

Heeft iemand een suggestie n.a.v. bovenstaande scenario's of misschien een heel ander idee? (upgraden naar SQL Server 2016 zit er helaas niet in)

[Ventieldopje]

Ik zou een tussenlaag gebruiken om de data aan je Angular app te geven, soort van API In welke taal die geschreven is maakt dan niet uit, zolang hij maar de juiste response (JSON) geeft. Zo koppel je de front-end los van je back-end.

[analogue]

De meeste webframeworks hebben tegenwoordig een JSON formatter en kunnen objecten omzetten naar JSON output. Zoals Ventieldopje al aangeeft is het handiger om dan een API/webservice te maken die je data op een RESTful manier kan ontsluiten.

Angular kan ook niet direct met een DB praten aangezien dat een frontend framework is, dus je ontkomt niet aan een HTTP (makkelijkste) service om alles binnen te halen.

[HansvDr]

Met een paar regels php, c# vb, asp of welke dan ook zet je je datasets zo om naar json.

[Morrar]

Als je niet vastzit aan MSSQL, waarom dan niet kijken naar een document store zoals ElasticSearch, Mongo of CouchDB? Kun je de JSON documenten 1 op 1 vanuit je applicatielaag uit of in je database halen, zonder dat er een conversieslag nodig is. Als je een schema over de data nodig hebt kun je dat achteraf opbouwen. Voordeel is ook dat je horizontaal kunt schalen (cluster) en bij elastic bijvoorbeeld snel kunt zoeken en dashboards kunt maken in Kibana.

Afhankelijk van hoe je input data eruit zien zijn er meerdere mogelijkheden om het naar JSON te krijgen en in te laden. ElasticSearch kan met LogStash bijvoordeeld heel makkelijk serverlogs inladen.

[ Voor 20% gewijzigd door Morrar op 21-12-2016 13:31 ]

[Verwijderd]

Bedankt voor de reacties allemaal, ik ga even kijken hoe ik jullie input kan inpassen!

[Gomez12]

Morrar schreef op woensdag 21 december 2016 @ 13:15:
Als je niet vastzit aan MSSQL, waarom dan niet kijken naar een document store zoals ElasticSearch, Mongo of CouchDB?

Gewoon even ter mijner informatie maar waarom zou je hier een document store voor neerzetten? Wat is het voordeel dat dat oplevert?

Voor een dashboard zou ik hooguit een document store misbruiken door er geen "echte" documenten in op te slaan, maar meer een time-series ding etc of een rdbms setup.
Idealiter zou ik voor een compleet dashboard alle 3 de opties gebruiken, maar als je tool set beperkt is tot 1 van die zou je het daarin kunnen frotten wmb, Maar een rdbms vervangen door een document store voor een dashboard, daar zou ik niet snel aan beginnen.
De gewenste datastructuur leent zich veelal niet voor een documenten setup. Ik hoef niet 10.000 documenten te hebben in 1 grafiek waarbij elk documentje de legenda en as-info bevat, ik heb wat omliggende waardes en ik heb een zooitje punten. Perfect voor een rdbms of een time-series ding.

Kun je de JSON documenten 1 op 1 vanuit je applicatielaag uit of in je database halen, zonder dat er een conversieslag nodig is.

In wezen is er geen enkele document database die ik ken die dat adviseert, ja het kan. Alleen elke serieuze speler zal zeggen dat een document-store daar bijna nooit de beveiliging etc voor ingebouwd heeft die nodig is voor een rechtstreekse koppeling, alles en iedereen zal je adviseren om er middleware tussen te stoppen waarin je de beveiliging etc kan regelen ipv dat iemand met een ongelukkig commando je hele document store leeggooit.

[Morrar]

Gomez12 schreef op woensdag 21 december 2016 @ 23:55:
[...]

Gewoon even ter mijner informatie maar waarom zou je hier een document store voor neerzetten? Wat is het voordeel dat dat oplevert?

Voor een dashboard zou ik hooguit een document store misbruiken door er geen "echte" documenten in op te slaan, maar meer een time-series ding etc of een rdbms setup.
Idealiter zou ik voor een compleet dashboard alle 3 de opties gebruiken, maar als je tool set beperkt is tot 1 van die zou je het daarin kunnen frotten wmb, Maar een rdbms vervangen door een document store voor een dashboard, daar zou ik niet snel aan beginnen.
De gewenste datastructuur leent zich veelal niet voor een documenten setup. Ik hoef niet 10.000 documenten te hebben in 1 grafiek waarbij elk documentje de legenda en as-info bevat, ik heb wat omliggende waardes en ik heb een zooitje punten. Perfect voor een rdbms of een time-series ding.

Natuurlijk sla je de leganda of assen niet op in het document...

Voor http logs sla je bijvoorbeeld IP, request, referrer, user agent, request, methode, response en timestamp op in het document. Een document bevat dan al deze waarden tezamen.

Bij het query-en haal je de info uit documenten die je nodig hebt. Met Elastic kun je bijvoorbeeld alle unieke user agents ophalen en in een pie chart duwen. De leganda wordt dan dynamisch aangemaakt natuurlijk.

Voor time-series heb je soortgelijke ingebouwde tooling, zoals berekenen van moving average of afgeleidde over een time window.

Voordeel van de doc store is dat je de ruwe data al in JSON formaat hebt en dus zo kunt uitleveren en tegelijkertijd ook aggregaten e.d. kunt opvragen. Omdat clusters horizontaal schalen zal de performance ook beter zijn dan bij een RDBMS.

[...]

In wezen is er geen enkele document database die ik ken die dat adviseert, ja het kan. Alleen elke serieuze speler zal zeggen dat een document-store daar bijna nooit de beveiliging etc voor ingebouwd heeft die nodig is voor een rechtstreekse koppeling, alles en iedereen zal je adviseren om er middleware tussen te stoppen waarin je de beveiliging etc kan regelen ipv dat iemand met een ongelukkig commando je hele document store leeggooit.

Management van rechten wordt steeds volwassener. Bij Elastic kun je rollen en rechten prima via Shield afregelen. Hardware failure is natuurlijk al afgevangen door de cluster opzet. Backups moet je natuurlijk voor beide soorten systemen opzetten.

[ Voor 6% gewijzigd door Morrar op 22-12-2016 00:33 ]