Évente visszaálló sorozatszám-generátor – több előtag támogatása

Ebben a cikkben Tamás, a könyvtár egyik fejlesztője, bemutatja azokat a fejlesztési döntéseket, amelyek a könyvtárban elérhető „Évente visszaálló sorozatos azonosító-generátor – több előtag támogatása” nevű építőelem-alkalmazás mögött állnak.

Miért így építettem fel

Ezt a logikai blokkot egy nagyon gyakorlati probléma megoldására terveztem: olyan azonosítók generálására, amelyek megbízhatóak, könnyen újrahasznosíthatók és gyorsan bevezethetők számos alkalmazásban.Célom az volt, hogy maga az azonosító tartalmazzon mindent, ami a következő kiszámításához szükséges. Az azonosító minden részének egyértelmű szerepe van:* az előtag jelzi, melyik sorozathoz tartozik az azonosító* az év időben elválasztja a sorozatokat* a szám az adott éven belüli sorrendet jelzi

Ennek a felépítésnek köszönhetően nem kellett semmilyen visszaállítási logikát bevezetnem. A legutóbbi létező azonosító már tartalmazza az összes szükséges információt a következő generálásához. Amíg az utolsó azonosító érvényes, a következő azonosító mindig kiszámítható módon állítható elő.

Az évet közvetlenül az azonosítóba építettem be, mert ez természetes módon elválasztja a rekordokat az idő mentén. Ez lehetővé teszi azt is, hogy a számozás minden évben automatikusan újrainduljon, anélkül, hogy bármilyen ütemezett visszaállításra vagy kézi frissítésre lenne szükség.

Az előtag határt képez a különböző sorozatok között. Ez lehetővé teszi, hogy ugyanazon táblán belül több független számozási sorozatot futtassunk. Az előtag megváltoztatása egyszerűen egy másik sorozat folytatását jelenti.

Ellenőrzést is beépítettem, mert az egész megközelítés egy konzisztens azonosító-struktúrán alapul. Ha egy meglévő azonosító nem felel meg a várt formátumnak, a sorozat folytatása zavaros vagy inkonzisztens eredményekhez vezethet. Inkább időben leállítom a folyamatot, jelzem a problémát, és elkerülöm a hibás azonosítók generálását.

Egy csatlakozóalapú keresést választottam, így a logikai blokk különböző táblákkal is működhet anélkül, hogy a maglogikát módosítani kellene. A csatlakozó konfigurálása után csak a tableId-t és az előtagot kell megadni, és ugyanaz a logikai blokk több helyen is újrahasznosítható.

Számomra a cél nem csupán az azonosítók generálása volt, hanem egy újrafelhasználható minta létrehozása, amelyben maga az azonosítóformátum határozza meg a számozás működését. Ez teszi a logikát egyszerűvé, kiszámíthatóvá és az alkalmazások között könnyen újrafelhasználhatóvá.

Mit csinál ez a logikai blokk?

Ez a logikai blokk olyan sorszámozott azonosítókat generál, amelyek évente visszaállnak, a következő szerkezet szerint:előtag + év + sorszám

Példa: TEST20240001 TEST20240002

Az évváltáskor a számozás automatikusan 1-től indul újra: TEST20250001

Ugyanabban a táblázatban több előtag is létezhet. Minden előtag saját, független sorozatot tart fenn: ORD20240001 ORD20240002 INV20240001 INV20240002

A logikai blokk biztosítja: * az azonosítók formátumának következetességét * az automatikus éves visszaállítást * az előtagonkénti független számozást * a hibásan formázott korábbi azonosítók korai felismerését * a numerikus túlcsordulás korai felismerését

Miért része a csatlakozó a tervezésnek

A következő azonosító generálása előtt a logikai blokknak szüksége van az adott előtag legfrissebb létező azonosítójára. A csatlakozó szűrt keresést hajt végre: * kiszűri azokat a rekordokat, amelyek azonosítója az előtaggal kezdődik * csökkenő sorrendbe rendezi a _sequenceNumber szerint * visszaadja a legfrissebb rekordot

