Item Blog

Néhány dolog, amire érdemes figyelni, ha functional design-okat szerkesztünk

Header-ök a szövegben

Bár a dokumentumban ez nem látszik, minden egyes header kap egy tag-et a Genessis-ben, amivel értelemszerűen egy ID-is jár. Hogy ezt hogy tudjuk megnézni, arról bővebben az ID ütközések feloldásánál.

Requirement-ek áthelyezése másik dokumentumba

Áthelyezéskor célszerű megőrizni a tesztelhető requirementek ID-jét, hiszen így nem kell átírni a unit testek referenciáit. Ezt a következőképp tehetjük:
Átmásoljuk a functional design adott részét. (Elvileg a dokumentumok egymástól távoli számoktól kezdik az ID-k kiosztását, így nem kell aggódni amiatt, hogy az új dokumentumban már szerepel ez az azonosító.)
Ezután a régi dokumentumban eltávolítjuk a másolt részekről a tag-eket. Ha ezt nem tesszük meg, akkor ugyanaz az ID két helyen is szerepelni fog. (A tapasztalatok szerint a sima törlés nem feltétlen elég, a tag bennmaradhat a dokumentumban, így törlés előtt el kell távolítani)

Ha a build duplikált ID-t mutat

Ebben az esetben a Genesis nem frissül, a build pedig nem írja ki, hogy hol szerepelnek az adott ID-k, így problémás lehet megtalálni. Ha keresnünk kell, akkor a legegyszerűbb a docx fájlokat kicsomagolni (a docx tulajdonképpen több xml fájl becsomagolva) és a \word\document.xml fájlban megkeresni. A tagek alakja a dokumentumban:
Header: GENESIS_H_”ID”
Requirement group: GENESIS_RG_”ID”
Testable: GENESIS_R_”GroupID”_”ID”_NT_REQ
Not testable: GENESIS_R_”GroupID”_”ID”_REQ
Nem sokkal a tag után szerepel maga a szöveg is, így megtalálhatóak a problémás részek. Ugyanígy, ha egy header tag ID-jére vagyunk kíváncsiak, akkor megkeressük a szöveget az xml fájlban, a tag-et pedig nem sokkal előtte találjuk.

   A synergy-s táblákban az ID mezők általában nem szokványos INT(1,1) IDENTITY-k, hanem GUID típusú adatok.

A GUID (Globally Unique IDentifier), ahogy a neve is mutatja, egy egyedi azonosító, mely az UUID (Universally Unique IDentifier) egy megvalósítása. Ennek megfelelően egy 16 bájt hosszúságú azonosítóról beszélhetünk. Generálható teljesen random módom, vagy bizonyos paraméterek felhasználásával. A szabvány első verziója a MAC címet és egy 100 ns felbontású időbélyeget (kezdőpontja a Gergely-naptár első napja) használt fel, viszont így megjelent egy teljesen nyilvánvaló biztonsági rés: a GUID-ból egyértelműen meghatározható a generáló gép azonosítója és a generálás ideje. Épp ezért a négyes verzió (a Microsoft is ezt használja, az egyik legelterjedtebb) már egy pszeudo-random számot használ.

Ha MSSQL-ben akarunk ilyen ID-t használni, akkor azt a uniqueidentifier kulcsszóval tehetjük. Ebben az esetben vagy megadjuk alapértelmezett értéknek a NEWID() függvényt, vagy minden INSERT-nél külön be kell illeszteni a egy ID-t a NEWID()-vel.

NEWID() vs. IDENTITY

Egyrészt egy ilyen GUID jóval több helyet foglal, mint egy szokványos INT típusú IDENTITY, másrészt az utóbbival ellentétben a generált kulcsok nincsenek sorrendben. Ez azért probléma, mert alapesetben az SQL Server klaszterezett indexelést használ. Mivel ez összefügg az adatok fizikai elhelyezkedésével, így minden egyes NEWID()-s beillesztés egyben az adatok átrendezését is jelenti.
Másrészt az ID-k mérete is megnövekszik, hiszen a szokványos INT helyett egy 16 bájtos adatot kell tárolni, plusz a klaszterezés és nem szekvenciális ID-k együttes hatása miatt nagyon megugrik a töredezettség mértéke is.
Ezekre a problémákra jelent részben megoldást, ha a NEWID() helyett a NEWSEQUENTIALID()-t használjuk: ez a módszer garantálja, hogy az generált ID nagyobb lesz a számítógép bekapcsolása óta generált összes GUID-nél. Ezen felül a generáláshoz felhasználja a MAC címet is, így elérhető, hogy két különböző gépen se generálhasson megegyező GUID-t.
Ez a tulajdonság teszi jól használhatóvá az ilyen típusú ID-kat: ha több táblából akarunk adatokat egyesíteni, amik érkezhetnek akár több gépről is (például adattárházak esetén), akkor biztosak lehetünk benne, hogy nem lesz azonos kulcs az összefésült adatok között.

