[sql db] automatisch aanmaken meerdere kolommen

[mkromkamp]

Gegroet Twkrs,

Voor het eerst kwam ik eigenlijks een vrij logisch probleem tegen. Het gaat om het volgende:

Normaliter stel je in je SRS vast wat de applicatie moet kunnen. Laten we als voorbeeld een applicatie nemen welke vergader agendas gaat opslaan. Nou is het mogelijk om al je agenda punten in een enkele kolom op te slaan maar laten we even als voorbeeld nemen dat we per agenda item een apparte kolom willen.

In onze specificatie hebben we initieel een maximum aantal van 4 agenda punten opgenomen. Dit gaat allemaal goed totdat het moment daar is dat de gebruikers een vijfde agenda punt aan willen maken. Nou kunnen we natuurlijk een kolommetje toevoegen en daarmee snel het probleem oplossen. Maar het zou natuurlijk veel praktischer zijn dat wanneer een gebruiker meer agenda punten aan wil maken daarvoor gewoon een knop heeft in zijn GUI. Ofwel: gebruiker klikt op "new item", aangezien dit zijn 5e item is zal de DB/ je programmeerwerk automatisch een vijfde kolom aanmaken?

Daarmee komen bij mij de volgende vragen dus op:

- Is mijn logica foutief? Zo ja, hoe zou je dit het beste op kunnen lossen.
- Hoe kun je dit realiseren? Het gaat even om het princiepe en niet om een specifieke prog. taal.

Alvast bedankt.

Groet,

M

[Verwijderd]

Het beste kun je database ongeveer als volgt opstellen:

vergader_types
type_id
name

vergader_items
item_id
type_id (verwijzend naar vergader_types)
name
time
etc...

[fleppuhstein]

Je model is geheel fout. Het gaat hier duidelijk om een 1 op N relatie waarbij je dus met een tweede tabel zou moeten werken, of misschien zelfs een koppel tabel, omdat het ook nog een N op N relatie zou kunnen zijn.

Back to the drawing board dus.

[hostname]

Zo ontstaan dus dingen als dit.

[..] Nou is het mogelijk om al je agenda punten in een enkele kolom op te slaan maar laten we even als voorbeeld nemen dat we per agenda item een apparte kolom willen.[..]

Hier gaat het dus al fout. Waarom zou je dat willen? Het is totaal tegen de principes van het normaliseren in. Je houdt er ook echt geen betere applicatie of sourcecode aan over, en voor je database is het ook niet beter.

[mkromkamp]

Ah. En volgens mij is het koffie tijd

Mijn logica is iets minder brilliant in dit opzicht

Het komt idd gwn neer op een 1 tot n relatie. Het zou totaal onlogisch zijn en niet fris voor je DB integriteit/ security om vanuit je prog code extra kolommen aan te maken.

Ik dank het tweaker orakel voor de uitleg

[Mike2k]

Kijk, als je er nog niet bekend mee bent, naar outer join. Dat wordt gebruikt voor dit soort 1 op n relaties.

[Cobalt]

-

[ Voor 147% gewijzigd door Cobalt op 30-08-2009 23:58 ]

[Gomez12]

Btw, omdat het soms toch wel handig kan zijn ( bijv voor temp tabellen waar je eerst een willekeurig bestand inleest om daarna het bestand via een interface te gaan mappen / normaliseren in je normale data stroom ). Wordt bij ons veelvuldig gebruikt, een klant leest een willekeurig bestand in in de dbase.
Hierna volgt een scherm om de kolommen te benoemen, na het benoemen van de kolommen vinden er enkele integriteitschecks plaats en daarna wordt de data naar de "echte" dbase overgezet en wordt de tmp-table weer verwijderd.
En dit alles onder het motto, je moet toch iets als mensen een bestand van 500mb van boven tot onder willen kunnen previewen / doorzoeken etc.

Je kan gewoon de tabel-definities aanpassen etc.
In mysql kan dit gewoon met alter table