[DB-ontwerp] Kies ...id -of- anders nl...

[drm]

Ik zit met de volgende kwestie:

Voor een website moeten er allerlei gegevens ingevuld worden over objecten. Objecten staan in de database, Types en fabrikaten ook. Maar de mogelijkheid dat mensen objecten, types of fabrikaten melden die niet in de database voorkomen moet ook geboden worden.

Oftewel, bij het formulier wordt een select-box gegenereerd met daarin (bijv.) alle objecten, en 1 veld "Anders, nl:"
Als die laatste geselecteerd is, kan men in een text-veld invullen wat het dan wel moet zijn.

Nu moeten deze gegevens in een database opgeslagen worden (uiteraard). Die tabel noemen we even "toegevoegd".

Oftewel, bij het aanbieden van dergelijk object, hebben we een tabelletje "toegevoegd" waarin (o.a) een objectID, een typeID en een fabrikaatID staat.

Wat nu als iemand "Anders, nl" invult? Dan vullen we bijvoorbeeld bij objectID "-1" in, en in een ander veld een ID naar een verwijzing in een andere tabel waarin alle ingevulde "Anders, nl:"-velden staan ofzo... 't Spreekt mij alleen niet zo aan, ik vind 't niet netjes.

Een andere oplossing is 1 extra vlaggetje aan de object-tabel toevoegen, waarin staat of het een object is wat een user heeft ingevuld dmv "Anders nl", zodat dat object ook een gewoon objectID krijgt, en netjes in de "toegevoegd" tabel kan staan. Hetgeen de gebruiker invult in het textveld, wordt dan dus gewoon toegevoegd als nieuwe record met zijn eigen ID in de object-tabel.

Nog een andere oplossing is hetzelfde idee, alleen dan een andere tabel met de door users ingevulde objecten, en in de tabel "toegevoegd" dat extra vlaggetje of het om een "Anders nl"-object gaat of een object uit de bestaande database.

Andere oplossingen kunnen misschien nog wel bedacht worden mbv n:m relaties of misschien wel enorm goeie andere ideeen

Nou is mijn vraag aan jullie: brainstorm hier eens over? Wie heeft er goede ideeen en/of tips?

ben benieuwd

_edit:
^{___________________________________________________}
Op verzoek eventjes een stukkie van het database model

Objecten:

code:

objectID (PK, autoincrement)
name (varchar)

Typen

code:

typeID (PK, autoincrement)
name (varchar)

Fabrikaten

code:

fabricID (PK, autoincrement)
name (varchar)

Restanten (dus de zgn. "toegevoegd" tabel)

code:

restantID (PK, autoincrement)
fabricID (FK)
typeID (FK)
objectID (FK)
-- nog wat meuk over toegevoegde restant --

Het eigenlijke probleem is dus wanneer iemand iets invult bij "anders, nl", waar die ingevulde data het beste kan staan in een database ontwerp. snappu?
^{___________________________________________________}

[Verwijderd]

TABLE: Objecten
id - autoincrement
fabrikaat - integer (id van fabrikaat uit fabrikaten table)
type - integer (id van type uit types table)
label - text
isCustom - boolean

TABLE: Fabrikaten
id - autoincrement
label - text

TABLE: Types
id - autoincrement
label - text

Bedoel je zoiets

[TheDane]

ik zie het probleem niet zo

ieder object, type of fabrikaat (produkt) is een entiteit met z'n eigen attributen.

