Page 3 of 3 FirstFirst 1 2 3
Results 31 to 35 of 35

Thread: IDNummer verkrijgen na een trigger

  1. #31
    Geloof me, je maakt het jezelf een stuk simpeler als je elke tabel zijn eigen primary key geeft. Op de andere manier loop je vast, al was het alleen maar omdat je steeds discussie hebt over wat nou uniek is en wat niet.

    Neem een factuur regel. Moet deze een eigen key hebben? Nee, eigenlijk niet want een factuur is altijd van een klant, dus "hoor" je de klant in de sleutel op te nemen. Bij een factuurregel worden dat dus al 3 velden om de juiste regel te vinden. Ergens komt er een moment dat je je database in moet omdat er iets vreselijk mis is gegaan. In plaats van te zoeken naar de factuurregel met ID 12345 moet je dan dus steeds gaan zoeken naar de factuurregel met klant nummer 2009123, factuurnummer 2009987 en regelnummer 4.

    Ik zou het wel weten

    Overigens... datzelfde probleem heb je ook bij GUIDs en dat is dan ook mijn (enige?) bezwaar tegen het gebruik van GUIDs als sleutel: het is zeer slecht datatracen.
    Marcel

  2. #32
    In principe heeft elke tabel bij mij een dubbele sleutel: een autoincrement om de tabellen aan elkaar te gaan koppelen en daarnaast een andere unieke sleutel, zoals bijvoorbeeld het ArtikelId en het ArtikelNummer of zoals hierboven aangegeven FactuurIdnr en FactuurNummer/Factuurregel.

    De constraints in de database gebruik ik een stuk minder omdat dit serieus wat implicaties heeft op de verwerkingssnelheid terwijl deze door de software toch gecontroleerd wordt.

  3. #33
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Geloof me, je maakt het jezelf een stuk simpeler als je elke tabel zijn eigen primary key geeft
    Maar dat is het probleem ook niet. Elke tabel heeft bij ons een primary key.
    Waar mijn collega problemen mee heeft is het volgende:
    - de volgorde van de key
    - de autoincrement, die altijd als eerste moet worden vermeld
    - de volgorde waarin de foreign key van referentiële integriteit wordt opgebouwd.


    Door een trigger te maken, kan hij zelf de volgorder van de primary key bepalen.
    Last edited by jkuiper; 10-Feb-09 at 10:38. Reason: extra informatie
    Delphi is great. Lazarus is more powerfull

  4. #34
    Ik denk dat Marcel bedoelt dat je een orderregel een eigen uniek id geeft (autonum) en dat als primary key gebruikt, in plaats van de primary key samen te stellen uit foreign keys. Een order heeft dus een orderid en een orderregel een orderregelid. Beide zijn autonummers, en compleet niet gerelateerd aan elkaar. Daarnaast heeft een orderregel ook een orderid, maar dat is alleen een foreign key, aldanniet met een index er op voor performance. OrderId maakt geen deel uit van de primary key van orderregel, omdat orderregelid op zichzelf al uniek is.
    Constraint, behalve de foreign zelf, heb je ook niet nodig.

    Ik snap dus nog steeds niet zo wat je nou bedoelt met de 'volgorde van de key'.
    1+1=b

  5. #35
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Hopelijk de strijd enigszins gewonnen.
    We gaan (net zoals in onze oude applicatie) gebruik maken van een tabel. Daar staat een nummer, die met +1 het volgende ID wordt.
    De trigger gaat gewoon niet werken. Deze geeft geen result terug.
    Dus voordat er een post wordt gedaan, of na de append in de dataset wordt het nummer geplaatst d.m.v. van een functie.
    Delphi is great. Lazarus is more powerfull

Page 3 of 3 FirstFirst 1 2 3

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •