[database] Opslag variabel aantal kolommen

Pagina: 1
Acties:

  • orf
  • Registratie: Augustus 2005
  • Laatst online: 20:00
Voor een webapplicatie wil ik het mogelijk maken voor gebruikers / bezoekers een cvs / dbf / txt / etc te importeren. Er moet dan een soort wizard doorlopen worden, waarin de juiste labels aan kolommen verbonden worden.

Door die data te combineren met een tabel die ik in de database heb staan moet daar data uitkomen die bruikbaar is. Dat klinkt wellicht wat cryptisch, maar het gaat er bijvoorbeeld om dat een bezoeker een csv file met de volgende gegevens toevoegt:

naam
adres
woonplaats
leeftijd
geslacht
opleidingsniveau


Op basis van bijvoorbeeld de woonplaats knoop ik wat gegevens aan een record vast en groepeer ik ze. Klik je op een record dan krijg je de overige gegevens te zien uit de CSV.

Elke csv file kan verschillend zijn, als er maar één kolom is waarop 'ge-joint' kan worden.

Meestal heb ik best ideeen om een database te normaliseren, maar in dit geval weet ik niet wat een goed model is, zodat een bezoeker ook eerdere importacties nog eens terug kan kijken en alle data op een slimme manier opgeslagen is.

Iemand ervaring met zulk soort variabele kolommen?

  • JHS
  • Registratie: Augustus 2003
  • Laatst online: 04-01 15:49

JHS

Splitting the thaum.

En al die gegevens zijn volledig willekeurig :) ? Ik betwijfel of het handig en nodig is om je data op die manier op te slaan, maar zoja, zou ik zoiets doen, als ik je goed begrijp:

[b]datas[/b]
  id
  data
  row_id (fk)
  column_id (fk)

[b]rows[/b]
  id
  title

[b]columns[/b]
  id
  title


Zo sla je alle waarden op, en kan je bekijken wat voor kolom het is. Omdat je verschillende kolomwaarde als een record moet kunnen zien associeer je het ook nog 's met een record_id. Het grootste nadeel hiervan is, buiten de performance, denk ik dat je voor het datas.data veld niet een efficiënt en waarschijnlijk vooral groot type moet kiezen :) .

DM!


  • orf
  • Registratie: Augustus 2005
  • Laatst online: 20:00
Inderdaad zijn de gegevens volledig willekeurig, één kolom moet gedefinieerd worden, de anderen zijn volledig vrij.

Het zal nooit om grote data gaan, denk aan gegevens als inkomen, leeftijd, geslacht, opleiding, etc.
In de tabel datas zal dan waarschijnlijk al de gedefineerde kolom kunnen, met iets van een sessie_id. Dan moet alles redelijk terug te halen zijn.

Ik kan hier wel wat mee denk ik, bedankt. :)

  • JaQ
  • Registratie: Juni 2001
  • Laatst online: 18:23

JaQ

orf schreef op woensdag 14 juni 2006 @ 18:35:
Inderdaad zijn de gegevens volledig willekeurig, één kolom moet gedefinieerd worden, de anderen zijn volledig vrij.

Het zal nooit om grote data gaan, denk aan gegevens als inkomen, leeftijd, geslacht, opleiding, etc.
In de tabel datas zal dan waarschijnlijk al de gedefineerde kolom kunnen, met iets van een sessie_id. Dan moet alles redelijk terug te halen zijn.

Ik kan hier wel wat mee denk ik, bedankt. :)
Zoals mijn grote held Tom Kyte als eens verteld heeft: je kan met 4 tabellen alles opslaan wat je maar wilt:

code:
1
2
3
4
5
6
7
8
9
10
11
12
Create table objects ( oid int primary key, name varchar2(255) );

Create table attributes 
( attrId int primary key, attrName varchar2(255), 
datatype varchar2(25) );

Create table object_Attributes 
( oid int, attrId int, value varchar2(4000), 
primary key(oid,attrId) );

Create table Links ( oid1 int, oid2 int, 
primary key (oid1, oid2) );


Zie hier

Mocht die niet werken door die sessie string, zoek maar eens op "Query on Design" op zijn site.

verder roept hij heel hard: Do not use Generic Data Models en daarin heeft hij groot gelijk ;)

Egoist: A person of low taste, more interested in themselves than in me