[Normaliseren] Artikelen aan order vast of orderregel?

[Verwijderd]

Ik ben bezig met een order systeem, wat ik uitsluitend schematisch op papier moet hebben.
Mijn vraag is echter;

Als ik een tabel heb met daar in alle artikelen.
En ik heb een tabel met orders die gelinkt staat aan orderregels

Waar link ik dan de tabel artikelen aan?

Het kan aan order (dat is ook de meest logische keuze vind ik zelf) want
een order kan 1 of meerdere (1:n) artikelen bevatten.
En orderregel klinkt minder logisch, want elke orderregel bevat maximaal 1 artikel.
Alleen het artikel kan in een groter aantal dan uitsluitend 1 worden besteld.

Ik snap het normaliseren dus opzich wel, maar ik zie even het licht niet.
Kan iemand me even een stukje op weg helpen?

[whoami]

Wat denk je zelf ?

Aan wat link je een artikel ? Schrijf eens gewoon op een blad papier hoe een order er voor een bepaalde klant moet uitzien; je zult zien dat hij bv verschillende artikels in één order bestelt.

Dan is het toch logisch dat je die artikels aan een orderregel koppelt, aangezien je anders nooit meer dan 1 verschillend artikel per order kunt bestellen.

[ Voor 64% gewijzigd door whoami op 06-09-2005 15:40 ]

[P_de_B]

Je hebt toch meerdere artikelen per order, die sla je in de orderregels op m.i., dus wordt de tabel artikelen aan orderregels gelinkt.

[Verwijderd]

whoami schreef op dinsdag 06 september 2005 @ 15:39:
Wat denk je zelf ?

Aan wat link je een artikel ?
Hoeveel artikels kan men per order bestellen ?

Wat ik denk stond er toch.

Ik ben alleen niet zeker van me zaak.
Omdat ik met deze 2 regeltjes in me kop zit

1: Een order kan 1 of meerdere artikelen bevatten
2: Elke orderregel bevat maar 1 artikel (wat eventueel in een groter aantal besteld kan worden)

[whoami]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:41:
[...]

Wat ik denk stond er toch.

Mijn bedoeling was, om je nog eens te laten nadenken.

1: Een order kan 1 of meerdere artikelen bevatten
2: Elke orderregel bevat maar 1 artikel (wat eventueel in een groter aantal besteld kan worden)

Ja, en een order bestaat uit meerdere orderregels, dus je eerste idee was fout.

[Verwijderd]

whoami schreef op dinsdag 06 september 2005 @ 15:42:
[...]

Mijn bedoeling was, om je nog eens te laten nadenken.


[...]


Ja, en een order bestaat uit meerdere orderregels, dus je eerste idee was fout.

Ja dat snap ik wel, maar elke orderregel heeft toch maar 1 artikel.
dus orderregel->artikel kan dan in mijn ogen nooit 1:n zijn?

[Dido]

Maar een orderregel bevat misschien nog wel meer dan alleen een artikel? Een aantal, bijvoorbeeld?

Een artikel kan daarentegen misschien wel op meerdere orderregels voorkomen

[ Voor 30% gewijzigd door Dido op 06-09-2005 15:46 ]

[curry684]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:41:
[...]

1: Een order kan 1 of meerdere artikelen bevatten

Nul of meerdere zelfs. Wat je met deze gedachte impliceert is dat je een koppeltabel zou willen wellicht, omdat een artikel in meerdere orders kan, en een order meerdere artikelen kan bevatten. Die assumptie klopt, dus je hebt inderdaad een tabel nodig met een FK naar Order en een FK naar Artikel.

Kijk nu nog eens even goed naar wat je als definitie voor OrderRegel had bedacht

[whoami]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:44:
[...]


Ja dat snap ik wel, maar elke orderregel heeft toch maar 1 artikel.
dus orderregel->artikel kan dan in mijn ogen nooit 1:n zijn?

1 'type' artikel ja, en zoals Dido al zei; een 'aantal' kolom.
Een orderregel kan maar één type artikel bevatten, maar, een order kan meerdere orderregels bevatten.

Op die manier krijg je het dus voor elkaar dat een order meerdere artikels kan bevatten (via de orderregels tabel dus).

[Nick_S]

Ik zou zelfs Order - Orderregel en Artikel gescheiden houden. Wat als je een artikel uit je assortiment wilt schrappen, schrap je dan ook alle Orderregels en de daarbij behorende Orders?

Een Orderregel zou dan bijvoorbeeld uit een:

Aantal
Artikelnummer
Artikelomschrijving
Prijs (per Artikel)

kunnen bestaan.