Mivel az előtag része a szűrőnek, minden előtagnak megvan a saját futószámlálója még ugyanazon táblán belül is. Ez biztosítja a sorozatok elkülönítettségét és kiszámíthatóságát.

Hogyan épül fel a kód?

A tényleges megvalósítás három triggert használ. Ez a felépítés szándékos. Azt akartam, hogy a logikai blokk felülről lefelé könnyen követhető legyen, miközben a fő logika elkülönült és újrafelhasználható marad. Így ahelyett, hogy a logikát számos szerkeszthető triggerre osztottam volna szét, három szakaszba szerveztem:1. FELHASZNÁLÓI BEÁLLÍTÁS: BEMENETI SZAKASZ 2. MAGIC érvényesítés + azonosító generálás 3. FELHASZNÁLÓI BEÁLLÍTÁS: KIMENETI SZAKASZ

Ez jó egyensúlyt teremt a használhatóság és az irányítás között.* Az első triggerben határozza meg a bemeneti adatokat.* A második trigger tartalmazza a belső logikát, amelyet általában nem kell szerkeszteni ahhoz, hogy a logikai blokk működjön.* A harmadik triggerben dönti el, mit kezdjen a generált eredménnyel.

Ez azt jelenti, hogy általában nem kell a maglogikai triggeren belül dolgoznia. Csak a bemeneti és a kimeneti oldalt kell konfigurálnia. Ez volt az egyik legfontosabb tervezési döntés: a logikai blokk újrafelhasználhatóvá tétele azáltal, hogy csak azokat a részeket tesszük elérhetővé, amelyeket általában módosítani kell.

1. trigger – USER CONFIG: BEMENETI SZAKASZ

Ez az első trigger, amellyel interakcióba lép. Célja, hogy meghatározza azokat a bemeneti értékeket, amelyekre a logikai blokknak szüksége van, mielőtt bármilyen azonosító generálható lenne. A gyakorlatban ezt a triggert a következők meghatározására használják:* Az előtag: _configPrefix* Az azonosító hossza: _configIdNumberFormat* A csatlakozóba átadott táblázat-azonosító: tableId

Mit jelentenek az egyes értékek

_configPrefix: Ezaz a szöveg, amely minden generált azonosító elejére kerül. Ezzel határozza meg, hogy milyen sorozatot szeretne generálni.

Példák:* ORD* INV* TEST

Ha _configPrefix = ORD, a logikai blokk csak az ORD-vel kezdődő meglévő azonosítókat veszi figyelembe, és csak azt a sorozatot folytatja. Ez az érték tehát egyszerre két dolgot is elvégzi:* meghatározza a végső azonosítóban látható előtagot* meghatározza, hogy a csatlakozó mely korábbi azonosítókat használja a következő szám forrásaként

Ez azt jelenti, hogy ugyanazon táblában a különböző előtagok különböző sorozatokat eredményeznek**._configIdNumberFormat**

Ez határozza meg az azonosító numerikus részének hosszát. Nullákkal kitöltött karakterláncként kell beállítani. Példák:000000000000000000

A nullák száma határozza meg a numerikus rész szélességét.

Példák:0000 → 0001, 0002, 0003 ... 9999 000000 → 000001, 000002 ... 999999

Ez az érték nem a tényleges számot határozza meg. Hanem azt a formátumot határozza meg, amelybe a számnak illeszkednie kell. Két célra használom: * az előtti nullák hozzáadására a generált számhoz * annak ellenőrzésére, hogy a következő szám továbbra is illeszkedik-e a megengedett hosszúsághoz

tableId

Ez határozza meg, hogy a csatlakozó melyik táblát kérdezze le.

A gyakorlatban ez teszi a logikai blokkot újrafelhasználhatóvá különböző táblák között. Ugyanazt a logikai blokkot lemásolhatja, és egy másik táblára irányíthatja úgy, hogy csak ezt az értéket módosítja a konfigurációs triggerben.

