Řešili, několikrát. Používáme tyto tři šablony:
1. Item Extension Codes
A. Máme tabulku položek, kde jsou její základní údaje (branch plant, item number, item description, item type, gl class atd.)
B. A pak máme tabulku "Item Extension Codes", která má PK stejný jako ta první. V té máme cca 120 sloupců pojmenovaných stylem "number01, number02, date01, date02, text01,..."
C. Další tabulka je tabulka IID. Má sloupce Branch Plant, IID Key, IID Value a IID Description. Typický záznam je Branch Plant 728 (Brno), IID Key VPRODTYPE, IID Value "S2", IID Description "NHP SAS 2.5 10K"
D. A nakonec existuje tabulka "Extension Code Definition", kde je primárním klíčem Branch Plant, Item Type a FieldName. Další sloupec je Description, příznak Mandatory a IID Key. Do té se při nastavování databáze třebas napíše, že pro Branch Plant 728 (Brno) a Item Type IM (vyráběná položka) se sloupec "text05" jmenuje "Vendor Product Type", Mandatory má nastaveno na "yes" a IID klíč je "VPRODTYPE".
Celé to pak funguje tak, že založím položku v první tabulce. Do té druhé můžu ale nemusím. Pro tu druhou funguje formulář tak, že je tam tuším na třech záložkách až stovky políček. Systém sám podle tabulky z bodu D ví, které zobrazit (mají mandatory yes nebo no) a které ne (nemají záznam nebo mají mandatory disabled). Z tabulky D pak i nastaví správný popisek daného pole. Takže pro každý typ položky (nakupovaná, vyráběná, polotovar, fiktivní atd.) se zobrazí jen ta pole, která sleduji. Tabulka C se pak používá na kontrolu zadaných hodnot - pokud tabulka D specifikuje nějaký klíč, tak se zaprvé uživateli nabízí seznam hodnot a zadruhé se ověřuje, že vybral některou z nich.
Přidat nový atribut je pak o tom najít si pro danou pobočku a typ položky dosud nepoužité pole a udělat pro něj záznam do tabulky D.
2. Item Cross References
A. Máme tabulku položek, kde jsou její základní údaje (branch plant, item number, item description, item type, gl class atd.)
B. Mámě tabulku Item Cross Reference Type. Primární klíč je XType. Jediný další je sloupeček Description. Hodnoty typu VP = Vendor Part Number, EM = Customer Model Number atd.
C. A finálně tabulka Item Cross Reference, kde primární klíč je Item Number, Address Number a XType.
Do tabulky A se vkládají položky. Ke každé je pak možné do tabulky C přiřadit další údaje. Tím, že je v tabulce C v primárním klíči i Address Number, tak můžete mít jeden údaj (například Customer Part Number) pro různé address booky jiný. Address Book je typicky ID zákazníka, ID dodavatele, ID nákupčího apod. Takže když někomu dodáte svou položku 3731052, tak mu můžete na dodací list napsat číslo, jaké chce on. Což je docela běžné, že stálí zákazníci chtějí objednávat podle jejich čísla položky. A pokud jednu položku dodáváte více zákazníkům, tak se vám tahle vlastnost tabulky C dost hodí.
3. Kaskáda tabulek
A. Máme základní tabulku, například Transaction. Primární klíč ID transakce. Další sloupce typu datum transakce, účetní datum, typ transakce, celková částka atd.
B. K ní máme další tabulku, například InventoryTransaction. Primární klíč je stále to samé ID transakce a má FK na tabulku Transaction. Přidává další sloupce typu Item Number, Quantity, Unit of Measure, Branch Plant atd.
C. A máme i jinou tabulku, například PaymentTransaction. Primární klíč stále to samé ID transakce a opět FK na Transaction. Přidává sloupce typu VAT Code, Net Amount, atd.
D. A ještě jiná tabulka pro EventTransaction. Klíč stále stejný a opět FK na Transaction. Navíc sloupce jako EventId, EntryType, AuthorizationMethod atd.
Každá transakce je pak v tabulce A s tím, že dodatečné údaje má v některé z dalších tabulek podle typu transakce. Tohle se používá ve chvíli, kdy mám několik typů daného objektu, které ale znám už ve fázi návrhu. Výhoda je v tom, že všechny sloupce můžete hezky navázat přes foreign key a obecně se s tím dělá trochu lépe.
--- Co vybrat ---
Metoda 1 je docela snadná na implementaci a dělá se k ní i hezké uživatelské rozhraní. Dobře se pro to píší sestavy. Blbě se s tím ale dělá cokoliv obecného. Do té míry, že vám sestava pro Brno nebude fungovat v Ploveru, protože tam mají stejný údaj v jiném sloupci, protože ten původní už roky používali pro jiného zákazníka.
Metoda 2 má výhodu v tom, že k jedné položce nejen že máte libovolný počet dodatečných údajů, ale dokonce pro každého zákazníka/dodavatele jinou hodnotu. Hůř se proto ale dělá uživatelské rozhraní - zaprvé nevíte který z definovaných 84 typů Cross Reference máte nabídnout, zadruhé z toho hezké okénko neuděláte už proto, že dopředu nevíte pro kolik různých zákazníků uživatel bude chtít vyplnit End Customer Model Number.
Metoda 3 je velmi jednoduchá na implementaci. Vše je předem dáno a vy si můžete snadno vytvářet formuláře, sestavy, integritní omezení apod. Nevýhoda je v tom, že za běhu už nic nezměníte. A skrytá nevýhoda je v tom, že se vám v průběhu let začnou vývojáři v té kaskádě tabulek ztrácet a budou mít tendenci to lepit novými tabulkami.
Všechny mají výhodu v tom, že máte jednu tabulku A, kde máte definované všechny položky/transakce apod. Základ formuláře nebo sestavy tedy má jediný zdroj, jedinou tabulku. Stejně tak tabulky typu kusovník se budou odkazovat přes FK právě do tabulky A. Jediné, co si pak musíte dolepit jinak, jsou dodatečné informace.