[ Voor 1% gewijzigd door Nick_S op 06-09-2005 16:06 . Reden: daarbijbehorende is geen enkel woord ]

[Verwijderd]

Nick_S schreef op dinsdag 06 september 2005 @ 16:06:
Ik zou zelfs Order - Orderregel en Artikel gescheiden houden. Wat als je een artikel uit je assortiment wilt schrappen, schrap je dan ook alle Orderregels en de daarbij behorende Orders?

Een Orderregel zou dan bijvoorbeeld uit een:

Aantal
Artikelnummer
Artikelomschrijving
Prijs (per Artikel)

kunnen bestaan.

Wat zou je nou precies gescheiden houden en welke niet, want dat valt niet echt op te maken uit je eerste zin.

Ik snap wel je punt van dat artikel verwijderen.

[Bosmonster]

artikelomschrijving is iets dat bij het artikel hoort neem ik aan.

Het 'schrappen' van artikelen lijkt me ook niet zo verstandig. Geef er dan een status aan van 'niet meer leverbaar' oid. Zo breek je tenminste geen oude orders.

[Crazy-]

idd, ik zou 3 tabellen maken

artikelen
orders
orderregels

in orderregels vind je relaties naar artikelen (en per order regel: aantal!) en relaties naar orders (order ID)

En artikelen verwijderen moet jei dd niet aan beginnen, anders kom je in de problemen met oude orders

[ Voor 23% gewijzigd door Crazy- op 06-09-2005 16:12 ]

[Verwijderd]

Bosmonster schreef op dinsdag 06 september 2005 @ 16:10:
artikelomschrijving is iets dat bij het artikel hoort neem ik aan.

Het 'schrappen' van artikelen lijkt me ook niet zo verstandig. Geef er dan een status aan van 'niet meer leverbaar' oid. Zo breek je tenminste geen oude orders.

no offence, maar dat is het punt niet, dat komt allemaal dik in orde

Ik heb nu order aan orderregel gekoppeld en orderregel aan artikel.
Maar hoe ik ook kijk, het bijbehorende verhaaltje schrijf en alles check
ben ik toch nog niet zeker van m'n zaak

[a3konijn]

Maar m.b.t. prijs heeft hij wel een goede. Deze zou ik ook bij orderregel opslaan. Want als je prijs van je artikel wijzigt dan is je order opeens niet meer hetzelfde als dat hij ingevoerd is.

[Nick_S]

Verwijderd schreef op dinsdag 06 september 2005 @ 16:10:
[...]

Wat zou je nou precies gescheiden houden en welke niet, want dat valt niet echt op te maken uit je eerste zin.

Ik snap wel je punt van dat artikel verwijderen.

Ik zou dus je Artikel noch aan Order noch aan Orderregel hangen. Dit zodat je altijd oude facturen/pakbonnen (wat ook met Orders te maken heeft) terug kunt halen, ongeacht je wijzigingen in Artikelen.

Dit introduceert wel wat redundantie, maar je kunt later altijd je originele Orders terughalen. (Dit kan bijvoorbeeld handig zijn voor bewaarplicht en dergelijke)

[Edit]

Misschien is dit verschil wel een voorbeeld tussen een compleet genormaliseerde database en een praktisch bruikbare database.

[ Voor 10% gewijzigd door Nick_S op 06-09-2005 16:18 ]

[Verwijderd]

a3konijn schreef op dinsdag 06 september 2005 @ 16:16:
Maar m.b.t. prijs heeft hij wel een goede. Deze zou ik ook bij orderregel opslaan. Want als je prijs van je artikel wijzigt dan is je order opeens niet meer hetzelfde als dat hij ingevoerd is.

Prijs sla ik inderdaad ook bij de order op, want je prijs kan in verloop van tijd natuurlijk varieren.
Is het door aanbiedingen, of door dat er een nieuw artikel op de markt is en je van je oude voorraad af wilt.

[whoami]

En toch is het juist.

Stel je gewoon eens voor hoe een order er uit ziet.

Een order bevat een datum, een order is voor een klant.
En op een order staan er verschillende regels, en iedere regel bevat dan een verwijzing naar het bestelde artikel, en het aantal ervan.

Een Order bestaat dus uit orderregels, en iedere orderregel verwijst naar één artikel.

[Crazy-]

whoami schreef op dinsdag 06 september 2005 @ 16:17:Een Order bestaat dus uit orderregels, en iedere orderregel verwijst naar één artikel.

En die order regel (lees: artikel) moet je dus apart opslaan in je database, anders kom je inderdaad in de problemen met prijswijzigingen (lees: archief)

[Verwijderd]

whoami schreef op dinsdag 06 september 2005 @ 16:17:
en iedere orderregel verwijst naar één artikel.