A logikai blokk önmagában nem keres táblákat. Átadja a tableId és az _configPrefix értékeket a csatlakozónak, amely visszaküldi az adott táblából a legfrissebb, megfelelő azonosítót.

Hogyan használjuk őket együtt

Ez a három érték együttesen határozza meg a generátor viselkedését:* a tableId megadja a logikai blokknak, hol keressen* az _configPrefix megadja, melyik sorozatot folytassa* az _configIdNumberFormat megadja, hogyan kell kinéznie a numerikus résznek

Gyakorlati beállítási útmutató

A logikai blokk konfigurálásakor ügyeljen arra, hogy:* a tableId a megfelelő táblára mutasson* az _configPrefix egyezzen a folytatni kívánt előtaggal* az _configIdNumberFormat egyezzen a kényszeríteni kívánt számhosszal

Ha megváltoztatja az előtagot, akkor már nem a régi sorozatot folytatja. Egy másik, az előtaghoz tartozó sorozatot indít el vagy folytat. Ha később megnöveli a számformátum hosszát, a logikai blokk azt a szélesebb formátumot várja el, amikor a táblában és az előtag hatókörében lévő meglévő azonosítókat érvényesíti.A csatlakozó lekérdezi az előtaggal egyező legfrissebb azonosítót, és azt a _stateLastId-ben tárolja. Ha még nem létezik azonosító, a LINK() biztosítja, hogy a generátor továbbra is létre tudja hozni az első érvényes azonosítót.

Miért része a csatlakozó a tervezésnek

A csatlakozó nem csupán egy technikai részlet. A újrafelhasználási stratégia része. A csatlakozót arra használom, hogy kiolvassam a cél táblából a legfrissebb létező azonosítót. A csatlakozó bemenetként megkapja a tábla azonosítóját, alkalmazza az előtagszűrőt, csökkenő sorrendbe rendezi a rekordokat a _sequenceNumber szerint, és visszaadja a legfrissebb, a feltételeknek megfelelő rekordot.

Ez két okból is fontos.

Először is, ez lehetővé teszi a logikai blokk számára, hogy a táblázat tényleges állapotától folytassa a számozást.

Másodszor, így a logikai blokk sokkal könnyebben újrahasznosítható. Ha a gombot másolod egy másik alkalmazásba, nem kell újraírnod a logikát. Csak a csatlakozót kell a megfelelő táblára irányítania, és meg kell adnia a szükséges konfigurációt. Ez a gyakorlati minta áll a kialakítás mögött: * egyszer létrehozza a gombot * beállítja a táblabemenetet a csatlakozóban * meghatározza az előtagot és a számformátumot * újrahasznosítja, ahol csak szükséges

Ez egy tudatos döntés volt, amelynek célja az alkalmazások gyorsabb fejlesztésének támogatása.

Mit csinál a csatlakozó a logikai blokkban?

Mi történik itt:* a csatlakozó megkapja a táblázat azonosítóját* a csatlakozó megkapja az előtagot* a csatlakozó az előtag alapján szűri a rekordokat* a csatlakozó a _sequenceNumber szerint csökkenő sorrendbe rendezi a rekordokat* a csatlakozó visszaadja a legutóbbi egyező azonosítót

A csatlakozó egy nagyon fontos felhasználási esetet is támogat: több entitás ugyanabban a táblában.

Ha ugyanaz a táblázat olyan rekordokat tartalmaz, mint: ORD20240001 MAT20240011

akkor a logikai blokknak nem szabad ezeket egyetlen közös sorozatként kezelnie. Minden előtag csak a saját legfrissebb értékétől folytathatja a sorozatot.

Így a csatlakozó először előtag szerint szűr. Ez azt jelenti, hogy a következő értékek a következők lesznek: ORD → ORD20240002, MAT → MAT20240012

Ezt a modellt azért választottam, mert ugyanabban a táblában különböző entitások is szerepelhetnek, de ez nem jelenti azt, hogy ugyanazt a sorszámot kellene használniuk.

