[SQL] Gedeeltelijke overeenkomst tabellen

[Dutchmania]

Beste Tweakers,

Ik ben bezig met een database voor m'n stagebedrijf welke alle producten bevat met daarbij horende informatie.
De informatie over deze producten (aanwezige software, componentenlijsten) staan verspreidt over meerdere tabellen en worden door ID nummers aan elkaar gelinkt.

Elk product heeft een productnummer welke bestaat uit 8 cijfers, elk product hoort vervolgens bij een apart project waarbij elk project een eigen productnummer heeft bestaande uit 7 getallen. De 7 cijfers van het productnummer van het project komen overeen met de eerste 7 cijfers van het productnummer van het product.

De bedoeling is om het ID nummer van een project in de producttabel te zetten waarbij de eerste 7 cijfers overeenkomen, het achtste cijfer kan genegeerd worden.

Ik heb het al geprobeerd met een query waarbij het laatste getal een wildcard is:
WHERE Product.Productnummer = Project.Productnummer%
Deze optie werkt als je zelf een nummer in voert alleen is het nu een naam van een kolom waardoor de wildcard niet werkt, of ik doe het verkeerd natuurlijk

Natuurlijk heb ik op Google gezocht naar wildcards en het gebruik hier van maar deze geeft alleen voorbeelden weer als de waarde al bekend ik maar niet als ik een kolom gebruik.

Wie kan mij een zetje in de goede richting geven zodat ik dit probleem kan oplossen.

[CodeCaster]

Elk product heeft een productnummer welke bestaat uit 8 cijfers, elk product hoort vervolgens bij een apart project waarbij elk project een eigen productnummer heeft bestaande uit 7 getallen. De 7 cijfers van het productnummer van het project komen overeen met de eerste 7 cijfers van het productnummer van het product.

Dus elk product kan maar bij één project horen, en per project kun je maar tien producten hebben?

Waarom niet gewoon een koppeltabel?

[Janoz]

Ik zal maar neit beginnen over de brakheid van een dergelijk datamodel, aangezien dat hier een gegeven is.

De oplossing is op zich redelijk simpel, maar afhankelijk van het type van het product nummer. Wanneer het een string is (varchar) zul je op zoek moeten naar de string functies van je database. (denk aan een substring of left oid). Is het een number, dan zul je bij de bereken functies moeten kijken (denk aan delen door 10).

[Dutchmania]

@CodeCaster:
Inderdaad, dit is simpel gezegd de opzet. Een koppeltabel is een idee maar ik heb de oplossing al (zie hieronder)

@Janoz:
Brakheid van datamodel , graag een beetje uitleg, ik ben pas sinds kort begonnen met het maken van databases en ben dus wel benieuwd...

De productnummers zijn getallen en heb eens gezocht naar het LEFT commando en heb het werkend door het volgende stukje: WHERE LEFT(Product.Productnummer, 7) = Project.Productnummer
Dat het zo makkelijk kan zijn he

Bedankt voor de info, ik ben (voorlopig) geholpen

[RobIII]

Dutchmanic schreef op maandag 05 juli 2010 @ 13:53:
@Janoz:
Brakheid van datamodel , graag een beetje uitleg, ik ben pas sinds kort begonnen met het maken van databases en ben dus wel benieuwd...

Verdiep je eens in normaliseren. En denk een na wat er straks gaat gebeuren (en geloof me, dat gaat gebeuren) als je meer dan 10 producten aan een project wil koppelen. Ik zie sowieso heel de relatie niet waarom een productnummer bepaald zou worden door een projectnummer, laat staan voor 7/8. Ook het idee dat elk product uniek is voor een project doet bij mij wat alarmbellen rinkelen (hoewel het niet onmogelijk is dat dit echt de situatie is) maar echt duidelijk is er niet iets over te zeggen gezien je veel te weinig informatie geeft over de context en enkel je abstracte idee geeft van hoe jij het graag opgelost had.

Dutchmanic schreef op maandag 05 juli 2010 @ 13:53:
De productnummers zijn getallen en heb eens gezocht naar het LEFT commando en heb het werkend door het volgende stukje: WHERE LEFT(Product.Productnummer, 7) = Project.Productnummer