Maar orderregel naar artikel is dan nog wel steeds een 1:n relatie toch?

[whoami]

Crazy- schreef op dinsdag 06 september 2005 @ 16:19:
[...]


En die order regel (lees: artikel) moet je dus apart opslaan in je database, anders kom je inderdaad in de problemen met prijswijzigingen (lees: archief)

Ja, dat zeg ik toch niet ? Ik beweer toch niet dat je dat niet moet doen ?
Je artikel sla je idd apart op, maar de prijs van het artikel (de prijs op moment van bestellen), neem je wel op in je order-regel.
(Al is dat bij facturen veel belangrijker).

[Crazy-]

Normaliter maak je van een order een factuur, dus inderdaad prijzen (hetzij kortingen e.d.) moet je inderdaad apart meenemen in een orderregel

[Nick_S]

Verwijderd schreef op dinsdag 06 september 2005 @ 16:20:
[...]

Maar orderregel naar artikel is dan nog wel steeds een 1:n relatie toch?

Elke Orderregel kan toch maar 1 soort Artikel bevatten? Dus lijkt mij een 1:1 relatie beter op zijn plaats als je toch een relatie wil. (Lees ook mijn andere posts over wel of geen relatie)

Af en toe een niet zo helder moment.

[ Voor 7% gewijzigd door Nick_S op 06-09-2005 16:35 ]

[Verwijderd]

Nick_S schreef op dinsdag 06 september 2005 @ 16:25:
[...]


Elke Orderregel kan toch maar 1 soort Artikel bevatten? Dus lijkt mij een 1:1 relatie beter op zijn plaats als je toch een relatie wil. (Lees ook mijn andere posts over wel of geen relatie)

Ik hou niet van 1:1 relaties in modellen. Al zou het in dit geval wel mogelijk zijn omdat je repeating
groups hebt (als het zo heet). Dus moet je het verder uit normaliseren.
Maar normaal zou ik zeggen, 1:1 relaties kan je de tabellen net zo goed samen voegen.
Dat wil ik hier dus absoluut niet he, want dat gaat niet, even voor de duidelijkheid

[bigbeng]

1 op 1? dacht het niet, dan kun je een artikel maar in 1 orderregel gebruiken en daarna niet meer... das niet logisch.

[leuk_he]

Een artikel kan in de praktijd best vaker voorkomen op eenorder.

-Deelleveringen. Lever de 1e keer 100 stuks uit en de 2e keer 200, echter wel in 1 order want de kortingregelingen gaan factuur gaan op order nivo.
-Verschillnede voorwaarden. quantum kortingen (10 artikelen gratis meeleveren ofzo)

Order
|
orderregel
|
artikel

[curry684]

Verwijderd schreef op dinsdag 06 september 2005 @ 16:20:
[...]

Maar orderregel naar artikel is dan nog wel steeds een 1:n relatie toch?

Dat klopt en dat is correct. Anders mag je idd nooit meer een artikel aan iemand anders leveren

Lees dit ook nog even:

curry684 schreef op dinsdag 06 september 2005 @ 15:46:
[...]

Nul of meerdere zelfs. Wat je met deze gedachte impliceert is dat je een koppeltabel zou willen wellicht, omdat een artikel in meerdere orders kan, en een order meerdere artikelen kan bevatten. Die assumptie klopt, dus je hebt inderdaad een tabel nodig met een FK naar Order en een FK naar Artikel.

Kijk nu nog eens even goed naar wat je als definitie voor OrderRegel had bedacht

[Verwijderd]

bigbeng schreef op dinsdag 06 september 2005 @ 16:27:
1 op 1? dacht het niet, dan kun je een artikel maar in 1 orderregel gebruiken en daarna niet meer... das niet logisch.

Dat is toch ook de bedoeling?

ORDER NR 001

Skateboard - 1 stuks
Fietswiel - 3 stuks
Skateboard - 4 stuks


Dat is beetje vaag lijkt me. elke orderregel mag maar 1 artikel bevatten, alleen de aantallen mogen vrij gekozen worden.
Dus in 1 orderregel kan je wel 5 fietswielen bestellen, maar niet een fietswiel en een skateboard

dacht ik

[Dido]

Verwijderd schreef op dinsdag 06 september 2005 @ 16:20:
Maar orderregel naar artikel is dan nog wel steeds een 1:n relatie toch?

Nee, dat lijkt me juist een n:1 relatie

Als ik een artikel heb, zeg "voetbal", dan kunnen er meerdere orderregels zijn waar die opstaat. Er is dus een 1:n relatie van artikel naar orderregel, niet andersom.