Általában tehát célszerű az IDENTITY-t választani, viszont ha a későbbiekben táblákat kell majd egybeolvasztani, akkor a NEWSEQUENTIALID() segítségével elkerülhető a kulcsok ütközése.

Akit részletesebben érdekel a téma:
http://en.wikipedia.org/wiki/Globally_unique_identifier
http://en.wikipedia.org/wiki/Universally_unique_identifier

Pár cikk a NEWID() vs. IDENTITY témában:
http://mssql.wordpress.com/2007/07/28/primary-key-newid-vs-identity-column/
http://www.sqlteam.com/article/uniqueidentifier-vs-identity
http://www.mssqltips.com/sqlservertip/1600/auto-generated-sql-server-keys-with-the-uniqueidentifier-or-identity/

A belgáktól kaptunk néhány, a belga gyakornokoknak továbbítandó standard-et a view-kkal kapcsolatban. Ennek (picit bővített) fordítása következik:

• Soha ne használjunk *-ot egy view-ban, mivel az újrafordítás során változhat az oszlopok sorrendje, ami nem várt viselkedéshez vezethet!
• A view minden oszlopa kerüljön új sorba!
• Az oszlopokat elválasztó vesszők a sorok elején szerepeljenek!
• A tábláknál mindig használjunk alias-okat, javítja az olvashatóságot!
• A JOIN-oknál nincs szükség az INNER és OUTER kulcsszavakra.
• Minden JOIN kerüljön új sorba, szintén az olvashatóság miatt
• Soha ne használjuk a vw_ előtagot (ez mondjuk az UBM project-nél kicsit körülményes lenne)
• A join-olt táblákból származó oszlopok elnevezésénél használjuk a táblához rendelt alias-t is (az order manager-ből egy példa: Description => WorkingCalendarDescription)

Ha egy conditionben az alábbi relációjelek valamelyikét használjuk

< , > , <= , >=

és a vizsgált operandus értéke null, akkor vizsgálatkor  hibát kapunk, rosszabb esetben a hibától újraindulhat az IIS.

Ez a működés szándékos, ezeket az eseteket a fejlesztőnek külön kezelni kell. Mivel az AND kapcsolatú kifejezések kiértékelése hasonló egyéb alacsonyabb szintű nyelvekéhez, ezért, ha már egy korábbi feltétel nem teljesül, akkor nem kell kiértékelni az utána következőket, hiszen azoktól már független a kifejezés értéke.

Példa a helyes megadásra:

op1 != null

(and)

op1 >= 10

Megjegyzés.: OR kapcsolatú condition esetén a relációjellel vizsgált részt ki kell emelnünk egy külső conditionben és ott a fenti módon AND kapcsolattal ellenőrizni, hogy null -e az értéke.

 A rendszerünk nehezen viseli azokat az eseteket, amikor egy tárolt eljárást hívunk meg, de előtte nem inicializáltuk (gyk.: nem használtuk) az spnek átadott paramétert. Amennyiben ezt hanyagságból tettük, sajnos kénytelenek vagyunk pótolni az inicializálást. Direkt esetekben azonban használhatjuk a default paraméter értéket.

CREATE PROCEDURE Schema1.SPname1

@par1 nvarchar(50) = NULL

AS

...

Találtam egy remek, példákkal illusztrált tőzsdei gyorstalpalót a Budapest Értéktőzsde (BÉT) oldalán, ami segít megérteni néhány fogalmat és az összefüggéseket.

Az alábbi fogalmakat emelném ki a projekt szempontjából:

• Határidős ügyletek (származékos piaci ismeretek)
• Opciós ügyletek (származékos piaci ismeretek)
• Különböző hedge típusok (árupiaci ismeretek)

http://bet.hu/topmenu/befektetok/tozsde_lepesrol_lepesre