Egy beállítási követelményt is érdemes egyértelműen megemlíteni: a csatlakozónak hitelesítésre van szüksége, ezért létre kell hozni egy tokent, és hozzá kell adni a csatlakozó hitelesítési beállításaihoz. Ezt beállítási feladatnak tekintem, nem a logikai blokk logikájának részének, de mégis fontos része annak, hogy a logikai blokk használható legyen.

2. trigger – MAGIC: érvényesítés + azonosító generálás

Ez a trigger a logikai blokk központi logikája. Három dolgot hajt végre sorrendben: 1. ellenőrzi, hogy a legutóbbi egyező azonosító rendelkezik-e a várt szerkezettel; 2. ellenőrzi, hogy a következő szám még mindig illeszkedik-e a beállított számhosszúsághoz; 3. létrehozza a következő azonosítót

Ezeket a lépéseket egyetlen triggerbe csoportosítottam, mivel ugyanahhoz a döntési folyamathoz tartoznak. Mielőtt új azonosítót hoznék létre, három kérdésre szeretnék választ kapni: * az előző azonosító szerkezetileg biztonságosan használható-e? * a következő szám továbbra is illeszkedne-e a formátumhoz? * ha igen, mi legyen a következő azonosító?

Formátum-ellenőrzés

Expression

REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + DATETIMETOTEXT(App info.Current Date and Time,'YYYY') + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}' + '[0-9]{' + LEN(Variable._configIdNumberFormat) + '}$','ok')

Mit csinál ez a expression?

Ez az expression ellenőrzi, hogy a legutóbbi azonosító pontosan megfelel-e annak a szerkezetnek, amelyet a logikai blokk elvár. A következő sorrendben működik: 1. A LINK(...) a Variable._stateLastId.id értéket veszi át, amikor a csatlakozó visszaad egy értéket. 2. Ha még nincs azonosító, a LINK(...) egy tartalékértéket használ, amely a következőkből épül fel: * Variable._configPrefix * DATETIMETOTEXT(...,'YYYY') * Variable._configIdNumberFormat3. Ezt a tartalékértéket azért építik be, hogy az érvényesítésnek még akkor is legyen érvényes szerkezete, amit kiértékelhet, ha ez az első generált azonosító.4. A Variable._configPrefix határozza meg azt a pontos előtagot, amellyel az azonosítónak kezdődnie kell. 5. A DATETIMETOTEXT(...,'YYYY') nem kerül felhasználásra egyezési értékként magában a reguláris kifejezésben, de része a tartalék szerkezetnek, így a tartalék valódi azonosító formátumúnak tűnik. 6. A LEN(Variable._configIdNumberFormat) meghatározza, hogy a numerikus résznek hány számjegyből kell állnia.7. A REGEX_REPLACE(...) ezután a teljes karakterláncot összehasonlítja ezzel a mintával: * előtag * pontosan 4 számjegy az évre * pontosan N számjegy a numerikus részre8. Ha a teljes karakterlánc egyezik, az egész értéket „ok”-ra cseréli.9. Ha nem egyezik, az eredeti érték változatlan marad.10. A trigger ezután ellenőrzi, hogy az eredmény egyenlő-e az „ok”-kal. Ha nem, a végrehajtás leáll.

Tehát ez a expression nem von ki értékeket számítás céljából. Feladata annak ellenőrzése, hogy az azonosító rendelkezik-e a várt szerkezettel, mielőtt bármilyen numerikus logikát alkalmaznának rá.

Miért választottam ezt

Úgy döntöttem, hogy a numerikus logika alkalmazása előtt ellenőrizem a teljes azonosító szerkezetét. Azért építettem fel így, mert a trigger többi része rögzített pozíciókat feltételez: * előtag az elején * év közvetlenül az előtag után * szám közvetlenül az év után

Ha az előző azonosító nem felel meg ennek a szerkezetnek, akkor az abból történő növelés megbízhatatlan lenne.