Of het produkt door een gebruiker is toegevoegd lijkt me op dit moment niet zo boeiend (komt dadelijk pas

als een gebruiker uit de lijst een "Ander, nl:" kiest, dan wordt in feite een produkt toegevoegd. Dit produkt krijgt in ieder geval een eigen ID.

Daarna wordt -net zoals bij het kiezen van een bestaand produkt- een relatie gelegd tussen het produkt en de gebruiker. neem ik aan.

Ik kan even niet terugvinden of het van belang is dat als meerdere gebruikers produkten toevoegen het mogelijk moet zijn dat gebruiker A ook toegevoegde produkten van gebruiker B moet kunnen lezen; Zo ja: dan kun je denken aan een user-produkt relatie tabel

userID | produktID | produktTYPE

waarbij altijd de default produkten + de custom produkten per gebruiker gelist worden.

is dit iets of heb je het probleem niet goed uitgelegd
_{of snap ik 't niet}

[ACM]

Ik denk dat je het beste alles in dezelfde tabel terecht kan laten komen.

De toegevoegde objecten in dezelfde als de gewone objecten. En dan daar een veldje aanmaken "isToegevoegd" oid.

De meldingen wijzen dan dus allemaal naar dezelfde tabel wat over het algemeen de query-eenvoud ten goede komt

Het idee van gordijnstok dus ongeveer.

[edit]
Waarom heb je eigenlijk onderscheid tussen Object/type/fabric
WAT is het onderscheid ertussen, behalve het naampje?

[Pelle]

Hmm, ik denk dat voor al je oplossingen wel iets te zeggen is

Zelf zou ik gaan voor 2 foreign keys in de toegevoegd table; die allebei NULL mogen zijn:

code:

+-----------------------------+
| toegevoegd            |
+----+--------+---------------+
| id | object | usersubmitted |
+----+--------+---------------+
| 1  | 5    | NULL      |
| 2  | 3    | NULL      |
| 3  | NULL   | 1        |
| 4  | 8    | NULL      |
| 5  | NULL   | 2        |
+----+--------+---------------+

+------------+
| objecten   |
+----+-------+
| id | naam  |
+----+-------+
| 3  | blaat |
| 5  | melp  |
| 8  | zuut  |
+----+-------+

+-----------------------------------------------+
| usersubmitted                    |
+----+------------------------------------------+
| id | naam                      |
+----+------------------------------------------+
| 1  | dit is een door een user gesubmit object |
| 2  | en dit ook :)                    |
+----+------------------------------------------+

[Goodielover]

Je hebt een tabel Object waarin de objecten staan met een FK's naar de tabellen type en fabrikaat.

In de tabel neem je naast de FK verwijzingen ook een tekstveld op voor de "anders" gevallen. Die sla je bij het object op en niet in de type-tabel. Je FK-veld laat je in zo'n geval leeg.
Je definieert een constraint die zegt (FK-type is not null "dan en slechts dan" tekstveldType is null)
zelfde doe je voor fabrikaat.
Je ontwerpt een onderhoudsmodule die de ingevulde "anders" velden presenteert en die die waarden (al dan niet gecorrigeerd) in de Type-tabel zet en alle "anders"-velden met gelijke waarden omzet naar een FK-relatie. Je bouwt dus op die manier langzamerhand aan een rijkere Type/fabrikaat-tabel

[drm]

ACM heeft wel een goed punt wat betreft query-eenvoud als je het bij 1 Foreign key field laat. Ik voel zelf ook het meest voor die manier, moe'k zeggen.

Wat betreft Object, Fabrikaat, en Type:
Een Object is bijvoorbeeld "Heftruck".
Een Fabrikaat is bijvoorbeeld "Caterpillar".
Een Type is bijvoorbeeld "169XL blabla".

als je die dus selecteert, kun je dus een Heftruck 169XL blabla van het fabrikaat Caterpillar aanbieden

_{ACM vroeg al of het niet "fabrikant" moest zijn, maar als je het over een "fabrikant" hebt, heb je het over Sjaak de Bever uit Breda, die een dergelijke Caterpillar gefabriceerd heeft Waarom dan niet "merk"? geen idee}

[drm]

Goodielover:
Je hebt een tabel Object waarin de objecten staan met een FK's naar de tabellen type en fabrikaat.

In de tabel neem je naast de FK verwijzingen ook een tekstveld op voor de "anders" gevallen. Die sla je bij het object op en niet in de type-tabel. Je FK-veld laat je in zo'n geval leeg.
Je definieert een constraint die zegt (FK-type is not null "dan en slechts dan" tekstveldType is null)
zelfde doe je voor fabrikaat.
Je ontwerpt een onderhoudsmodule die de ingevulde "anders" velden presenteert en die die waarden (al dan niet gecorrigeerd) in de Type-tabel zet en alle "anders"-velden met gelijke waarden omzet naar een FK-relatie. Je bouwt dus op die manier langzamerhand aan een rijkere Type/fabrikaat-tabel

Waarom zou je dat dan niet doen door een vlaggetje in die andere tabellen, bijvoorbeeld iets van "confirmed" of "isok" ofzo? Boolean, dan. (voor zover dat bestaat in MySQL )

[Verwijderd]

Je denkt veel te moeilijk Jouw probleem is dus eigenlijk dat je een object wilt toevoegen waarvan je nog geen fabrikaat of type van hebt toegevoegd. Je voert dus een record in in de objecten table, maar hebt geen referentie data naar de andere tables.

Dat is niet zozeer een probleem van een databasemodel, maar een probleem van flow binnen een programma. Je moet dus voordat het object wordt aangemaakt de mogelijkheid hebben om

1) fabrikaat en type te selecteren
of
2) nieuw fabrikaat en type aan te maken

[Goodielover]

Op dinsdag 16 april 2002 10:33 schreef Gordijnstok het volgende:
Je denkt veel te moeilijk Jouw probleem is dus eigenlijk dat je een object wilt toevoegen waarvan je nog geen fabrikaat of type van hebt toegevoegd. Je voert dus een record in in de objecten table, maar hebt geen referentie data naar de andere tables.