A float típus létezik SQL-ben is és C#-ban is, de nagyon különböző a jelentésük. Az SQL float kb. 15 tizedesjegy pontosságú, a c# float csak kb. 7, és ez sok művelethez nem elég. A float típusú sql mezőknek c#-ban a double felel meg.

Ne használjatok C# float típust mappingben se és változótípusnak se, mert nem elég pontos!

 Főbb lebegőpontos típusok SQL-ben (sok alias név van):

• Real <http://msdn.microsoft.com/en-us/library/ms173773.aspx> , 4 byte, 7 értékes jegy, max kitevő: 38 (ne használjátok, nem elég pontos)
• Float <http://msdn.microsoft.com/en-us/library/ms173773.aspx> , 8 byte, 15 értékes jegy, max kitevő: 308 (legtöbb művelethez elég jó)
• Decimal(p, s) <http://msdn.microsoft.com/en-us/library/ms187746.aspx> , változó méretű, fix számú egész és tizedes jeggyel

Vigyázzatok a decimal típus használatakor, mert mindig fix számú tizedes jegyet kezel, ha nincs megadva (s), akkor nullának veszi és egészre kerekíti a tárolt értékeket. Legtöbbször decimal(18,3) formában szoktuk használni az ubm adatbázisban (jelentése: 15 jegyű egészrész, háromszámjegyű törtrész).

 Lebegőpontos típusok c#-ban:

• float <http://msdn.microsoft.com/en-us/library/b1e65aza.aspx> , 4 byte, 7 értékes jegy, max kitevő: 38 (ne használjátok, nem elég pontos)
• double <http://msdn.microsoft.com/en-us/library/678hzkk9.aspx> , 8 byte, 15 értékes jegy, max kitevő: 308
• decimal <http://msdn.microsoft.com/en-us/library/364x0z75.aspx> , 16 byte, 28 értékes jegy, max kitevő: 28

Mivel üzleti alkalmazásokban legtöbbször az értékes jegyek száma a szűk keresztmetszet és nem a kitevő mérete, ezért a decimal típust szokás preferálni, azonban bonyolítja a helyzetet, hogy nincs egyértelmű megfelelője SQL-ben.

A double c# típusnak szinte egyértelműen megfelel a float sql típus, ez szinte minden feladathoz elég.

Egy korábban létrehozott mezőt akartam computed mezővé módosítani mssqlben. Ehhez először el kell dobni a mezőt, majd újra létrehozni computedként (ALTER COLUMN nem tudja ezt). A mező eldobásakor tapasztaltam, hogy nem engedi, mert egy Default constraint hivatkozik rá és ami még nagyobb baj hogy a constraint nevét (DF__Megrendel__Onall__7879E76E) az sql server generálta. Ez akkor fordul elő tipikusan, amikor így hozunk létre egy mezőt:

ALTER TABLE [tableName]
ADD [columnName] bit DEFAULT 0 
GO

Ekkor nem adunk meg a DEFAULT constraintnek nevet, ezért egy random nevet kap (Ez igaz a primary key, foreign key rövidített megadására is). A fő probléma a random névvel az, hogy különböző futáskor különböző neve lesz ugyanannak a constraintnek. Így különbözni fog a development rendszerben, az acceptanceben és productionben is. A javasolt megoldás, hogy még létrehozáskor explicit módon nevet adunk a constrainteknek:ALTER TABLE [tableName] 
ADD [columnName] bit CONSTRAINT [DF_MYCONSTRAINT] DEFAULT 0 
GO 

--idegen kulcs hivatkozás estében: 

ALTER TABLE [tableName] 

ADD [columnName] int CONSTRAINT [FK_TABLENAME_REFERENCEDTABLENAME] FOREIGN KEY REFERENCES [referencedTableName]
GO

Azonban, ha már létrejött a random nevű megszorítás, akkor valahogy le kell vennünk a mezőről (el kell dobnunk). Végül ezt a megoldást használtam a helyzetre:

DECLARE @sqlexec varchar(max)

SELECT top 1 @sqlexec = 'ALTER TABLE dbo.tablename DROP CONSTRAINT ' + so.name
FROM sysobjects so
JOIN sysconstraints sc ON so.id = sc.constid
JOIN sysobjects soparent on soparent.id = so.parent_obj
WHERE so.xtype = 'D' and soparent.name = 'tablename'
AND sc.colid = 
(SELECT colid FROM syscolumns WHERE id = object_id('schema.tablename') AND name = 'columnname')

EXEC(@sqlexec)go