Left is een stringfunctie welke je nou los laat op een varchar (string). Dat het werkt is omdat er een impliciete cast word gedaan van int naar string. Beter kijk je naar zaken om dit 'wiskundig' op te lossen en dus naar aritmetische functies.

Dutchmanic schreef op maandag 05 juli 2010 @ 13:53:
Dat het zo makkelijk kan zijn he

Neem van ons aan dat je over niet al te lange tijd spijt als haren op je hoofd hebt dat je voor zo'n model hebt gekozen. Mijn advies: doe het niet.

Dutchmanic schreef op maandag 05 juli 2010 @ 13:53:
Bedankt voor de info, ik ben (voorlopig) geholpen

Nee, je lijkt geholpen maar de werkelijkheid is dat je jezelf zojuist nog een schep dieper in de shit hebt geholpen

[ Voor 9% gewijzigd door RobIII op 05-07-2010 14:01 ]

[Janoz]

Dutchmanic schreef op maandag 05 juli 2010 @ 13:53:
@Janoz:
Brakheid van datamodel , graag een beetje uitleg, ik ben pas sinds kort begonnen met het maken van databases en ben dus wel benieuwd...

Dergelijke samengestelde sleutels zie je eigenlijk enkel in 2 situaties:

situatie 1: Oplossingen gemaakt door mensen die geen reet van relationele database systemen snappen en denken dat ze een prachtig systeem bedacht hebben.

situatie 2: Legacy systemen die tijden terug door iemand bedacht zijn die geen reet van relationele database systemen snapt en denkt dat hij/zij een prachtig systeem bedacht hebben.

De productnummers zijn getallen en heb eens gezocht naar het LEFT commando en heb het werkend door het volgende stukje: WHERE LEFT(Product.Productnummer, 7) = Project.Productnummer
Dat het zo makkelijk kan zijn he

Dat er enkel getallen in staan maakt het nog geen nummer. Sterker nog, aangezien je aangeeft dat je het probleem met een left opgelost hebt geeft mij sterk het vermoeden dat het een string is (left is een string functie)

[NMe]

Sowieso is het een bijzonder slecht plan om je ID's een andere functie te geven dan het uniek nummeren van je records. Als je zo'n visueel getal wil hebben dan zou ik daar nooit de primary key van maken maar het gewoon redundant opslaan.

offtopic:
Een getal bestaat uit meerdere cijfers. Je zegt dat je productnummer uit 7 getallen bestaat, maar dat bedoel je niet. Dit soort termen kun je in ons vakgebied beter onder de knie hebben.

[Dutchmania]

Ik gaf in het begin een globale omschrijving om het idee uit te leggen, het eigenlijke datamodel ligt anders, ik zal hieronder een voorbeeld geven van de rest. Ook zal ik eens gaan kijken naar normalisatie.

De productnummers zijn opgeslagen als integers, dus niet als varchar's.

Voor de rest zal ik afwachten en als het dan zover is dan kom ik op m'n knieën terug naar je

vb. datamodel: http://images.mikehollander.nl/Datamodel.PNG

Wat ik zeg: ik begin net een beetje in de wondere wereld van databases :P:D
Ik heb deze opdracht gekregen van stage en ben nu 4 maanden bezig met dit onderwerp, ik begon bij start (geen kennis over databases en scripting)

ps. @NMe: termen komen nog, ben bezig

[ Voor 15% gewijzigd door Dutchmania op 05-07-2010 15:05 ]

[Schmoove]

Volgens mij kun je beter zoiets doen:

product_tbl
product_id key
serienummer
productiedatum
leverdatum
opmerking

project_tbl
project_id key
projectnummer
project
omschrijving

project_products_tbl
project_id key
product_id key
opmerking

Dus een tabel om je producten in op te slaan en een tabel om je projecten in op te slaan.
Vervolgens een koppeltabel waarin je de relatie legt tussen een project en de bijbehorende producten.
Zo kun je als je wil zelfs 1000 producten aan 1 project koppelen.

