Databasekeuze sensordata

[Verwijderd]

u_nix_we_all schreef op woensdag 26 juli 2017 @ 18:24:
De goede tips sneeuwen onder door een veel te diepgravende, nog-net-niet-offtopic discussie IMHO.

De 1e pagina van dit onderwerp staan alle goede tips op. Als het antwoord er staat krijg je vaak daarna een offtopic discussie. Zolang iedereen dat weet, zie ik niet in waarom dat een probleem zou zijn, en er komt ook nuttige kennis uit naar voren. Ook voor TS.

[BramV]

Verwijderd schreef op woensdag 26 juli 2017 @ 18:15:
Ik vermoed dat topicstarter al huilend is weggerend na mijn (en andermans) gezever

Haha ja ik vind hem ook dieptriest eerlijk gezegd. Zo helemaal voorbijgaan aan de vraag voor de opslag van een simpele tabel... Nu begrijp ik ook weer waarom projecten bijv. bij de overheid mislukken. Volledig voorbijgaan aan de werkbaarheid en oplevering maar puur verzanden in theorie.
En dan is niet eens het transport Arduino naar DB behandelt. Verwacht Queue oplossingen en uiteraard de frontend voor de grafiek, eindeloos praten wel of geen PHP/Net/Java/Javascript/Jquery/Angular/React/Vue...
In de tussentijd zou het bij mij al gereed zijn en draaien :-)

[ Voor 4% gewijzigd door BramV op 26-07-2017 19:01 ]

[farlane]

BramV schreef op woensdag 26 juli 2017 @ 18:46:
[...]
In de tussentijd zou het bij mij al gereed zijn en draaien :-)

pff wat maakt het nou uit of je 3 tabellen doet met een union of 1 tabel met id... Voor dit hobby project. Stel je voor zeg dat het verkeerd is. Nou nou nou..

[Shaggie_NB]

Verwijderd schreef op woensdag 26 juli 2017 @ 17:59:
[...]


Nogmaals, dat is een FK als PK gebruiken en gewoon onjuist.

Is helemaal niet onjuist!
In de informatie analyse heet dit lexicaliseren en reduceren. Zolang er geen extra attributen worden opgenomen bij die sensor mag je er geen extra tabel voor opnemen. Dit zal in elke Case-tool automatisch verdwijnen.
En lexicaliseren en reduceren gebeurd voor normaliseren. Dus als jij die toch opneemt ben je fout bezig...

[Verwijderd]

Zoals je aangeeft, vind het lexicaliseren en reduceren vóór het normaliseren plaats. En bij het normaliseren, wordt het gewoon in een andere tabel gestopt. Niets fout aan bezig.

Maar laten we er een 'agree to disagree' van maken. Ik ga de discussie verder niet voeren en het is je goed recht er anders over te denken, de TS heeft er iig niets meer aan zo.

[Shaggie_NB]

Verwijderd schreef op woensdag 26 juli 2017 @ 20:15:
Zoals je aangeeft, vind het lexicaliseren en reduceren vóór het normaliseren plaats. En bij het normaliseren, wordt het gewoon in een andere tabel gestopt. Niets fout aan bezig.

Maar laten we er een 'agree to disagree' van maken. Ik ga de discussie verder niet voeren en het is je goed recht er anders over te denken, de TS heeft er iig niets meer aan zo.

Altijd fijn die databaseontwerpers die zich niet aan het ontwerp van de informatieanalyst houden...
Databaseontwerp is geen op zich staande theorie. Het is gewoon een onderdeel van de informatieanalyse. Met de daarbij behorende modellen en volgordelijkheid...

[ Voor 12% gewijzigd door Shaggie_NB op 26-07-2017 20:25 ]

[Verwijderd]

Shaggie_NB schreef op woensdag 26 juli 2017 @ 20:20:
Altijd fijn die databaseontwerpers die zich niet aan het ontwerp van de informatieanalyst houden...

Ik ben geen 'databaseontwerper' en dit heeft niets te maken met het wel of niet houden aan wat de analist zegt. De analist ontwerpt geen database. Beetje onzinnige opmerking.

[Shaggie_NB]

Verwijderd schreef op woensdag 26 juli 2017 @ 20:25:
[...]
Ik ben geen 'databaseontwerper' en dit heeft niets te maken met het wel of niet houden aan wat de analist zegt. De analist ontwerpt geen database. Beetje onzinnige opmerking.

'Je gaat het pas zien als je het doorhebt'

[Verwijderd]

Shaggie_NB schreef op woensdag 26 juli 2017 @ 20:28:
'Je gaat het pas zien als je het doorhebt'

Klopt. En geduld. Dat moment komt, ook voor jou, vanzelf. Als je wat ouder bent wellicht.

[Creepy]

En daarmee is het nu klaar.