Dat is niet zozeer een probleem van een databasemodel, maar een probleem van flow binnen een programma. Je moet dus voordat het object wordt aangemaakt de mogelijkheid hebben om

1) fabrikaat en type te selecteren
of
2) nieuw fabrikaat en type aan te maken

Je wil helemaal niet dat een willekeurige gebruiker zomaar je referentietabellen kan vullen, waar dan ook meteen de rest van de gebruikers last van hebben.
Je fabrikaat tebel zal exploderen en vol met dubbelen komen.

[drm]

Gordijnstok:
Je denkt veel te moeilijk Jouw probleem is dus eigenlijk dat je een object wilt toevoegen waarvan je nog geen fabrikaat of type van hebt toegevoegd. Je voert dus een record in in de objecten table, maar hebt geen referentie data naar de andere tables.

Dat is niet zozeer een probleem van een databasemodel, maar een probleem van flow binnen een programma. Je moet dus voordat het object wordt aangemaakt de mogelijkheid hebben om

1) fabrikaat en type te selecteren
of
2) nieuw fabrikaat en type aan te maken

Euh nee, da's te simpel. Ik geloof dat ik even wat moet vertellen over de toepassing hiervan.

Het gaat om een werkmaterieel-site. Op die site wordt (o.a.) de mogelijkheid geboden objecten als "restanten" aan te bieden. Een "restant" is dus een een object wat na diefstal of na schade geveild kan worden op die site. Snappie? Die gebruikers zijn niet zonder meer gerechtigd nieuwe typen of fabrikaten "toe te voegen". Ze kunnen hooguit een type of fabrikaat melden wat niet in de database voorkomt.

* drm hoopt dat 't zo een beetje duidelijker is...

[Verwijderd]

Op dinsdag 16 april 2002 10:35 schreef Goodielover het volgende:

[..]

Je wil helemaal niet dat een willekeurige gebruiker zomaar je referentietabellen kan vullen, waar dan ook meteen de rest van de gebruikers last van hebben.
Je fabrikaat tebel zal exploderen en vol met dubbelen komen.

Een referentietabel staat gelijk aan een object Je kunt bij wijze van ook dubbele objecten toevoegen, dat probleem hou je alleen tegen met een goede interface en ondersteuning.

Probleem is nu als ik nu zeg maar het object "Auto" toevoeg. Dan is dat eigenlijk corrupte data. Want een fabrikaat Volvo of BMW is een heel ander product, net zoals een 2.0l of een 1.6l een heel ander product is.

Je moet dus wel zorgen voor de juiste informatieverstrekking, anders heb je juist kans dat je dubbele objecten krijgt met dezelfde naam, maar toch met een ander fabrikaat en /of type.

[drm]

Object "Auto" is niets mis mee.
Fabrikaat "Volvo" ook niet.
Type "400 SL 2.0" ook niet.

Wanneer iemand een "restant" toevoegt wordt het pas interessant een relatie tussen die 3 te leggen, en dat gebeurt dus in een "restanten" tabel

is het dan echt zo moeilijk?

[Verwijderd]

Op dinsdag 16 april 2002 10:45 schreef drm het volgende:
Object "Auto" is niets mis mee.
Fabrikaat "Volvo" ook niet.
Type "400 SL 2.0" ook niet.

Wanneer iemand een "restant" toevoegt wordt het pas interessant een relatie tussen die 3 te leggen, en dat gebeurt dus in een "restanten" tabel

is het dan echt zo moeilijk?

De technische uitwerking vast niet, maar de psychologische gedachte vraagt toch wel de nodige koppen koffie en een later tijdstip

PS: waarom laat je de koppelingscolumns dan niet gewoon leeg. Je kunt ook alleen uit de objecten table het label van het object ophalen.

[drm]

take your time

Goodielover>
zou je jouw manier even wat beter kunnen onderbouwen? Dwz. zou je even uit willen leggen waarom je het niet door een apart boolean veld op zou lossen?

[Goodielover]

Een alternatief tov mijn eerdere oplossing is het bijhouden van user-added objecten met een vlaggetje.
De beheersomgeving die ik schetste zou ik altijd houden om het van User-added te kunnen upgraden naar "Standardized"

Op dinsdag 16 april 2002 10:46 schreef Gordijnstok het volgende:

[..]

De technische uitwerking vast niet, maar de psychologische gedachte vraagt toch wel de nodige koppen koffie en een later tijdstip

[drm]

Gordijnstok:
PS: waarom laat je de koppelingscolumns dan niet gewoon leeg. Je kunt ook alleen uit de objecten table het label van het object ophalen.