1:1 lijkt me niet, tenzij je (en dat komt voor) unieke exemplaren verkoopt. In dat geval heb je een heel andere database.

[bigbeng]

Weet je wel wat 1 op 1 betekent?

Stel:

order 1
orderregel 1

order 2
orderregel 1

Als de relatie orderregel - artikel 1 op 1 is, dan kan een artikel maar op 1 orderregel voorkomen. Dus of in order 1 orderregel 1, of in order 2, orderregel 1, maar nooit in beide. Als dat wel kan, dan is de relatie 1 op n

Oftewel een orderregel kan 1 artikel bevatten, maar 1 artikel kan wel op n verschillende orderregels (gewoonlijk verdeeld over meerdere orders) voorkomen.

[Verwijderd]

Dido schreef op dinsdag 06 september 2005 @ 16:35:
[...]

Nee, dat lijkt me juist een n:1 relatie

Als ik een artikel heb, zeg "voetbal", dan kunnen er meerdere orderregels zijn waar die opstaat. Er is dus een 1:n relatie van artikel naar orderregel, niet andersom.

In verhaalvorm krijg je dan: Een artikel heeft null of meerdere orderregels.
Dat klinkt stom, of denk ik nu te praktisch, en moet ik het wat meer op modelbasis bekijken?

[Dido]

bigbeng schreef op dinsdag 06 september 2005 @ 16:37:
Weet je wel wat 1 op 1 betekent?

offtopic:
Dat vroeg je aan mij?

Verwijderd schreef op dinsdag 06 september 2005 @ 16:38:
In verhaalvorm krijg je dan: Een artikel heeft null of meerdere orderregels.
Dat klinkt stom, of denk ik nu te praktisch, en moet ik het wat meer op modelbasis bekijken?

Waarom klinkt dat stom? Het is toch zo?
"Een artikel komt op null of meerdere orderregels voor", vrij vertaald: "Een artikel kan verkocht worden". Dat laatste klinkt niet stom: dat is het doel van een winkel.