Úgy döntöttem továbbá, hogy ide beépítem a LINK(...) tartalék megoldást is, így az első generált azonosítóhoz nincs szükség külön érvényesítési logikára. Ugyanez az érvényesítési útvonal akkor is működik, ha létezik régebbi azonosító, és akkor is, ha nincs. Szándékosan leállítom a triggert, ahelyett, hogy megpróbálnám kijavítani a hibás formátumú azonosítókat. Az automatikus javítás elrejtené az adatproblémákat, és olyan sorozatot hozhatna létre, amely érvényesnek tűnik, de hibás bemeneti adatokon alapul.

Túlcsordulás elleni védelem

Expression

LEN(IF(MID(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat), LEN(Variable._configPrefix), 4) = DATETIMETOTEXT(App info.Jelenlegi dátum és idő,'YYYY'),RIGHT(Variable._configIdNumberFormat+ TOTEXT(TEXTTOINTEGER(REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}','')) + 1),LEN(Variable._configIdNumberFormat)),RIGHT(Variable._configIdNumberFormat + '1', LEN(Variable._configIdNumberFormat))))

Mit csinál ez a expression?

Ez az expression kiszámítja, mi lenne a következő numerikus rész, majd meghatározza annak hosszát. A következő sorrendben működik: 1. A LINK(...) az utolsó azonosítót használja, ha létezik ilyen. Ha nincs, akkor a Variable._configPrefix + Variable._configIdNumberFormat értékre tér vissza. 2. A MID(..., LEN(Variable._configPrefix), 4) a prefixet közvetlenül követő 4 karaktert olvassa ki. Ezt az előző azonosító évrészeként kezeli. 3. A DATETIMETOTEXT(...,'YYYY') az összehasonlításhoz az aktuális évet adja meg. 4. Az IF(...) eldönti, hogy a numerikus rész folytatódjon-e vagy álljon vissza: * ugyanaz az év → növekmény * más év → 15-től kezdődik. A növelési ágban a REGEX_REPLACE(...) eltávolítja az előtagot és a 4 számjegyű évet az előző azonosító elejéről, így csak a numerikus rész marad meg.6. A TEXTTOINTEGER(...) + 1 átalakítja azt a numerikus szöveget számmá, és növeli az értéket.7. A TOTEXT(...) az új számot visszaalakítja szöveggé.8. A Variable._configIdNumberFormat + ... az érték elé illeszti a beállított nullázási formátumot.9. A RIGHT(..., LEN(Variable._configIdNumberFormat)) csak a szükséges számú számjegyet tartja meg.10. A visszaállítási ágban a RIGHT(Variable._configIdNumberFormat + '1', LEN(...)) létrehozza az új évre vonatkozó első megengedett számot.11. A LEN(...) meghatározza a kapott numerikus rész hosszát.

A trigger összehasonlítja ezt a hosszúságot a Variable._configIdNumberFormat-ból származó megengedett hosszúsággal. Ha a következő numerikus rész túl hosszú lenne, a végrehajtás leáll.

Miért ezt választottam

Úgy döntöttem, hogy a következő számot ugyanúgy számolom ki, ahogyan az azonosítót ténylegesen generálják, ahelyett, hogy egy külön képletet használnék annak kitalálására, mikor haladná meg a szám a megengedett hosszúságot.

Azért építettem fel így, mert azt akartam, hogy a túlcsordulás-ellenőrzés pontosan ugyanazokat a szabályokat kövesse, mint a valódi azonosító generálás. Ez csökkenti annak esélyét, hogy a validációs logika és a generálási logika később eltérjen egymástól.

Biztonságosabb itt leállni, mint folytatni. Ha a következő numerikus érték már nem fér bele a beállított hosszúságba, az eredményül kapott azonosító megsértené az Ön által beállított struktúrát.

Például, ha a numerikus formátum 0000, akkor a 9999 érvényes, a 10000 viszont nem. Azt szeretném, ha a logikai blokk ezt a rekord létrehozása előtt észlelné, nem utána.

Az azonosító generálási logika

Expression

Variable._configPrefix+ DATETIMETOTEXT(App info.Current Date and Time,'YYYY')+ IF(MID(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),LEN(Variable._configPrefix),4) = DATETIMETOTEXT(App info.Jelenlegi dátum és idő,'YYYY'),RIGHT(Variable._configIdNumberFormat+ TOTEXT(TEXTTOINTEGER(REGEX_REPLACE(LINK(Variable._stateLastId.id, Variable._configPrefix + Variable._configIdNumberFormat),'^' + Variable._configPrefix + '[0-9]{4}','')) + 1),LEN(Variable._configIdNumberFormat)),RIGHT(Variable._configIdNumberFormat + '1', LEN(Variable._configIdNumberFormat)))

Mit csinál ez a expression?

Ez az a „ expression ”, amely létrehozza a végleges azonosítót. A következő sorrendben működik: 1. A Variable._configPrefix hozzáadja a konfigurált előtagot az azonosító elejéhez. 2. A DATETIMETOTEXT(App info.Current Date and Time,'YYYY') hozzáadja az aktuális 4 számjegyű évet. 3. A LINK(...) a csatlakozó által visszaadott utolsó azonosítót használja, ha van ilyen. Ha a csatlakozó nem ad vissza azonosítót, akkor a Variable._configPrefix + Variable._configIdNumberFormat kifejezést használja tartalék szerkezetként. 4. A MID(..., LEN(Variable._configPrefix), 4) kiolvassa az előtagot közvetlenül követő 4 karaktert. Ezeket az előző azonosító évrészeként kezeli. 5. A DATETIMETOTEXT(...,'YYYY') függvényt itt ismételten használjuk, hogy a „ expression ” eldönthesse, az előző azonosító az aktuális évhez tartozik-e.6. Az IF(...) függvény irányítja a két lehetséges útvonalat: * ugyanaz az év → folytatódik a számozás * másik év → visszaállítás 17-re. Az azonos évre vonatkozó ágban a REGEX_REPLACE(...) eltávolítja az előtagot és a 4 számjegyű évet az előző azonosító elejéről, így csak a számrész marad meg.8. A TEXTTOINTEGER(...) + 1 ** növeli azt a numerikus értéket.9. A TOTEXT (...) visszaalakítja a növelt értéket szöveggé.10. A Variable._configIdNumberFormat + ... a beállított nulla-formátumot helyezi az új érték elé.11. A RIGHT (..., LEN(Variable._configIdNumberFormat)) csak a szükséges számú számjegyet tartja meg, így a numerikus rész hossza mindig rögzített marad.12. A visszaállítási ágban a RIGHT (Variable._configIdNumberFormat + '1', LEN(...))** létrehozza az új éves sorozat első számát.13. Az előtag, az aktuális év és a formázott szám összevonásra kerül a végső azonosítóvá.

Így a végső kimenet mindig a következő szerkezetű:előtag + év + rögzített hosszúságú szám

Miért választottam ezt

Úgy döntöttem, hogy a következő azonosítót teljes egészében a táblázat legfrissebb valós azonosítójából vezetem le. Azért építettem fel így, mert az előző azonosító már tartalmazza mindazt, amire a logikának szüksége van:* melyik előtaghoz tartozik a sorozat* melyik évhez tartozik* mi volt az utolsó numerikus érték

Ez azt jelenti, hogy nincs szükségem külön számlálótáblára, tárolt évmezőre vagy ütemezett éves visszaállításra.

A fix hosszúságú formázást is azért választottam, mert így a szerkezet kiszámítható marad, és könnyebb ellenőrizni.

Ennek az az ára, hogy az „ expression ” szigorú azonosító-struktúrától függ. Éppen ezért az érvényesítési lépés jön először. Elfogadtam ezt a kompromisszumot, mert egy szigorú és olvasható szerződés itt hasznosabb, mint sok laza bemeneti formátum támogatása.

3. kiváltó – USER CONFIG: KIMENETI SZAKASZ

Ez a logikai blokk utolsó triggerje. Célja annak meghatározása, hogy mi történjen a generált azonosítóval, miután az _stateOutput érvényes értéket tartalmaz.

A lényeg itt az, hogy ezt a fázist szándékosan nyitva hagytuk az Ön számára.

Ha az _stateOutput nem üres, akkor Ön döntheti el, hogy a logikai blokk mit tegyen ezután. A jelenlegi beállításban a trigger egy útmutató üzenetet jelenít meg, amely elmagyarázza a következő lépéseket: * adja hozzá a konfigurált táblázatot az alkalmazáshoz * cserélje ki az üzenetlépést egy „Create Record” triggerre * használja az _stateOutput-ot az új rekord azonosítójaként

Azért építettem így, mert a kimeneti viselkedés az egyes felhasználási esetek között eltérő lehet.

Lehet, hogy: * azonnal létre szeretne hozni egy rekordot * először egy másik változóban szeretné tárolni az azonosítót * egy hosszabb munkafolyamaton belül szeretné felhasználni az azonosítót * további feltételeket szeretne ellenőrizni, mielőtt a táblába írna

Ahelyett, hogy egy rögzített kimeneti viselkedést építettem volna be, a kimeneti szakaszt konfigurálhatóvá tettem.

Ezért található a felhasználó számára látható konfiguráció a logikai blokk mindkét végén:* a bemeneti struktúra konfigurálható* a kimeneti viselkedés konfigurálható* a maglogika a közepén marad

Változónevezési megközelítés

A belső változók aláhúzásjel előtagot használnak:* _configPrefix* _configIdNumberFormat* _stateLastId* _stateOutput

Ez segít a konfigurációs értékek és a belső feldolgozási változók gyors megkülönböztetésében.

Tervezési határok

A logikai blokk a következő szerkezetet feltételezi:előtag + év + szám. Minden előtag saját, független sorozatot tart fenn.

A logikai blokk nem támogatja, hogy egy számláló több előtagra is kiterjedjen.

Ha az év vagy a számrész az azonosítón belül máshova kerül, az expressions-t ennek megfelelően módosítani kell.

A fejlesztési döntések összefoglalása

Ha az egész logikai blokkot a mögötte álló alapvető döntésekre redukálom, azok a következők:* Gyors újrafelhasználhatóságot akartam, ezért a logikai blokk konfigurációvezérelt.* Azt akartam, hogy a táblázat legyen a hiteles forrás, így a következő azonosító mindig a legfrissebb valós rekordon alapul.* Azt akartam, hogy a logika karbantartható maradjon, ezért a számítás egy helyre van központosítva.* Azt akartam, hogy egy táblában több entitás is zökkenőmentesen működjön, ezért minden előtaghoz saját, független sorozata tartozik.* Azt akartam, hogy az azonosító szerkezete idővel is konzisztens maradjon, ezért az év az azonosító része, és a sorozat automatikusan visszaáll, amikor az év megváltozik.* Azt akartam, hogy a táblát megvédjem a helytelen mintázatoktól, ezért a formátum-érvényesítés és a túlcsordulás-ellenőrzés még a rekord létrehozása előtt megakadályozza a hibás azonosítók kialakulását.* Azt akartam, hogy a trigger folyamat olvasható maradjon, ezért a feladatok egyértelmű lépésekre vannak felosztva: konfiguráció, érvényesítés, generálás, kimenet.

Ezért néz ki így a logikai blokk. Ez nem csupán egy azonosító-generátor. Ez egy újrafelhasználható minta az ellenőrzött azonosító-létrehozáshoz, amely megpróbálja egyensúlyba hozni az egyszerűséget, az újrafelhasználhatóságot és az adatvédelmet, miközben az éves szegmentációt közvetlenül beépíti az azonosító szerkezetébe.

Csatlakozz hozzánk

Csatlakozz a közösséghez, hogy megoszthasd a fejlesztéseket, további egységeket javasolhass, problémákat jelenthess, vagy megvitathasd az architektúrával kapcsolatos döntéseket.