Omdat het "namelijk" uit "Anders, nl:" dan niet meer zoveel zin heeft...

/edit

Goodielover:
Een alternatief tov mijn eerdere oplossing is het bijhouden van user-added objecten met een vlaggetje.
De beheersomgeving die ik schetste zou ik altijd houden om het van User-added te kunnen upgraden naar "Standardized"

Uiteindelijk is dat in het "vlaggetjesmodel" _{bij C&A} niets anders dan een het vlaggetje omzetten, dus wat dat betreft zie ik nog steeds het voordeel niet in

[Goodielover]

Op dinsdag 16 april 2002 11:27 schreef drm het volgende:

[..]

Omdat het "namelijk" uit "Anders, nl:" dan niet meer zoveel zin heeft...

/edit
[..]

Uiteindelijk is dat in het "vlaggetjesmodel" _{bij C&A} niets anders dan een het vlaggetje omzetten, dus wat dat betreft zie ik nog steeds het voordeel niet in

Het voordeel zit 'm erin dat je de andere gebruikers niet die waarden laat zien die je nog niet hebt goedgekeurd.
Pas als een gegevensbeheerder de domeinwaarden heeft goedgekeurd komen ze in de lijst.
Een gebruiker die denkt dan íe een bepaalde waarde niet kan vinden en dus maar "anders" invult, is dan niet direct een vervuiler van je DB.

[dusty]

Simpel voorbeeld van : Normalisatie.

Je zal even moeten proberen om wat abstracter tegen je database model aan te kijken.

[drm]

Goodielover:
Het voordeel zit 'm erin dat je de andere gebruikers niet die waarden laat zien die je nog niet hebt goedgekeurd.
Pas als een gegevensbeheerder de domeinwaarden heeft goedgekeurd komen ze in de lijst.
Een gebruiker die denkt dan íe een bepaalde waarde niet kan vinden en dus maar "anders" invult, is dan niet direct een vervuiler van je DB.

Nee, maar goed, als je er dan toch een vlaggetje aanhangt, dan is dat vlaggetje ook meteen het criterium om het "goedgekeurd" te hebben of niet. toch?

Grootste voordeel van alleen een vlaggetje is dat je query om gegevens te laten zien (een view op de restanten) gewoon in alle gevallen hetzelfde is.

dusty:
Simpel voorbeeld van : Normalisatie.

Je zal even moeten proberen om wat abstracter tegen je database model aan te kijken.

Ehmmm heb jij de thread gelezen?

[Goodielover]

Op donderdag 18 april 2002 09:29 schreef drm het volgende:

[..]

Nee, maar goed, als je er dan toch een vlaggetje aanhangt, dan is dat vlaggetje ook meteen het criterium om het "goedgekeurd" te hebben of niet. toch?

Grootste voordeel van alleen een vlaggetje is dat je query om gegevens te laten zien (een view op de restanten) gewoon in alle gevallen hetzelfde is.
[..]

Eerste punt: Ja.

Tweede punt: Tijdens het invoer proces laat je alleen de goedgekeurde waarden zien (dus where vlaggetje = "Goedgekeurd")
Tijdens het presentatie-proces join je gewoon met de tabel en maakt het vlaggetje je niets uit. Anders loopt je join ook fout.
Maar volgens mij bedoelen we nu dus hetzelfde.

[drm]

Goodielover:
Eerste punt: Ja.

Tweede punt: Tijdens het invoer proces laat je alleen de goedgekeurde waarden zien (dus where vlaggetje = "Goedgekeurd")
Tijdens het presentatie-proces join je gewoon met de tabel en maakt het vlaggetje je niets uit. Anders loopt je join ook fout.
Maar volgens mij bedoelen we nu dus hetzelfde.

Volgens mij ook

[dusty]

Op donderdag 18 april 2002 09:29 schreef drm het volgende:
[..]
Ehmmm heb jij de thread gelezen?

Yup.

Zodra jij objecten met eigenschappen (met of zonder vlaggetje) in verschillende speciale tabellen moet gaan opslaan heb je dus niet goed genormaliseerd.

[drm]

dusty:
Yup.

Zodra jij objecten met eigenschappen (met of zonder vlaggetje) in verschillende speciale tabellen moet gaan opslaan heb je dus niet goed genormaliseerd.

Heb je dus niet goed gelezen, want het gaat dus niet om "verschillende speciale tabellen"

[ACM]

Op donderdag 18 april 2002 16:49 schreef drm het volgende:
Heb je dus niet goed gelezen, want het gaat dus niet om "verschillende speciale tabellen"

Lees idd mijn berichten es na dusty en de antwoorden daarop