Tabellen. Primaire sleutels en generators
_NOTICE: Dit document is een hoofdstuk uit het boek “The InterBase World”, geschreven door Alexey Kovyazin en Serg Vostrikov.
InterBase is een relationeel DBMS. Dit betekent bovendien dat alle gegevens in InterBase worden opgeslagen als tabellen. De tabel zoals deze vanuit SQL-oogpunt is gerealiseerd, lijkt sterk op de gewone tabel die je met de hand op een vel papier kunt tekenen of in een programma zoals Microsoft Excel kunt maken. Tabellen in InterBase hebben kolommen en rijen waarin gegevens worden geplaatst. De tabel heeft noodzakelijkerwijs een naam, uniek binnen één database. Tabellen zijn de belangrijkste opslag van informatie in een database en daarom moet je zeer zorgvuldig zijn bij het maken van tabellen.
Er zijn regels die beschrijven hoe je tabellen in de relationele database moet maken, die de gegevens van de echte wereld weerspiegelen en tegelijkertijd een efficiënte opslag van informatie in een database mogelijk maken. Het proces van het toepassen van deze regels voor het ontwerpen van een “correcte” database wordt normalisatie genoemd. We hebben het woord “correct” bewust tussen aanhalingstekens geplaatst, omdat “genormaliseerde database” en “geoptimaliseerde database” geen synoniemen zijn. Je hoeft niet ondubbelzinnig aan de normalisatieregels te voldoen - pas altijd de correctie toe voor de specificatie van een bepaald probleem.
De normalisatie van tabellen in een database wordt in detail behandeld in het boek [14. en daarom zullen we niet proberen het ongrijpbare te omarmen en we keren terug naar ons onderwerp van discussie - naar InterBase-tabellen. Laten we eens kijken naar de syntaxis van een DDL-zin (DDL - Data Definition Language, voor meer details zie de woordenlijst) die het mogelijk maakt om tabellen te maken:
CREATE TABLE table [EXTERNAL [FILE] “”] ( [, | …]);
Hier is table een naam van de gemaakte tabel, - de beschrijving van kolommen (soms zullen we zeggen - velden) van de gemaakte tabel. De optie table [EXTERNAL [FILE] “”] betekent dat de zogenaamde externe tabel zal worden gemaakt, die niet in een gedeeld databasebestand wordt opgeslagen, maar in een apart bestand met een naam . Zoals je kunt zien, is alles eenvoudig - we definiëren een tabelnaam en kolommen die deze bevat. Nu zullen we in detail bekijken hoe we kolommen moeten definiëren. De syntaxis van het maken van een kolom wordt beschreven door de volgende DDL-zin:
= col { datatype | COMPUTED [BY] (< expr>)} | domain}
[DEFAULT { literal | NULL | USER}]
[NOT NULL] [ ]
[COLLATE collation]
Dit is een vrij grote definitie, maar in de definitie van een kolom is slechts een klein deel van de gegeven zinnen verplicht. Elke kolom in de tabel moet een naam hebben, uniek binnen de tabel, evenals een gegevenstype gedefinieerd door de zin datatype, of een expressie voor het berekenen van de waarde van een kolom (voor berekende kolommen), of het domein (zie hieronder), gedefinieerd door domain. Gegevenstypen werden behandeld in het hoofdstuk “Gegevenstypen”; daarom kun je gemakkelijk begrijpen hoe een SQL-expressie voor het maken van een tabel wordt gevormd.
Laten we verbinding maken met onze database FIRSTBASE.gdb die eerder in het hoofdstuk “Een database maken” is aangemaakt, en we zullen proberen in de praktijk met tabellen te werken. Als het gaat om het maken, verwijderen en bijwerken van tabellen, is elk van de InterBase-beheertools - van de tools die worden vermeld in de applicatie “InterBase-beheerder en ontwikkelaarstools”, evenals een standaardhulpprogramma isql.exe uit een set van levering van elke InterBase-kloon - geschikt.
Hier is een voorbeeld van een eenvoudige tabel genaamd TABLE_EXAMPLE die 3 velden van verschillende typen bevat:
CREATE TABLE Table_example ( ID INTEGER, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION);
Deze tabel illustreert het meest voorkomende geval in het proces van databaseontwikkeling. Er zijn echter ook andere methoden om velden te definiëren. We kunnen bijvoorbeeld een veldtype instellen met behulp van domeinen. Het domein is een type dat door een gebruiker is gedefinieerd voor het gemak van het toepassen van bepaalde combinaties van typeparameters. Het is bijvoorbeeld mogelijk om domein D_ID te definiëren voor het specificeren van identificatievelden. Nadat we het domein hebben gedefinieerd, kunnen we het gebruiken om het type van een veld in te stellen:
CREATE DOMAIN D_ID AS INTEGER; CREATE TABLE Тable_example ( ID D_ID, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION);
Veld ID zal het type hebben dat is gedefinieerd door domein D_ID. Dus, nadat we het type van het veld in het domein hebben gedefinieerd, vereiste controles en beperkingen, kunnen we dit domein vele malen toepassen voor het maken van velden met dezelfde functie. Bijvoorbeeld, monetair zonder vermoeiend en met het gevaar een fout te maken bij het kopiëren van definities van variabele typen. De derde manier om een kolom in de tabel in te stellen, is door deze als berekend (COMPUTED BY) te definiëren en een voorwaarde op te geven volgens welke de waarde wordt berekend. We kunnen bijvoorbeeld willen dat onze tabel een kolom heeft die 10% van de waarde van veld PRICE_1 berekent. In dit geval moet de volgende opdracht worden geschreven:
CREATE TABLE Тable_example ( ID INTEGER, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION, PRICE_10 COMPUTED BY (PRICE_1.0.1));
Maar denk niet dat zodra we de gegevens in veld PRICE_1 invoegen, er in veld PRICE_10 een tiende deel van de waarde van dit veld zal verschijnen. Nee, het proces is hier gecompliceerder. In werkelijkheid krijgen we het vereiste tiende deel alleen door te verwijzen naar veld PRICE_10, bijvoorbeeld bij het uitvoeren van een SELECT-query op deze tabel. Dat wil zeggen dat er geen gegevens worden opgeslagen in een berekend veld, en het ophalen van de berekening van de expressie die aan een veld is gekoppeld, wordt uitgevoerd, en het resultaat wordt geproduceerd als antwoord op de query.
Dus we hebben 3 belangrijke manieren bekeken om velden in de tabel op te geven. Laten we nu in detail de opties bekijken die kunnen worden ingesteld bij het maken van een kolom. De optie [DEFAULT {literal | NULL | USER}] - maakt het mogelijk om een kolomwaarde standaard in te stellen. Dit is erg handig voor automatische gegevensinvulling. Er zijn 3 manieren om een standaardwaarde in te stellen. De eerste wordt aangeduid als literal en maakt het mogelijk om standaardwaarden in te stellen als tekstconstanten, getallen of datums. We kunnen bijvoorbeeld de volgende expressies genereren voor het maken van een kolom met tekststandaardwaarden: NAME VARCHAR(80) DEFAULT ‘Vasily Stanislavovich’
Zo zullen alle velden die in de tabel worden ingevoegd standaardwaarden aannemen, d.w.z. als er geen andere waarde is gedefinieerd voor veld NAME, zal de string ‘Vasily Stanislavovich’ verschijnen. De tweede manier om een standaardwaarde in te stellen, is door DEFAULT NULL op te geven in de definitie van een kolom. En in opnieuw gemaakte records zal de waarde van deze kolom NULL zijn, als er natuurlijk geen andere waarde expliciet is ingesteld. Een voorbeeld:
PRICE_1 DOUBLE PRECISION DEFAULT NULL
De derde manier om een standaardwaarde in te stellen, is door DEFAULT USER op te geven in de definitie van een kolom. Zo zal dit veld in opnieuw gemaakte records de naam van de huidige gebruiker bevatten, d.w.z. de gebruiker die de verbinding met InterBase heeft gemaakt en deze invoeging heeft uitgevoerd (voor meer details over gebruikers zie het hoofdstuk “Beveiliging in InterBase: gebruikers, hun functies en rechten” (deel 4)). Voor sommige velden is het essentieel dat het veld een niet-lege waarde heeft. Bijvoorbeeld een veld dat volgens de probleemspecificatie niet leeg kan zijn. Om een beperking op databaseniveau in te stellen dat een veld een gedefinieerde waarde moet hebben, is het noodzakelijk om de volgende toevoeging aan de beschrijving van een kolom te maken:
NAME VARCHAR(80) NOT NULL
Zo zal er een veld zijn waarin null-waarden niet kunnen worden opgeslagen. Gewoonlijk wordt de beperking NOT NULL gecombineerd met de optie DEFAULT die definitief een correcte waarde aan dit veld toewijst. Maar vaak is de beperking NOT NULL niet voldoende. Bijvoorbeeld, in het geval van het opslaan van prijzen in een database is het vrij duidelijk dat ze geen negatieve waarden kunnen aannemen (hoewel het geweldig zou zijn als we extra zouden worden betaald bij het kopen van goederen). Om de server te laten controleren of de waarden van de prijzen die in een database worden ingevoegd positief zijn, is het noodzakelijk om een kolom op de volgende manier te definiëren:
PRICE_1 DOUBLE PRECISION CHECK (PRICE_1>0)
Waarden die in kolom PRICE_1 worden ingevoegd, worden gecontroleerd op positiviteit. Het moet worden opgemerkt dat verschillende consistente opties kunnen worden gecombineerd, en we kunnen bijvoorbeeld een niet-lege waarde instellen en controleren op positiviteit:
PRICE_1 DOUBLE PRECISION NOT NULL CHECK (PRICE_1>0)
Bij het maken van de kolommen kunnen sommige opties niet worden gecombineerd, bijvoorbeeld het is onmogelijk om NULL standaard in te stellen en tegelijkertijd een niet-lege waarde beperking. Het moet worden opgemerkt dat controles een reeks nuttige functies kunnen uitvoeren voor gegevensbeheer in een database. We zullen hun gebruik in detail bekijken in het hoofdstuk “Databasebeperkingen”.
Dus we hebben de manieren bekeken om tabellen en velden met verschillende opties te maken. Er zijn echter gevallen waarin we de tabel die al bestaat moeten wijzigen. Natuurlijk kunnen we de tabel volledig opnieuw maken. Eerst moeten we de opdracht uitvoeren om de tabel te verwijderen en deze vervolgens opnieuw te maken. Bijvoorbeeld:
DROP TABLE Table_example; CREATE TABLE Table_example(ID NUMERIC(15,2);
Maar zo’n manier om tabellen te wijzigen heeft aanzienlijke nadelen. Bij het verwijderen van een tabel met de DROP-opdracht worden alle gegevens die de tabel bevat verwijderd en om ze niet te verliezen, is het noodzakelijk om ze naar tijdelijke tabellen te kopiëren. Dat is nogal omslachtig. Daarom is er de ALTER TABLE-opdracht voor eenvoudige wijziging van de structuur van tabellen, die het mogelijk maakt om nieuwe velden toe te voegen, bestaande te verwijderen, evenals beperkingen van referentiële integriteit toe te voegen / te verwijderen.
We willen bijvoorbeeld nog een kolom aan de tabel toevoegen die bedoeld is voor het opslaan van gegevens over het patroniem van een persoon:
ALTER TABLE Table_example ADD Patronimic VARCHAR(80);
Na uitvoering van deze opdracht zal onze tabel Table_example een nieuwe kolom hebben met de naam Patronimic en het type VARCHAR (80). Als we een kolom met de naam NAME uit de tabel willen verwijderen, moeten we het volgende uitvoeren:
ALTER TABLE Table_example DROP Name;
Je kunt de volledige syntaxis van de ALTER TABLE-instructie zien in [1.. Het is een zeer nuttige opdracht en we zullen deze vaak gebruiken.
En wat moet je doen, zul je vragen, als het nodig is om een kolom te wijzigen? We hebben bijvoorbeeld besloten dat het voor het opslaan van namen beter is om veld HUMAN_NAME te gebruiken dan NAME. In dit geval kunnen we ALTER TABLE toepassen
ALTER TABLE Table_example ALTER COLUMN NAME TO HUMAN_NAME;
Als we hebben besloten om het type van een veld te wijzigen, bijvoorbeeld om het aantal tekens dat in een veld wordt opgeslagen te vergroten, moeten we het domein van dit veld wijzigen met de instructie ALTER DOMAIN (zie het hoofdstuk “Gegevenstypen” hierboven).
Dus we hebben het maken en wijzigen van tabellen in InterBase bekeken. Nu is het tijd om wat dieper in de theorie van databases te duiken. InterBase is zoals al gezegd een relationele database. Dit betekent bovendien dat elk record in de tabel een kenmerk moet hebben op basis waarvan het ene record van het andere kan worden onderscheiden. Het speciale mechanisme van unieke sleutels dient dit doel.
Primaire sleutels in tabellen
Natuurlijk kunnen we een tabel maken die geen sleutels bevat. Dit is ons niet verboden. Maar zoals eerder gezegd, is het maken van een efficiënte database onmogelijk zonder het naleven van de normalisatieregels. De aanwezigheid van sleutels is het belangrijkste element van normalisatie. Daarom, hoewel we niet streven naar het behandelen van de theorie en normalisatie van databases, moeten we een definitie van sleutels introduceren en hun functie in InterBase bekijken. We gaan stap voor stap en we beginnen met het meest voorkomende type sleutel - een primaire sleutel.
Dus, wat is een primaire sleutel? Het is een of meer velden in de tabel die records binnen deze tabel uniek identificeren. Het klinkt moeilijk, maar in werkelijkheid is alles heel eenvoudig. Stel je een gewone tabel voor, bijvoorbeeld het boekhoudblad. Wat is de allereerste kolom? Dat klopt, het volgnummer - 1, 2, 3 … Dit nummer duidt een unieke regel binnen de tabel aan, en het is voldoende om dit nummer te kennen om een string in deze tabel te vinden. In dit voorbeeld zal het een primaire sleutel zijn. De overgrote meerderheid van tabellen in een relationele database heeft noodzakelijkerwijs een primaire sleutel (PK - afkorting van Primary key). De algemene richtlijn bij het maken van tabellen is om een primaire sleutel te maken. Een primaire sleutel kan worden gemaakt bij het maken van een tabel of later. Laten we aannemen dat we op het moment van het maken van een tabel hebben besloten dat veld ID onze primaire sleutel zal zijn. Dan kunnen we een primaire sleutel op de volgende manier toevoegen:
CREATE TABLE Table_example ( ID INTEGER NOT NULL, NAME VARCHAR(80), PRICE_1 DOUBLE PRECISION, CONSTRAINT pkTable PRIMARY KEY (ID));
Wat moet er gebeuren om een primaire sleutel te maken voor de tabel table_example? Laten we zoeken wat er is veranderd in de definitie van de tabel? Ten eerste heeft kolom ID een extra definitie NOT NULL gekregen. Dit is belangrijk, omdat de primaire sleutel uniek moet zijn en geen ongedefinieerde waarden mag bevatten. En NULL is, zoals je weet, een ongedefinieerde waarde. Dus alle velden die in een primaire sleutel zijn opgenomen, moeten de beperking NOT NULL hebben. Om het maken van een primaire sleutel te voltooien, moet het volgende aan het einde van de tabel worden geschreven: CONSTRAINT ()
De volledige syntaxis van beperkingen vind je in het hoofdstuk “Databasebeperkingen” þ. 1, en voor ons voorbeeld van een primaire sleutel ziet het er zo uit:
CONSTRAINT pkTable PRIMARY KEY (ID)
Hier is pkTable de naam van een primaire sleutel, en ID zijn de kolommen die deze bevat. Deze manier van het definiëren van primaire sleutels voor tabellen is handig bij het massaal aanmaken van tabellen (bijvoorbeeld bij het construeren van een databaseprototype op basis van scripts die zijn verkregen via verschillende CASE-bronnen). Maar wat te doen als we een primaire sleutel moeten toevoegen/verwijderen aan een tabel die al bestaat en gevuld is met gegevens? Hiervoor moet nog een uitbreiding van de opdracht - ALTER TABLE - worden toegepast. Een voorbeeld van het toevoegen van een primaire sleutel aan onze tabel:
ALTER TABLE TABLE_EXAMPLE ADD CONSTRAINT FF PRIMARY KEY (ID);
Zo zal de tabel Table_example precies dezelfde primaire sleutel hebben als in het vorige voorbeeld toen deze samen met de tabel werd gemaakt. Om een primaire sleutel te verwijderen, moet de volgende opdracht worden ingevoerd:
ALTER TABLE Table_example DROP CONSTRAINT pkTable;
Zo wordt de sleutel met de naam pkTable uit een database verwijderd.
Generatoren - beste vrienden van primaire sleutels
We moeten iets zeggen over de implementatie van een primaire sleutel. Omdat deze bedoeld is om uniciteit te ondersteunen, kunnen geen twee records in één tabel dezelfde waarden van deze sleutel hebben. Dat wil zeggen, om aan de voorwaarde te voldoen, moet InterBase bij het invoegen van een nieuw record in de tabel alle records in de tabel controleren en uitzoeken of de tabel dergelijke waarden bevat of niet. Voor snel zoeken heeft InterBase een mechanisme van indexen - speciale InterBase-objecten, die het mogelijk maken om snel een record in de tabel te vinden. Daarom wordt bij het maken en verwijderen van de primaire sleutel een index gemaakt of verwijderd voor dat veld (of die velden) dat in de primaire sleutel is opgenomen.
Zoals eerder gezegd, kan de primaire sleutel meerdere velden bevatten. Zo kunnen we een uniciteit van een combinatie van waarden van deze velden opmerken. Als we bijvoorbeeld een sleutel definiëren voor de velden ID en NAME, zal de server controleren dat er geen identieke combinaties van deze velden in de tabel zijn. Dat wil zeggen, combinaties van velden ID en 1 en “Ivanov”, 2 en “Ivanov” zullen correct zijn omdat ze verschillen in de waarden van veld ID.
Dus kan de primaire sleutel meerdere velden van elk type bevatten. In de praktijk is het meest voorkomende type van de sleutel echter de teller - een integer veld dat toenemende waarden bevat. Waarom is dat zo? Het is de weerspiegeling van een oud geschil tussen natuurlijke en vervangende sleutels. Het concept van natuurlijke sleutels zegt dat we als sleutel de waarden moeten proberen te gebruiken die echt bestaan in het gegevensdomein dat een database weerspiegelt. Als we bijvoorbeeld een systeem ontwikkelen voor de registratie van mensen voor een paspoortkantoor, zou volgens dit concept een combinatie van nummer en serie van het paspoort als primaire sleutel moeten worden genomen. Echt, elke persoon moet een unieke combinatie van een nummer en een serie van het paspoort hebben. Maar wat te doen met het feit dat een persoon tijdens zijn leven van paspoort kan veranderen (in verband met het bereiken van een bepaalde leeftijd, trouwen, enz.)? In dit geval moeten we het nummer en de serie van het paspoort wijzigen die in overeenstemming zijn met de concrete persoon, d.w.z. eigenlijk onze primaire sleutel wijzigen. Dit is ongewenst vanuit het oogpunt van de ontwikkeling van databaseapplicaties: rekening houdend met een vertakt systeem van communicatie tussen tabellen (het volgende hoofdstuk is hieraan gewijd) zal de ontwikkelaar veel moeite moeten doen om deze situatie te beheersen.
Daarom wordt in de meeste gevallen een vervangende sleutel gebruikt. Vervangend - betekent kunstmatig, d.w.z. niet bestaand in het gegevensdomein dat onze database beschrijft, en kunstmatig gecreëerd - voor het gemak van de ontwikkeling van databaseapplicaties. Zoals gezegd, is meestal een teller een primaire sleutel. Sommige DBMS’en, zoals Paradox en MS SQL, hebben een speciaal type - de teller (auto increment). Bij het toevoegen van een nieuw record aan de tabel wordt een veldwaarde automatisch verhoogd met dit type voor de waarde van een increment - meestal per eenheden. In InterBase is er geen veld van het tellertype, maar dergelijk gedrag kan worden gerealiseerd. Voor het maken van het veld dat automatisch wordt gevuld bij het toevoegen van een record aan de tabel, wordt een verzameling van bronnen gebruikt: de eerste daarvan is generator.
Wat is een generator? Simpel gezegd, een generator is een benoemde teller. Binnen een database kunnen we een teller maken, een unieke naam geven binnen deze database en de waarden van deze teller beheren. Dat zal een generator zijn. Hier is een voorbeeld van DDL-instructies die dit aan je uitleggen:
CREATE GENERATOR g1; SET GENERATOR g1 TO 2445;
In de eerste regel van dit voorbeeld wordt generator met naam g1 gemaakt, en in de tweede regel wordt waarde 2445 aan deze generator toegewezen. Nu is er een vraag hoe de verkregen generator te gebruiken. Er is een ingebouwde functie GEN_ID in InterBase voor het verkrijgen en wijzigen van de waarden van generatoren. Deze functie neemt als parameters de naam van de generator en de waarde van de increment, die op de gegeven generator moet worden toegepast, en retourneert de integerwaarde die overeenkomt met de waarde van de generator, verkregen als resultaat van het toevoegen van de increment eraan. Hier is een voorbeeld van een GEN_ID-functieaanroep in een trigger of opgeslagen procedure:
Current_value = GEN_ID (g1, 1)
Als we de waarde van de generator willen ontvangen, kunnen we de volgende query gebruiken:
SELECT GEN_ID(g1, 1)FROM RDB$ DATABASE
Omdat tabel RDB $ Database altijd slechts één record bevat, ontvangen we een waarde van generator g1 als resultaat van de gegeven query.
Hier is current_value een variabele (in de volgende hoofdstukken vind je informatie over het gebruik van variabelen in InterBase), g1 - een generator, 1 - increment. In dit voorbeeld zal de waarde van generator g1 in de variabele current_value terechtkomen na het toevoegen van increment 1 eraan, d.w.z. de volgende waarde van de generator. Let op, de increment kan niet gelijk zijn aan 1! Bovendien kan deze zelfs negatief zijn: Current_value = GEN_ID (g1, -23)
Als resultaat van het uitvoeren van deze functie zal de huidige waarde van generator g1 min 23 zijn. Zoals je kunt zien, is een scala aan mogelijke toepassingen van generatoren vrij breed - het kan niet alleen worden gebruikt voor het verkrijgen van waarden van primaire sleutels, maar ook voor het volgen van globale wijzigingen in een database.
Mensen die bekend zijn met databases kunnen een vraag stellen: “wat gebeurt er als tegelijkertijd meerdere clients proberen gegevens naar dezelfde tabel te plaatsen en tegelijkertijd de generatoren ’trekken’? Zullen ze dezelfde of verschillende waarden van de generator ontvangen?”. Ze zullen ondubbelzinnig VERSCHILLENDE waarden van de generator ontvangen. Hoe ‘gelijktijdig’ de poging om de waarde van de generator te ontvangen ook was, iedereen die een aanvraag deed, zou de unieke waarde ontvangen. Dit wordt gegarandeerd door de ‘constructie’ van generatoren: ze werken op het laagste niveau van een server en geen processen van opnemen en invoegen beïnvloeden hen - er wordt vaak gezegd dat generatoren ‘buiten de context van transacties’ werken. Als je meer wilt weten over transacties, lees dan het hoofdstuk “Transacties. Parameters van transacties” (deel 1); hoe generatoren zijn georganiseerd - “InterBase database structuur” (deel 4). Nou, namens generatoren hebben we een betrouwbaar mechanisme voor het maken van unieke primaire sleutels. Kunnen we dit mechanisme echter gebruiken? Hoe de waarde die uit de generator is verkregen in een veld van de primaire sleutel te plaatsen?
Hiervoor zijn er twee manieren - een primaire sleutel invoegen namens een client en namens een server. Om de eerste manier onder de knie te krijgen, moeten we verwijzen naar het hoofdstuk “Gebruik van hoofdcomponenten van FIBPlus” en om de tweede te begrijpen - naar het hoofdstuk “Triggers” (deel 1). Hier zullen we kort het belangrijkste punt van beide manieren bekijken.
In het geval van het maken van een primaire sleutel namens een client gebeurt het volgende. Wanneer het record dat in een database zal worden ingevoegd, wordt gegenereerd, wordt GEN_ID-functieaanroep (, 1) uitgevoerd en wordt de ontvangen waarde voor dit record gesubstitueerd. Dan vindt het invoegen in de tabel plaats, en we zijn gegarandeerd een unieke primaire sleutel te ontvangen.
De tweede manier - het maken van een primaire sleutel namens een server - elimineert in het algemeen elke zorg van de kant van een client over welke waarde van een primaire sleutel het zal zijn. In dit geval werkt bij het invoegen van het record de trigger - een speciaal databaseobject, dat elke bewerking kan uitvoeren bij het invoegen/verwijderen/bijwerken van records in tabellen. En in deze trigger worden de volgende bewerkingen uitgevoerd: GEN_ID-functieaanroep, ontvangst van de vereiste waarde van de generator en het invoegen ervan in de tabel. Het voordeel van de tweede manier is dat bij het ontwikkelen van een clientapplicatie er helemaal geen zorg hoeft te zijn over het maken van een primaire sleutel, het enige wat je moet doen is eenmaal een noodzakelijke trigger schrijven. Maar het nadeel is dat we de waarde van de gegenereerde sleutel niet direct na het invoegen in de applicatie kunnen ontvangen! Als we de eerste manier gebruiken, kunnen we de waarde van de primaire sleutel ontvangen, hoewel we elke keer bij het invoegen voor het maken ervan moeten zorgen. Het is moeilijk om met zekerheid te zeggen welke manier beter is, alles hangt af van een specifiek probleem. Verder in dit boek zullen we mogelijke varianten bekijken voor het oplossen van vragen over het werken met een primaire sleutel.
Conclusie
Dus, in dit hoofdstuk hebben we bekeken hoe tabellen in InterBase te maken en bij te werken, evenals het omgaan met primaire sleutels. Zo hebben we de belangrijkste objecten in InterBase bekeken die voorwaardelijk statisch kunnen worden genoemd, omdat ze alleen de informatie opslaan en geen conversie ervan uitvoeren. Verder zullen we praten over de manieren van informatiebeheer en informatieconversie binnen een database.