[DB] tabel binnen tabel/?

[H!GHGuY]

stel je even de volgende situatie voor:
meetgegevens in tabelvorm moeten voor iedere meting in DB opgeslaan worden.
de meetgegevens zijn van vaste grote/vorm. (bvb de kleurcomponenten van een bitmap met vaste grote)

wat is dan de beste manier om deze op te slaan in een DB? ik dacht aanvolgende dingen:
1) de gegevens wanuit de programmeertaal serializen en opslaan in een BLOB
voordelen: 1 tabel bevat alle metingen waarin dan ook snel 1 meting kan opgezocht + deserialzed worden.
nadelen: serializen = taalgebonden

2) elke set meetgegevens in een nieuwe tabel stoppen
voordeel: een tabel is ook in SQL een tabel
nadelen:
- SQL kent theoretisch geen volgorde zowel van kolommen als rijen (de meetgegevens zijn geordend en de volgorde is belangrijk) evt oplossen met nummering
- veel grote, lompe SQL statements (zowel CREATE TABLE als INSERT/SELECT)
- hoe 1 meting zoeken ? hoe een overzicht van alle metingen krijgen

op dit moment gaat de voorkeur wegens de voor/nadelen uit naar het serializen, maar ik vroeg me ook af of er DBMS'en zijn die een 'tabel binnen een cel/tabel' of iets gelijkaardigs ondersteunen, of als er iemand een betere methode kent om dit op te lossen. google en GoT search hielpen me alvast niet veel verder. ook bijkomstige voor/nadelen zijn welkom...

[NMe]

Ik snap niet echt wat je probleem is aangezien je een beetje abstract je verhaal vertelt, maar ik krijg het idee dat je door simpel je database te normaliseren wel gewoon een bruikbare database moet krijgen. Beide opties die je noemt zijn niet echt handig, en ik weet wel bijna zeker dat het ook op te lossen is door de normalisatieregels toe te passen.

[H!GHGuY]

normaliseren kan nou net niet...

je kan de meetgegevens voorstellen als de waarden van een bitmap in rijen en kolommen...
in het eerste voorbeeld zou'k de bitmap normaliseren en in een BLOB stoppen. Er zijn per meting nog meer gegevens over de meting zelf en die moeten er dus ook in. Er moet ik niet kunnen gezocht worden op meetgegevens.

het 2de voorbeeld zou dan misschien in jouw termen iets meer genormaliseerd zijn aangezien die dan ook 1 tabel per "bitmap" zouden vormen. maar het probleem dan is om de gegevens er terug uit te halen. rijen en tabellen hebben namelijk geen volgorde in een DB. Ook de bijkomende info moet'k dan anders opslaan.

als het nou mogelijk zou zijn om binnen 1 tabel zowel de meetwaarden als de overige info op te slaan (evt gesplitst in meerdere tabellen, normaliseren dus) dan zou ik geen tabel/meting nodig hebben en moet'k me ook geen zorgen maken om de taal waarin het programma geschreven wordt

[Voutloos]

Die 2e optie is sowieso de meest ranzige van de 2 en moet je meteen doorstrepen. Ik kan me niet voorstellen dat een veldje maken per "pixel" ooit efficiënter kan zijn dan desnoods je totaal zelf geschreven wrapper (serializer) voor de data.

Gebruik je DB voor de relationele data, je bitmap is gewoon een kluwe rauwe data, oftewel blob. En anders sla je in de DB het pad naar de bitmap op, maar dan krijg je deze discussie weer: MySql en veel BLOB data en er was een jaar terug nog een behoorlijk groot topic over blobs/plaatjes of filenames in de DB en efficiëntie, maar die konik zo gauw niet vinden.

[ Voor 5% gewijzigd door Voutloos op 26-04-2005 20:15 ]

[H!GHGuY]

Voutloos schreef op dinsdag 26 april 2005 @ 20:15:
Die 2e optie is sowieso de meest ranzige van de 2 en moet je meteen doorstrepen. Ik kan me niet voorstellen dat een veldje maken per "pixel" ooit efficiënter kan zijn dan desnoods je totaal zelf geschreven wrapper (serializer) voor de data.

Gebruik je DB voor de relationele data, je bitmap is gewoon een kluwe rauwe data, oftewel blob. En anders sla je in de DB het pad naar de bitmap op, maar dan krijg je deze discussie weer: MySql en veel BLOB data en er was een jaar terug nog een behoorlijk groot topic over blobs/plaatjes of filenames in de DB en efficiëntie, maar die konik zo gauw niet vinden.

als ik met die BLOB's werk dan zal het wel 1 tabel met ID+BLOB zijn, en de rest van de gegevens in een andere, kwestie van de efficientie. die BLOB's zullen het em niet doen als het over inefficientie zou gaan.

maar er is dus geen andere mogelijkheid om zoiets te realiseren?

[ReallyStupidGuy]

Voutloos schreef op dinsdag 26 april 2005 @ 20:15:
Die 2e optie is sowieso de meest ranzige van de 2 en moet je meteen doorstrepen.

Ranzig dat was het woord wat ik zocht toen ik dit verhaal aan het typen was


Ik heb zo niet een pasklare oplossing voor je, ook al weer omdat het wel een beetje abstract is wat je verteld. Ik heb nu zelf voor ogen heb is een aantal sensoren die elk uur een meting doen, die worden in een sheet gezet en die sheet wordt elke dag opgeslagen.

