openkvk.nl is een database ontstaan uit een verzameling van gegevens uit verschillende bronnen waaronder kvk.nl, belastingdienst.nl en rechtspraak.nl. Deze bronnen zijn openbaar en gebonden aan wettelijke publicatie. Om de data uit deze bronnen te kunnen integreren in dit systeem en doorzoekbaar te maken draaien we dagelijks onderhoudsqueries, en per kwartaal verversen we de bronnen compleet.
Deze data wordt je, bij normaal gebruik dat de dienstverlening niet laat onderbreken, kosteloos aangeboden. De dienst is dan ook toegangelijk voor iedereen wie de voorgaande regel in acht neemt. Onder normaal gebruik verstaan we in ieder geval niet: het dumpen van de volledige database, op welke manier dan ook. We wijzen uitdrukkelijk nogmaals op de Databankenwet Artikel 4. Van deze dienst worden alle queries opgeslagen voor onderzoeksdoeleinden. Hiermee wordt tevens een overzicht per gebruiker van de dienst gegenereerd. Bij buitensporig gebruik krijgt de gebruiker een verwijzing. Ook limiteren we, zover wij kunnen limiteren, het hergebruik voor commerciele uitingen als Direct Marketing. Geen ingeschreven bedrijf zit te wachten op een grote hoeveelheid spam. Dumps van de volledige dataset worden en zijn onder strikte voorwaarden afgegeven aan derden, voor innovatieve ideeën, projecten en analyse. Zij blijven aan voorgaande beperkingen verbonden. Het gebruik van de API geschied alleen via api.openkvk.nl.
De inhoud van de database wordt gevormd van uit een relationele database. Een sample is beschikbaar.
CREATE TABLE "sys"."kvk" (
"id" int NOT NULL DEFAULT next value for "sys"."seq_4399",
"kvk" bigint,
"bedrijfsnaam" varchar(255),
"adres" varchar(64),
"postcode" varchar(6),
"plaats" varchar(32),
"type" varchar(16),
"kvks" int,
"sub" int,
"bedrijfsnaam_size" smallint,
"adres_size" smallint,
CONSTRAINT "kvk_id_pkey" PRIMARY KEY ("id")
);
CREATE TABLE "sys"."anbikvk" (
"naam" varchar(256),
"vestigingsplaats" varchar(32),
"beschikking" date,
"intrekking" date,
"kvks" int
);
CREATE TABLE "sys"."anbi" (
"naam" varchar(256),
"vestigingsplaats" varchar(32),
"beschikking" date,
"intrekking" date
);
CREATE TABLE "sys"."faillissementen" (
"kvk" bigint,
"bedrijfsnaam" varchar(255),
"plaats" varchar(32),
"rechtbank" varchar(64),
"rolnummer" varchar(16),
"status" varchar(16),
"datum" date
);
CREATE TABLE "sys"."concernrelaties" (
"kvk" bigint,
"ouder" varchar(30),
"postcode" varchar(6),
"plaats" varchar(32),
"ouderkvk" int
);
CREATE TABLE "sys"."qkoorts" (
"adres" varchar(64),
"postcode" varchar(6),
"plaats" varchar(32),
"provincie" varchar(16),
"besmet" date,
"publicatie" date,
"dier" varchar(6)
);
CREATE TABLE "sys"."hoogsteconcern" (
"kvks" int,
"kind" int
);
CREATE TABLE "sys"."kvk_extra" (
"kvk" bigint,
"bedrijfsnaam" varchar(256),
"straat" varchar(256),
"nummer" int,
"toevoeging" varchar(16),
"postcode" char(6),
"plaats" varchar(32),
"website" varchar(128),
"type" varchar(14),
"status" varchar(64),
"kvks" int,
"sub" int
);
Om je via het web queries te laten uitvoeren gebruiken wij de DBSlayer handler van de Cherokee webserver. Door middel van een reverse proxy kun je op je eigen site zelf AJAX requests doen, deze technologie heeft Cherokee ook aan boord. Flash applicaties kunnen direct verbinden, er is een crossdomain.xml geplaatst.
Een request is een correcte SQL92 query netjes HTTP gecodeerd, en wordt verstuurd als een normale GET request.
Bijvoorbeeld: /api/SELECT * FROM kvk WHERE kvks=20147376,
mocht je dit voorbeeld erg letterlijk willen nemen zet er dan minimaal LIMIT 100 achter,
anders doen wij dat voor jou door middel van een redirect.
Verschillende programmeertalen gebruiken verschillende array formaten, we ondersteunen er een heleboel.
Wil je nu liever een alleen kvknummer terugkrijgen op basis van een volledige string, dan kan dat uiteraard ook.
Ga je een webapp maken in PHP dan kun het beste hier eens een kijkje nemen: http://www.cherokee-project.com/doc/cookbook_dbslayer.html
Sphinx zit al enige tijd ook in MonetDB zelf, maar de optimiser moet nog worden getuned. De query die je in het javascript stukje is momenteel de enige vorm met een multi join die goed gaat. Er wordt aan gewerkt, als je het anders doet gaat het in plaats van in 100ms, 15s duren. Een voorbeeld;
SELECT x.kvk, x.bedrijfsnaam, x.adres, x.postcode, x.plaats, x.type,
NOT(anbikvk.kvks is null AND anbikvk.intrekking is null) AS "anbi", status, x.kvks, x.sub
FROM
(SELECT kvk.kvk, kvk.bedrijfsnaam, kvk.adres, kvk.postcode, kvk.plaats, kvk.type, kvk.kvks, kvk.sub
FROM sphinx_searchIndex('Nieuwe Erven 2', 'openkvk') AS fts, kvk where kvk.kvk = fts.id) AS x
LEFT JOIN anbikvk ON x.kvks = anbikvk.kvks
LEFT JOIN faillissementen ON x.kvks = faillissementen.kvk LIMIT 200 OFFSET 0;
In het bovenstaande voorbeeld zie je dat sphinx_searchIndex wordt gebruikt om een nieuwe tabel te maken, die tabel wordt gealiased als fts, free-text-search. Behalve het id komt er meer uit deze tabel terug, zoals de kans dat het bepaalde documentid overeenkomt met de zoekopdracht. Het documentid, zoals Sphinx dit noemt, is het volledige, 64bit kvk nummer. Dit omdat een Dixons in Oss hetzelfde korte (kvks) nummer heeft als de Dixons in Zaandam. De vorm van de query heeft een reden, een van die redenen is het negatief prioriseren van externe SQL-functies binnen MonetDB. Momenteel kan MonetDB geen kostenanalyse maken van een externe SQL-functie en zal de join (die enorm duur is) dus altijd verkiezen als 'minder dure'. Wil je zelf zoeken, en geen ANBI of Faillissement informatie? Dan zul je er geen last van hebben, immers, je doet geen join over alle data. Zoals je kunt zien kun je dat gebruik maken van de query tussen de (...).
Je kunt openkvk bereiken op twitter.