Popis konvencí názvů

Konvence při tvorbě databáze na SQL serverech

26.5.2020 by Antonín Měchura 25.11.2008 Edit - Stanislav Nikodem, pridané indexy, tabuľky a logika tvorby prefixov Názvové konvence databázových objektů

Důležité: Názvy polí a především klíčů je nutné držet v logice. Je nepřípustné když se klíč v číselníku jmenuje UserId a v relační tabulce OperatorId. Stejně tak pozor na PartNo, ProductNo, ProductId atd.

Názvy tabulek jsou tvořeny s důrazem na rychlé dohledání logiky a relací mezi tabulkami. Takže název nejprve vyjadřuje předmět a relaci. Je možno používat malé i velké písmena. Mezi slovy oddělovač podtržítko. Používá se jednotné číslo v názvech objektů. Je dovoleno a doporučováno použít prefix před názvem. Měl by co nejvíce vyjadřovat společnou logickou strukturu objektů. Opět je oddělen podtržítkem. Například t_ je použito pro obecně číselníky v aplikaci. Stejně lze vytvořit prefix např. pr_ značí proces. Pro logické celky jsou doporučeny max. 2 písmenné prefixy. Primárně používáme v názvech především angličtinu. Prefixy tabulek Pro seskupení a odlišení významu zavádíme prefixy pro tabulky. Prefix je písmenko nebo několik písmenek před vlastním názvem tabulky oddělený podtržítkem. Prefix malými písmeny! Prefix Typ tabulky Příklad t Všeobecný číselník t_Place s Systémové tabulky a číselníky s_Messages dev Tabulky pro developers dev_Descriptions

Příklad: Faktura hlavičky Invoice Faktura položky Invoice_item Číselník uživatelů t_user

Názvy pohledů

Jsou odvozeny od názvu tabulky nebo tabulek, které spojuje. Opět je použita logika pro logické skupiny objektů a oddělení slov podtržítkem. Je možné seskupovat objekty pomocí prefixů max. 3 znakových. Není přípustné používat prefix na konci. Prefixy sa logicky odvodzujú od objektu alebo akcie ku ktorým prislúchajú(napr. objekty logovania budú mať prefix log.) tak aby bolo ľahké ich dohľadanie. např:
název_pohledu_v : správně je vf_faktury_polozky.

Pokud pohled spojuje více tabulek tvoří se název ze spojení obou tabulek tak aby byl co nejvíce pochopitelný pro ostatní tvůrce. Příklad: Relační spojení Objednavka a zákazník: pr_OrderCustomer : prodej Objednavky a zákazníci.

Názvy polí:

Názvy klíčů

Pro číslovaný IDENTITY klíč se používá název OID. OID je vždy typu bigint. Pro nečíslovaný primární klíč se používá CID. Je typu VARCHAR Pro jednoznačný ale neprimární hodnotu v databázi – uživatelský kód se používá NazevCD. Zkratka CD = CODE Pro pole, které se využívá pro uložení Barcode se používá zkratka NazevBD . Zkratka BD jako Barcode.

Pro cizí klíč se použije název TabulkaID === v tabulce je primární klič název OID

Pomenovanie poľa je jednotné pre celý projekt.

Příklad:

Tabulka faktury. OID, VarSym, DT …. CustomerID, OrderId V názvu cizího klíče je povoleno zkrátit název tabulky ale jen tak aby byl pochopitelný. Např. CustomerId nebo CustId. Názov cudzieho kľúča je vo všetkých objektoch rovnaký a jeho názov je určený tabuľkou na konci tohto dokumentu.

Povolené zkratky v názvech polí. Zkratky používat přednostně na konci. DE Description Part_DE, Order_DE FG FLAG Bit pole pro stav, JeHotovo_FG NM Name Jméno, popis Item_NM, NO Note Poznámky,
DT Date DT, Send_DT

Maximální délka názvu pole je 18 znaků

Uložené procedury a funkcí:

Pro názvy je použita stejná logika v názvech s prefixem pro tvorbu logických skupin objektů. Název procedury je tvořen co nejvíce s ohledem na to, co procedura dělá. Mělo by být zřejmé s kterým objektem a co dělá.

Příklady:
x_process_start, x_proces_end, usp_UserSave asp_TableNazevInsert usp_PartUpdateStatus usp_PartDeleteItem usp_PartInsert

Rezervované prefixy uložených procedur:

rg_ ROUTING Uložené procedury routingu sg_ xTraceSG Používa xTraceSg Core a_ SECURITY Security modul wp_ WorkPlace Pro práci s WorkPlace chk_ CHECK Všechny procedury funkce, které ověřují (routing, quality, atd)

Spouště, trigery

Prefix vyjadřuje činnost, pro kterou je triger vytvořen.

Možné použití zkratek pro databázovou činnost = Velkými písmeny Triger vždy začíná písmenem T

I INSERT Pro vkládání D DELETE Pro mazáni U UPDATE Pro změny

Příklad:

Triger pro insert TI_PartStatusUpdate , triger pro INSERT změní status v partTable pomocí update TD_PartProblemDelete triger , který po výmazu záznamu vymaže také podřízené záznamy z relační tabulky (nevhodný příklad, lépe použít ref integritu a kaskádové změny)

Rozhodování o datových typech

Doporučení: Decimal nebo Numeric? Decimal je novější. OID klíče BigInt Přednostně varchar místo nvarchar Pokud je pole znakové menší než 8 znaků doporučuje se použít CHAR (). Zryhluje hledání. Pro stavy používat TinyInt 0 až 256 znaků nebo int Bit je pro jednostavový status, Lze použít například pro IsDeleted Vyhýbáme se pokud možno text a ntext. Raději pokud se vejde do 8000 znaku tak varchar()

Další doporučení: 1. Řádky (součty délek všech polí) by měly co nejmenší 2. Pokud neznám přesnou délku pole navrhnu varchar větší a pak podle možností zmenším podle skutečných dat. 3. Trigery nejsou pro udržování datové integrity. Na to jsou relace a cizí indexy. 4. Nevytvářejte clustrované indexy na klíči s IDENTITY 5. Hodnoty NULL pokud možno zakazujeme. Používáme default hodnoty definované nad poli. 6. Pokud je v některém z polí tabulky jednoznačný údaj, nepoužijeme OID s IDENTITY. Název pak deklarujeme jako KeyID : Např: UserId 7. Pozor na maximální velikost jednoho řádku 8060 bytů. Celková délka řádku jej nesmí přesáhnout. 8. Pole text, text, image jsou uloženy mimo hlavní záznam. Proto je jakékoliv hledání, update nad těmito poli velmi náročné. Pokud možno se jim vyhneme nebo nad nimi neprogramujeme UPDATE,

Indexy Začiatok názvu indexov vždy tvorí prefix UK – pre unikátny index IX – pre ostatné typy indexov Za prefixom názov pokračuje _ + názov tabuľky + _ + Názov pola(polí). Napr. ix_Product_PartNo