Elfproef SQL function
Door Bo az, 20 jaar geleden, 17.180x bekeken
Ik moest vandaag voor school de elfproef maken voor SQL server en ik dacht ik vorm 'm even om voor MySQL misschien dat iemand er iets aan heeft.
Er komen wel een aantal opmerkingen bij:
Als je niet weet wat de elfproef is: http://nl.wikipedia.org/wiki/Elfproef
Er wordt alleen naar de elfproef gekeken, niet of de lengte wel juist is, 19 wordt dus ook als geschikt gezien. Deze toevoeging mag je eventueel zelf doen.
Er kwam meteen een leuke extra (*kuch*) van MySQL boven drijven, ook al define je het datatype INT krijg je als nog een komma getal en dus moest ik de FLOOR functie gebruiken.
Het gebruik van deze functie is het gemakkelijkste in een CHECK constraint, maar helaas wordt deze niet door MySQL ondersteun en zal je dus een andere oplossing moeten verzinnen.
Voorbeelden
Bij de uitkomst 1 (TRUE) is de elfproef geslaagd.
Een voorbeeld van het gebruik in MySQL:
Code (php)
1
SELECT fnElfProef(587423548)
Een voorbeeld van het gebruik icm een CHECK constraint in SQL Server:
Code (php)
1
2
3
4
2
3
4
CREATE TABLE bank (
accountnr INT NOT NULL,
CONSTRAINT elfproef CHECK(dbo.fnElfProef(accountnr) = 1)
)
accountnr INT NOT NULL,
CONSTRAINT elfproef CHECK(dbo.fnElfProef(accountnr) = 1)
)
Een voorbeeld van het gebruik icm een CHECK constraint in Postgre:
Code (php)
1
2
3
4
2
3
4
CREATE TABLE bank (
accountnr INT NOT NULL,
CONSTRAINT elfproef CHECK(fnElfProef(accountnr))
)
accountnr INT NOT NULL,
CONSTRAINT elfproef CHECK(fnElfProef(accountnr))
)
Gesponsorde koppelingen
PHP script bestanden
Er zijn 15 reacties op 'Elfproef sql function'
0 
-0 
-0
Tip: Maak vast ruimte voor IBAN-nummers, dat ga je vroeg of laat echt nodig hebben.
Edit: Nee, mijn kennis is nog steeds up-to-date, MySQL blijft ellendig.
0 -0
-0
pgFrank:
Ik heb even die CHECK-constraint aangemaakt, een ongeldige waarde is ondanks de warning gewoon in te voeren... STRICT zal dit probleem oplossen, maar het is wel weer risico-vol gedrag.
Ik neem aan dat je het op MySQL getest hebt? Krijg je een warning? Zover ik weet en getest heb ondersteund MySQL helemaal geen CHECK-constraint (mijn versie: 5.0.37-community-nt in ieder geval niet.
Edit:
robin:
Laad me raden HBO? :P
Zeker
0 -0
-0
Als Frank over een database systeem praat dan is het pgSQL.
Ik heb nog nooit een functie gemaakt met MySQL, maar moet je deze dan gewoon als query uitvoeren of is dit meer een soort tabel?
edit:
Ik had alleen Oracle op het HBO...
Ik heb nog nooit een functie gemaakt met MySQL, maar moet je deze dan gewoon als query uitvoeren of is dit meer een soort tabel?
edit:
Ik had alleen Oracle op het HBO...
0 -0
-0
Martijn!:
Ik heb nog nooit een functie gemaakt met MySQL, maar moet je deze dan gewoon als query uitvoeren of is dit meer een soort tabel?
Een functie is eigenlijk prima te vergelijken met een functie in PHP. Je kan er parameters aan mee geven en het heeft een return waarde. Verschil is dat een return altijd van één bepaald type is (dus òf INTEGER òf STRING ... ). leuk detail is dat je als return type ook een TABLE kan geven (iig in SQL Server).
0 -0
-0
Quote:
Als Frank over een database systeem praat dan is het pgSQL.
Nee helaas, die heb ik net ook nog maar toegevoegd en dan werkt ie wel gewoon als CHECK-contraint.
0 -0
-0
Edit: Ik zou persoonlijk geen integer retour geven, maar een boolean: TRUE als het is gelukt en FALSE wanneer het is mislukt.
Edit 2: Geef mij een plank en ik maak wel een misser.... CHECK is héél wat anders in MySQL, dat gaat over errors in de tabel.
0 -0
-0
pgFrank:
Edit: Ik zou persoonlijk geen integer retour geven, maar een boolean: TRUE als het is gelukt en FALSE wanneer het is mislukt.
Dat het logischer is ben ik met je eens, maar SQL Server kent geen datatype boolean en dat zal dus lastig gaan. Omdat het origineel daarvoor gemaakt is heb ik dat ook voor de anderen niet gedaan (lui dus).
0 -0
-0
In SQL Server heb je toch het datatype BIT ? Dat is 0, 1 of NULL en dus vergelijkbaar met een boolean.
0 -0
-0
Daar heb je gelijk in, dat was wellicht een betere/logischer keuze geweest.
Misschien pas ik het nog een keer aan, zou ook netter staan in de CHECK, dan kan de vergelijking er uit.
Misschien pas ik het nog een keer aan, zou ook netter staan in de CHECK, dan kan de vergelijking er uit.
0 -0
-0
Precies! Dat was ook de reden waarom ik over een boolean begon, dat is logischer wanneer je een CHECK-constraint gebruikt.
In PostgreSQL en SQL Server kun je ook een domain aanmaken (CREATE DOMAIN en CREATE TYPE). Dat is wellicht nog net iets handiger dan een check-constraint, het gaat hier toch om een soort van datatype en niet om een businessrule.
Mogelijkheden genoeg!
In PostgreSQL en SQL Server kun je ook een domain aanmaken (CREATE DOMAIN en CREATE TYPE). Dat is wellicht nog net iets handiger dan een check-constraint, het gaat hier toch om een soort van datatype en niet om een businessrule.
Mogelijkheden genoeg!
0 -0
-0
Aangepast, maar die BIT blijft een raar geval in SQL Server (zie de CHECK).
Of heeft iemand nog een beter idee?
En ze mij op school maar wijsmaken dat een van de punten waarop SQL Server van de standaard afwijkt is dat je geen DOMAINS kan maken!
Mooi dat ik nu weet dat het kan, maar toch vind ik dat hier niet zo van belang zeker niet als 3e dit gaan gebruiken, laat eerst maar eens zien wat een function is.
Of heeft iemand nog een beter idee?
Quote:
In PostgreSQL en SQL Server kun je ook een domain aanmaken (CREATE DOMAIN en CREATE TYPE). Dat is wellicht nog net iets handiger dan een check-constraint, het gaat hier toch om een soort van datatype en niet om een businessrule.
En ze mij op school maar wijsmaken dat een van de punten waarop SQL Server van de standaard afwijkt is dat je geen DOMAINS kan maken!
Mooi dat ik nu weet dat het kan, maar toch vind ik dat hier niet zo van belang zeker niet als 3e dit gaan gebruiken, laat eerst maar eens zien wat een function is.
0 -0
-0
What's in a name: user defined type, dat lijkt toch sterk op een DOMAIN zoals bv. PostgreSQL die kent. In dit nieuwe type roep je vervolgens jouw functie aan en klaar is kees.
In de database heb je nu de beschikking over een nieuw datatype en kun je nooit meer vergeten om de CHECK-constraint aan te roepen.
In de database heb je nu de beschikking over een nieuw datatype en kun je nooit meer vergeten om de CHECK-constraint aan te roepen.
0 -0
-0
Elfproef is niet alleen toe te passen voor het checken van bankrekeningnummers, maar als je het laatste getal vermenigvuldigd met -1 ipv +1 kun je BSN's checken. even ter info.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu