Selv tak.
.. Har vist misforstået spørgsmålet lidt...
Når nu du ikke har behov for at kunne rette her og nu i dialogen, er det rette at bruge nedenstående løsning:
Brug en TDBLookupCombo med nøglen (field) ID og vise navn(ene) i comboen. Så er opgaven løst. Skal du rettet et navn går du ind i grp-tabellen og retter der. Så rettes det alle steder, simpelthen fordi den laver opslaget i grp og ser hvar der er der.
Det er smart at separere intern logik og ekstern data. De databærende felter skal ikke også være de der får tabellerne til at hænge sammen.
Desuden fylder det en del mindre da en tekststreng på 50 (her godtnok varchar som kun fylder hvad der bliver brugt - tror slet ikke MSSQL vil være med på det) er noget voldsommere end et heltal på 4 bytes.
Der er større risiko for at skrive forkert. En nøgle der hedder "Kontorforsyningsenhed" er mere usikkert end tallet 12.
Ulempen med en primærnøgle er, at du kan have sammenfald på navne (eks. flere forekomster af "Delahaye"), men det kan løses med et unikt indeks på navn-feltet.
CREATE TABLE [dbo].[grp]
(
[ID] [int] IDENTITY (1, 1) NOT FOR REPLICATION NOT NULL,
[navn] [varchar](50),
CONSTRAINT [pk_grp] PRIMARY KEY([ID])
)
CREATE TABLE [dbo].[nv]
(
[ID] [int] IDENTITY (1, 1) NOT FOR REPLICATION NOT NULL,
[grp_ID] [int] NULL,
[oprettet] [datetime] NULL CONSTRAINT [df_nv_oprettet]
CONSTRAINT [pk_nv] PRIMARY KEY([ID]),
CONSTRAINT [fk_nv_grp] FOREIGN KEY([grp_ID]) REFERENCES [grp] ([ID]) ON DELETE CASCADE ON UPDATE CASCADE
)
Kan sagtens strikke et eksempel sammen hvis du lægger en email.