Artikel (1) - Regel (n) is je enige logische mogelijkheid, omdat:
Artikel (1) - Regel (1) betekent dat een artikel maar 1 keer verkocht wordt,
Artikel (n) - Regel (n) betekent dat op 1 regel meerdere artikelen staan, en
Artikel (n) - Regel (1) betekent dat op 1 regel een aantal artikelen staan (die maar 1 keer verkocht worden.

[ Voor 71% gewijzigd door Dido op 06-09-2005 16:43 ]

[curry684]

Verwijderd schreef op dinsdag 06 september 2005 @ 16:38:
[...]

In verhaalvorm krijg je dan: Een artikel heeft null of meerdere orderregels.
Dat klinkt stom, of denk ik nu te praktisch, en moet ik het wat meer op modelbasis bekijken?

Lees nou [rml]curry684 in "[ Normaliseren] Artikelen aan order vast ..."[/rml] eens

[bigbeng]

Dido schreef op dinsdag 06 september 2005 @ 16:38:
[...]

offtopic:
Dat vroeg je aan mij?

offtopic:
nee, jij was gewoon te snel

[mrBussy]

Deel 1:
Als je de database puur voor opslag gaat gebruiken ( en dus geen order genereerd a.d.h.v. de database ) dan zou ik Order en OrderRegel aanmaken. Bij OrderRegel neem je dan meteen ook alle informatie op die je over het artikel wil weten.

Het is immers niet nodig om een apparte tabel te maken aangezien (theoretisch gezien) ieder artikel van omschrijving en prijs kan wijzigen en je dus meer overhead zou creeren (nieuwe database definitie).

Deel 2
Wil je het niet als informatie op wil slaan, maar er ook bewerkingen op wil maken (zoals het aanmaken van de order in een app waardoor je informatie nodig hebt op het moment) zou ik Order, OrderRegel en Artikel aanmaken. Op het moment dat een Order definitief is: Zie deel 1. Tot die tijd gebruik dan de Artikel tabel

[bigbeng]

Ik begin te vermoeden dat de gebruiker naast de unieke sleutel orderregelnr (of welke pk je wil op je orderregel) dat er ook een uniqueness constraint op de combi ordernr en artikelnr moet komen. Klopt dat?
Want dat kan natuurlijk, als je dat wilt.

[curry684]

Zuiver gezien heb je een m:n relatie tussen Order en Artikel. Hiervoor maak je terecht een koppeltabel, die je al de naam OrderRegel hebt gegeven. Bij deze relatie kun je andere attributen van de relatie aangeven, zoals het "aantal" of de "afgesproken prijs". Die zitten correct in die tabel omdat ze een directe eigenschap van de relatie zijn en niet van een van de verbonden entiteiten. Daarmee wordt OrderRegel dus als volgt:

code:

OrderRegeld (PK)
OrderId (FK)
ArtikelId (FK)
Prijs
Aantal

En heb je alles bereikt wat je wilde

[Verwijderd]

De relatie Orderregels : Artikelen is een n:1 relatie. Denk maar eens logisch na, een orderregel kan maar 1 artikel bevatten, maar een artikel kan op meerdere orderregels staan.

[Verwijderd]

bigbeng schreef op dinsdag 06 september 2005 @ 16:42:
Ik begin te vermoeden dat de gebruiker naast de unieke sleutel orderregelnr (of welke pk je wil op je orderregel) dat er ook een uniqueness constraint op de combi ordernr en artikelnr moet komen. Klopt dat?
Want dat kan natuurlijk, als je dat wilt.

Meestal doe je dat niet in een orderadministratie. Het is namelijk zeer wel mogelijk dat je twee orderregels met hetzelfde artikel hebt. Bijvoorbeeld wanneer de prijs anders is ( je verkoopt 10 stuks a € 10, en nog eens 5, met korting, a € 9,50 ).

[WormLord]

leuk_he schreef op dinsdag 06 september 2005 @ 16:30:
Een artikel kan in de praktijd best vaker voorkomen op eenorder.

-Deelleveringen. Lever de 1e keer 100 stuks uit en de 2e keer 200, echter wel in 1 order want de kortingregelingen gaan factuur gaan op order nivo.
-Verschillnede voorwaarden. quantum kortingen (10 artikelen gratis meeleveren ofzo)

Order
|
orderregel
|
artikel

Voor dit geval ga je dan zendingen / leveringen gebruiken.
Per zending / levering kan je dan voor 1 of meer orders 1 of meer artikelen leveren.

[djluc]

curry684 schreef op dinsdag 06 september 2005 @ 16:44:
[...]En heb je alles bereikt wat je wilde

Op deze manier kan je nooit meer de originele order reproduceren. Een productomschrijving kan bijvoorbeeld veranderen. Je zou deze data dus ook moeten overnemen in je orderregels tabel.

Een geheel andere aanpak is van je artikelen tabel een historische tabel maken. Je voert dus nooit wijzigingen op een product uit maar plaatst steeds een nieuw record bij wijzigingen. Hierdoor kan je op basis van de aanmaakdatum van de order precies de juiste records er bij halen.

[Rac-On]

* Rac-On een dergelijk systeem onderhoudt (en beetje mee gebouwd heeft) en wij hanteren het volgende:

een order is gekoppeld aan meerdere order regels
een order bevat algemene dingen zoals totaal, verzendkosten, datum, status en dat soort meuk
iedere orderregel kent een produkt en een aantal
een produkt verdwijnt nooit uit de database. De prijs van een produkt wijzigd nooit

opzich hebben we hierbij een shortcut genomen. Omdat we ooit begonnen zijn als pre-paid internetprovider, is er een duidelijke relatie tussen de omschrijving van een produkt en wat het kost (guess what, "5 euro beltegoed" kost 5 euro ). Voor speciale acties, bijv 10% korting, werd/wordt een extra produkt aangemaakt ('5 euro beltegoed voor 4,90" kost 4,90).
Dit is uiteraard niet vol te houden als je produkten verkoopt waar de prijs erg van varieert. In dat geval zou je er voor kunnen kiezen om de prijs op te slaan in de tabel orderregels, maar mooier is naar mijn mening aan artikel een extra tabel te koppelen, namelijk prijs. Die tabel zou worden (ong):
prijsid = artikelid = ingangsdatum = einddatum = stukrpijs

op die manier behoudt je namelijk een stukje informatie, namelijk wat je artikel vroeger gekost heeft. Voor optimalisatie zou je nog een kolom "geldtnu" kunnen toevoegen

[djluc]

Dat is vergelijkbaar met mijn bovenstaande post inderdaad rac-on. Je haalt inderdaad ook aan dat je hierdoor extra informatie behoud, zo kan je net zoals in bijvoorbeeld de Pricewatch een grafiekje maken met prijsdalingen en stijgingen. Dit kan eventueel een extra selling-point van je product zijn.

[Verwijderd]

Mischien een stomme opmerking hoor, maar is het niet eens handig om te definieren wat iedereen met de entiteiten bedoeld...

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 17:07:
Mischien een stomme opmerking hoor, maar is het niet eens handig om te definieren wat iedereen met de entiteiten bedoeld...

Spreekt dat niet voor zich dan?

[Rac-On]

Verwijderd schreef op dinsdag 06 september 2005 @ 17:07:
Mischien een stomme opmerking hoor, maar is het niet eens handig om te definieren wat iedereen met de entiteiten bedoeld...

lijkt me voor zichzelf spreken toch?
order: vergelijkbaar met een faktuur
orderregel: vergelijkbaar met een regel op een faktuur
produkt/artikel: een "iets" wat verkocht kan worden, een omschrijving en een prijs heeft

@djluc: jup, vergelijkbaar met wat jij zegt inderdaad. De filosofie die we hier hanteren is dat wijzigingen in de database nooit mogen leiden tot onlogische dingen. En een regel met:
2 headsets (EUR 5,40) totaal: 11,95
is dus niet acceptabel, wat dus de noodzaak met zich mee brengt historische prijs informatie te bewaren.

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 17:19:
Spreekt dat niet voor zich dan?

Iedereen heeft zoveel te zeggen over hoe ze het hebben aangepakt dat me eerder het probleem lijkt te liggen bij de defenitie van de entiteiten dan bij de eigelijke implementatie.

Maar goed, misschien heb ik te weinig gelezen.

[djluc]

Het is meer een kwestie van hoe ver wil je gaan? De meest simpele oplossing is:

Tabel artikelen
omschrijving-prijs

Tabel orders
id-klantinfo-datum

Tabel orderregels
orderid-productomschrijving-aantal-prijs

Dus zonder relatie tussen het artikel en de order/orderregels. Als je meer informatie er uit wilt halen kan je vervolgens verder gaan normaliseren. Je kan dit doen zolang je maar alle informatie uit de bovenstaande opzet er uit kan halen, zelfs al wijzigen er records die gerelateerd zijn.

[Verwijderd]

Dit is wat ik nu heb, reacties altijd welkom natuurlijk



_{Even snel gemaakt, dus niet op de verkeerde lijnsymbolen letten}

[Rac-On]

is inderdaad een goede oplossing. Nu nog even bedenken wat je wilt doen met veranderingen aan een artikel!

[Verwijderd]

rac-on schreef op dinsdag 06 september 2005 @ 17:56:
is inderdaad een goede oplossing. Nu nog even bedenken wat je wilt doen met veranderingen aan een artikel!

Geen artikel verwijderen, maar werken met actief/inactief zoals iemand al aangaf.
En geen wijzigingen doen, maar artikelen opnieuw toevoegen met de nieuwe gegevens.

Het voordeel in dit geval voor mij is, dat ik alleen het model moet opzetten, het gaat
nooit gebruikt worden. Dus opzich hoef ik me daar niet zo heel veel zorgen over te maken.
Mocht iemand me vragen hoe ik dat had gezien in dit model, dan geef ik gewoon bovenstaand antwoord.

[Verwijderd]

Dido schreef op dinsdag 06 september 2005 @ 16:38:
[...]

Artikel (1) - Regel (n) is je enige logische mogelijkheid, omdat:
Artikel (1) - Regel (1) betekent dat een artikel maar 1 keer verkocht wordt,
Artikel (n) - Regel (n) betekent dat op 1 regel meerdere artikelen staan, en
Artikel (n) - Regel (1) betekent dat op 1 regel een aantal artikelen staan (die maar 1 keer verkocht worden.

Scherp

[Verwijderd]

1 dingetje dan nog, beetje zinloos om hier een heel topic voor te openen.

Ik heb een klantentabel met daarin de velden "username" en "password"
Mijn docent zegt, dat moet je in een nieuwe tabel doen.
Ik vond van niet, want dan krijg je een 1:1 tabel die echt totaal geen voordelen bied.

Wat vinden jullie, splitsen of zo laten?

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 18:53:
1 dingetje dan nog, beetje zinloos om hier een heel topic voor te openen.

Ik heb een klantentabel met daarin de velden "username" en "password"
Mijn docent zegt, dat moet je in een nieuwe tabel doen.
Ik vond van niet, want dan krijg je een 1:1 tabel die echt totaal geen voordelen bied.

Wat vinden jullie, splitsen of zo laten?

Splitsen.
Iemand die in kan loggen hoeft niet perse ook aan klant te zijn ( jijzelf logt toch ook in het pakket in, en je bent geen klant), en het is mogelijk dat een klant meerdere logins heeft ( 1 voor de directeur, 1 voor de inkoper etc. etc. )
Ik zou dus een aparte tabel "gebruikers" maken, met een veld waarin eventueel een koppeling met een klantnummer kan worden gemaakt ( optioneel dus )

[Gomez12]

Nog een vraagje erbij : Hoe los je het beste "samengestelde" artikelen op???

Vb. als artikelen heb ik
moederbord
hdd
keyboard
monitor
muis
1 uur arbeidsloon.
kast

Dit kan allemaal los verkocht worden en de voorraad is ook per artikel. Nu wil ik ook een computer aanbieden die opgebouwd is uit de voorgaande onderdelen en waarvan de prijs de prijs van de artikelen - 10 % is ( dus bij elke artikelprijswijziging zou de computer van prijs moeten veranderen ). Ik wil dus niet dat de klant zelf alle artikelen bij elkaar zoekt. Ik wil maar 1 regel hebben op de order naar de klant toe.

Gebeurt dit dan op orderregel niveau of op artikelniveau???

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 17:53:
Dit is wat ik nu heb, reacties altijd welkom natuurlijk

[afbeelding]

_{Even snel gemaakt, dus niet op de verkeerde lijnsymbolen letten}

De relatie tussen Artikel en Orderregel ligt nog steeds verkeerd. 1 artikel kan op meerdere regels staan, maar 1 regel heeft altijd maar 1 artikel

[Verwijderd]

Gomez12 schreef op dinsdag 06 september 2005 @ 19:01:
Nog een vraagje erbij : Hoe los je het beste "samengestelde" artikelen op???

Vb. als artikelen heb ik
moederbord
hdd
keyboard
monitor
muis
1 uur arbeidsloon.
kast

Dit kan allemaal los verkocht worden en de voorraad is ook per artikel. Nu wil ik ook een computer aanbieden die opgebouwd is uit de voorgaande onderdelen en waarvan de prijs de prijs van de artikelen - 10 % is ( dus bij elke artikelprijswijziging zou de computer van prijs moeten veranderen ). Ik wil dus niet dat de klant zelf alle artikelen bij elkaar zoekt. Ik wil maar 1 regel hebben op de order naar de klant toe.

Gebeurt dit dan op orderregel niveau of op artikelniveau???

Ik zou d'r een soort pakket van maken zoals iemand eerder als voorbeeld gaf.
1 muis - 14,00
2 muizen - 20,00

Dus ik zou een pakket maken met bijvoorbeeld de naam "Gomez Desktop 1400DL"
en dan bij de beschrijving aangeven wat het allemaal bevat en dan zelf een prijs kiezen
Als je een eventuele GUI zou hebben bijvoorbeeld als webshop, is dat ook veel makkelijker
weer te geven.

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 19:02:
[...]

De relatie tussen Artikel en Orderregel ligt nog steeds verkeerd. 1 artikel kan op meerdere regels staan, maar 1 regel heeft altijd maar 1 artikel

Artikel heeft een 1 op meer relatie NAAR orderregel

Dus een artikel kan null of meer keer orderregels hebben.
Maar een orderregel bevat altijd maar 1 artikel.

_{Afbeelding is wat onduidelijk, geef ik toe}

[Verwijderd]

Gomez12 schreef op dinsdag 06 september 2005 @ 19:01:
Nog een vraagje erbij : Hoe los je het beste "samengestelde" artikelen op???

Vb. als artikelen heb ik
moederbord
hdd
keyboard
monitor
muis
1 uur arbeidsloon.
kast

Dit kan allemaal los verkocht worden en de voorraad is ook per artikel. Nu wil ik ook een computer aanbieden die opgebouwd is uit de voorgaande onderdelen en waarvan de prijs de prijs van de artikelen - 10 % is ( dus bij elke artikelprijswijziging zou de computer van prijs moeten veranderen ). Ik wil dus niet dat de klant zelf alle artikelen bij elkaar zoekt. Ik wil maar 1 regel hebben op de order naar de klant toe.

Gebeurt dit dan op orderregel niveau of op artikelniveau???

Het beste kun je dan met een koppeltabel werken die aan artikel koppelt aan 1 of meerdere andere artikelen. een 1 : n relatie van de artikelentabel met zichzelf dus. Die tabel zou ik als volgt opbouwen (velde type zijn totaal fictief ) :

code:

Create table 
  ArtikelSamenstelling 
AS (
      Hoofdartikel varchar(20), 
      Samenstellend_artikel as varchar(20)
    )

Bij een wijziging van 1 van de regels moet je dan de prijs van het hoofdartikel opnieuw berekenen. LET OP !!!! een hoofdartikel kan zelf weer een samenstellend artikel van iets anders zijn, dus je moet die prijsherberekening recursief aanpakken.

Uiteindelijk is het het hoofdartikel dat je verkoopt, en waar de voorraad van wordt bijgehouden.

[ Voor 4% gewijzigd door Verwijderd op 06-09-2005 19:09 ]

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 19:05:
[...]


Artikel heeft een 1 op meer relatie NAAR orderregel

Dus een artikel kan null of meer keer orderregels hebben.
Maar een orderregel bevat altijd maar 1 artikel.

_{Afbeelding is wat onduidelijk, geef ik toe}

maar zit dan het bolletje op de lijn tussen orderregel en artikel niet aan de verkeerde kant ?

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 19:10:
[...]

maar zit dan het bolletje op de lijn tussen orderregel en artikel niet aan de verkeerde kant ?

Ja die zit aan de verkeerde kant

[Gomez12]

Verwijderd schreef op dinsdag 06 september 2005 @ 19:03:
[...]


Ik zou d'r een soort pakket van maken zoals iemand eerder als voorbeeld gaf.
1 muis - 14,00
2 muizen - 20,00

Dus ik zou een pakket maken met bijvoorbeeld de naam "Gomez Desktop 1400DL"
en dan bij de beschrijving aangeven wat het allemaal bevat en dan zelf een prijs kiezen
Als je een eventuele GUI zou hebben bijvoorbeeld als webshop, is dat ook veel makkelijker
weer te geven.

Is 1 mogelijkheid die volgens mij vrij bewerkelijk is. Als je muis dan van prijs veranderd dan mag je het artikel 1 muis en 2 muizen en Gomez Desktop 1400DL allemaal los van prijs veranderen.
Voor veelvouden van artikelen zou ikzelf een staffel maken zodat iemand bij 2 muizen 25% korting krijgt, bij 3 muizen 40 % etc. Dan hoef je alleen maar de prijs van de ene muis aan te passen, rest veranderd mee. ( hierbij heb je dus ook maar 1 artikel muis verkoopprijs wordt dan bepaald door aantal x korting ( waarbij korting een lookup naar de staffeltabel is voor de staffel voor deze klant en dit type product ).

Alleen samengestelde artikelen krijg ik dit relatie schema niet gepropt vanwege het feit dat ik 2 kanten op kan gaan :
1 : Ik kan de hele prijsroutine en voorraad routine en artikelroutine aanpassen zodat op het moment dat er een artikelprijs/artikelvoorraad wordt gezocht er eerst gekeken wordt of het geen samengesteld artikel is. Nadeel hiervan is dat het vrij ingrijpend is.
2 : Ik kan gewoon een suborderregel tabel toevoegen die wel voor de prijs en voorraad geldt, maar niet afgedrukt wordt voor de klant. Nadeel is dat ik een extra niveau in mijn orders inbouw die in een heleboel gevallen identiek aan orderregels zal uitvallen.

Na enige overdenkingen vermoed ik toch dat mijn hersenspinsel de verkeerde kant op gaat. Want als ik situatie 2 pak dan heb ik alleen de orderregels goed afgeregeld en mag ik de rest van de list-artikelen etc nog aanpassen. Terwijl ik met situatie 1 nog steeds gewoon de situatie heb dat een samengesteld artikel voor alles ( behalve artikel-specifieke procedures ) gewoon een artikel is wat een prijs heeft en wat een voorraad heeft etc.

Edit : wat ffrenzy dus zegt, want dan heb en hou ik gewoon 1 object artikel ipv artikel en samengesteld artikel.

[ Voor 4% gewijzigd door Gomez12 op 06-09-2005 19:51 ]

[Verwijderd]

Verwijderd schreef op dinsdag 06 september 2005 @ 19:43:
[...]


Ja die zit aan de verkeerde kant

gelukkig, ben ik toch niet helemaal gek

[Rac-On]

wat betreft korting kan je er ook voor kiezen de korting over de hele faktuur te berekenen. Je tabel orders krijgt dan een extra kolom korting. Ook kan je produkten aanmaken, bijv "100 euro korting" met een prijs van EUR -100,-.

[Verwijderd]

rac-on schreef op dinsdag 06 september 2005 @ 20:29:
wat betreft korting kan je er ook voor kiezen de korting over de hele faktuur te berekenen. Je tabel orders krijgt dan een extra kolom korting. Ook kan je produkten aanmaken, bijv "100 euro korting" met een prijs van EUR -100,-.

kortingen geef je meestal in de regel van het artikel waarop de korting zit op. met een veld "Kortingspercentage" en/of "kortingsbedrag"

Korting op de gehele factuur geef je in de order zefl op, idd.

offtopic:
FFrenzy voelt zich als MCP in Navision development wel thuis in dit topic

[ Voor 9% gewijzigd door Verwijderd op 06-09-2005 21:20 ]

[Killemov]

Databases voor gevorderden: samengestelde artikelen kun je eventueel ook doen met een recursieve relatie of ... sets.