De nummering van de IDs maakt dan niet meer uit... als je tabellen gaat koppelen op basis van overeenkomende getallen in de IDs is dat vragen om problemen.

[ Voor 12% gewijzigd door Schmoove op 05-07-2010 14:41 ]

[RobIII]

Dutchmanic schreef op maandag 05 juli 2010 @ 14:30:
Ik heb deze opdracht gekregen van stage en ben nu 4 maanden bezig met dit onderwerp

Ik heb eerst je hele reply gelezen voordat ik aan de je plaatje aanklikte. Maar seriously: als je 4 maanden bezig bent geweest met dit datamodel dan moet je een ander vak gaan kiezen. Ik neem echter aan dat je datamodel groter is dan deze 3 tabellen maar dat we die niet te zien krijgen, of dat je die 4 maanden ook gespendeerd hebt aan het verdiepen in de materie die je aan 't oplossen bent/gaat. Ik vroeg je echter om meer informatie omtrent het onderwerp en meer info over de context waarin producten gerelateerd zijn aan projecten en/of projectnummers en hoe dat dan precies zit. Daar helpt je afbeelding helemaal niets aan, we zijn er geen steek wijzer door geworden. Vertel nou eens precies hoe de vork in de steel zit en welk probleem je nu eigenlijk aan 't oplossen bent (of wil gaan oplossen). Wat voor projecten zijn het, welke (soort) producten, hoe komt het dat een productnummer gebaseerd is op een projectnummer etc. Dat is informatie waar we wat mee kunnen.

Janoz schreef op maandag 05 juli 2010 @ 14:14:

Dat er enkel getallen in staan maakt het nog geen nummer. Sterker nog, aangezien je aangeeft dat je het probleem met een left opgelost hebt geeft mij sterk het vermoeden dat het een string is (left is een string functie)

SQL:

select left(1234567,4)

1234

AFAIK doen de meeste RDBMSen (MySQL en MSSQL iig wel) gewoon een impliciete cast. Maar dat een stringfunctie loslaten op een int vies is is duidelijk. Ik vrees alleen dat TS dat (nog) niet beseft.

[ Voor 41% gewijzigd door RobIII op 05-07-2010 14:47 ]

[Schmoove]

In de meeste ERP systemen zijn IDs voor producten, projecten of wat dan ook vaak strings.
Dit omdat er vaak in IDs letters staan om duidelijk te maken waar het over gaat en om een zekere flexibiliteit in je naamgeving te krijgen.

Productnummers bijvoorbeeld bestaan zelden uit puur cijfers

Dus die LEFT die hij gebruikt is niet per definitie fout natuurlijk als het ID als string in de database staat.

[ Voor 90% gewijzigd door Schmoove op 05-07-2010 14:52 ]

[Dutchmania]

Ok, hoe de vork in de steel zit:

Ik doe een opleiding elektrotechniek maar men heeft mij hier onder de noemer "Nieuwe uitdaging" de opdracht gegeven om een database te maken met daarin al hun producten.
Het bedrijf waar ik stage loop is een elektronica bedrijf welke zich specialiseert ik complete systemen, een systeem bestaat uit modules, welke weer bestaan uit PCA's (Geassembleerde printplaten).
De nadruk lag op de PCA's. In elke PCA kunnen 1 of meerdere software bestanden zitten (SW en PLD). Van elk product wordt een status van controles bijgehouden zodat men later weer kan terugkijken wanneer een controle is uitgevoerd en wat daar de uitslag van is/was.
Ook wordt er bijgehouden welke gebruiker de controle heeft uitgevoerd en welke het product heeft toegevoegd.

Het productnummer van het project en product is vastgelegd door het bedrijf en kan ik niets aan doen helaas, elke productnummer (PN.Productnummer is tabel) is vastgelegd voor een reeks van producten en elk product krijgt een eigen serienummer welke bestaat uit een 10-cijferig nummer (Int).

Plaatje: http://images.mikehollander.nl/Datamodel2.PNG

Ik hoop dat dit wat opheldert over de database.