Ik heb twee ideetjes waar je misschien wat mee kunt:


1: Sommige databases (of misschien wel veel?) ondersteunen fields met als type array, op die manier kun je het iets netter en beheersbaarder houden dan met blobs lijkt me.

2: Misschien kun je de resultaten toch nog in een aparte tabel zetten (in mijn voorbeeld: Tijd, sensor, waarde) en de rapporten in een tabel (datum, .......).

Mijn voorkeur zou uitgaan naar de tweede omdat dat het makkelijkste is met zoeken en beheren, maar dan heb je wel meer dan 1 tabel wat je niet wilt (snap niet precies de reden maargoed...).

Het lijkt me iig niet handig om voor elk raport een aparte tabel aan te maken, dat is niet normaliseren en niet echt de bedoeling van relationele databases. Je maakt het je dan heel lastig om informatie te raadplegen en om het een beetje beheersbaar te houden. (leuke overzichtjes, backups ed worden wel erg lastig!)

Over de keuze van de taal: Als je een database gebruikt maakt het volgens mij weinig uit of je 1 of 2 tabellen hebt qua taal. Het lijkt misschien iets omslachtiger dan alles in 1 tabel "kwakken" maar als je iets meer wilt is het veel praktischer.

Normaliseren:
Uit mijn voorbeeld

info op sheet

rapportdatum:
Medewerker:
___________0.00 1.00 2.00 3.00
sensor1
sensor2

wordt (alles in 1 regel zetten):
rapportdatum, medewerker,sensor1 0.00u, sensor2 0.00u, sensor1 1.00u, sensor2 1.00u, ...............
wordt:
tabel rapporten:
Rapportdatum, medewerker
tabel uitlezing:
sensor, tijdstip, waarde

Nou is dit niet meer echt normaliseren maar het gaat er om dat je redudantie voorkomt.

[ Voor 10% gewijzigd door ReallyStupidGuy op 26-04-2005 20:39 ]

[Varienaja]

Als je gegevens in een database stopt, die je vervolgens niet terug kunt queryen dan heb je geen database nodig. Een tabel met ID en een BLOB is zoiets.. daar kan je dus niks mee. Sla dan liever bestandjes op in een of andere directory.

Vergis je niet; databases zijn erg krachtig, en doen helemaal niet zo moeilijk over brede tabellen of grote queries. Maar post eens wat voorbeelden van data die je op wilt slaan. Dan kunnen we misschien meedenken over een mooie manier om dat op te slaan in een database.

[H!GHGuY]

ReallyStupidGuy schreef op dinsdag 26 april 2005 @ 20:35:
[...]

Ranzig dat was het woord wat ik zocht toen ik dit verhaal aan het typen was

1: Sommige databases (of misschien wel veel?) ondersteunen fields met als type array, op die manier kun je het iets netter en beheersbaarder houden dan met blobs lijkt me.

Het lijkt me iig niet handig om voor elk raport een aparte tabel aan te maken, dat is niet normaliseren en niet echt de bedoeling van relationele databases. Je maakt het je dan heel lastig om informatie te raadplegen en om het een beetje beheersbaar te houden. (leuke overzichtjes, backups ed worden wel erg lastig!)

Over de keuze van de taal: Als je een database gebruikt maakt het volgens mij weinig uit of je 1 of 2 tabellen hebt qua taal. Het lijkt misschien iets omslachtiger dan alles in 1 tabel "kwakken" maar als je iets meer wilt is het veel praktischer.

het gaat em niet over normaliseren an sich, die theorie en praktijk hebben we wel op school gekregen en met een beetje common sense maak je ook al een vrij genormaliseerde DB.

dat van die array zal ik echter eens verder onderzoeken.

veel info over hoe de metingen eruit zien kan'k eigenlijk niet geven, maar het bitmap verhaal is een sterke veralgemening en vereenvoudiging. een 2D tabel met meetgegevens waarvan de grootte constant is. De metingen moeten niet opgezocht kunnen worden adhv de data maar enkel adhv de metadata (welke meting). De data zelf moet enkel binnen de software mee gerekend worden.
vb dmv bitmaps: zoek bitmap xyz op en maak er een JPG van en toon die aan de gebruiker.

dat die 2de optie ranzig was, voelde ik ook wel, maar mss was er net dit ene ding wat ik over het hoofd zag wat de oplossing net weer mooier en bruikbaarder maakte.

Varienaja schreef op dinsdag 26 april 2005 @ 22:52:
Als je gegevens in een database stopt, die je vervolgens niet terug kunt queryen dan heb je geen database nodig. Een tabel met ID en een BLOB is zoiets.. daar kan je dus niks mee. Sla dan liever bestandjes op in een of andere directory.

Vergis je niet; databases zijn erg krachtig, en doen helemaal niet zo moeilijk over brede tabellen of grote queries. Maar post eens wat voorbeelden van data die je op wilt slaan. Dan kunnen we misschien meedenken over een mooie manier om dat op te slaan in een database.

tjah, er komen waarschijnlijk nog wel meer gegevens in de DB dan enkel die meetgegevens.
waarschijnlijk komen ook verwerkte resultaten , metadata en andere gegevens in die DB.

daarenboven moeten de gegevens waarschijnlijk zowel via de software als via een web-app beschikbaar zijn. Dus een DB lijkt me een geschikte keus...