Diskuze: Input parameters into stored procedure
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 9 zpráv z 9.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.
Nechci bejt rejpal, ale 50ti sloupcová tabulka? To zavání špatným návrhem...
SQL obecně nebývá nejsilnější nástroj pro práci se stringy. Na druhou
stranu by mělo být řešení takové, aby případná úprava datového modelu
znamenala co nejmenší práci.
Optimální by dle mého bylo řešení, kdy samotná procedura dostává
jednotlivé hodnoty rozdělené do parametrů, ale v aplikaci je pro volání
procedury wrapper, který dostává pole a to exploduje do jednotlivých
parametrů. V případě, že bys tabulku rozšířil o další sloupec,
stačilo by rozšířit input procedury o další parametr a následně wrapper,
aby s dalším parametrem počítal.
@Michal Štěpánek: Ani na tabulce o 300 sloupcích nevidím nic zvláštního. Viděls někdy podrobnou správu majetku?
Ano, podrobnou správu majetku jsem viděl (dokonce jsem ji i dělal), ale
rozhodně jsem k tomu nepotřeboval "tolikasloupcovou" tabulku (ani 50ti
sloupcovou). Vždycky se to dá nějak pohodlně a hlavně čitelně rozdělit
do různých (méněsloupcových) tabulek a navzájem propojit, aby se to
jednoduše udržovalo a spravovalo.
Když už jsem měl tabulku o 20ti sloupcích, přemýšlel jsem, co dělám
špatně - a přišel jsem na to...
Jistě, rozdělit vlastnosti objektu do několika tabulek, pak nad nimi udělat view, na něm instead of triggery, aby se záznam o jednom objektu pohodlně editoval, nad to nejlépe fláknout další view, kde budu mít objekt joinovaný k dodavateli, tam zase pár instead of triggerů, aby se update pěkně rozlil do tabulek, nakonec to bude všechno pekelně pomalé, ale hlavně že mám rozměry objektu v jiné tabulce, než jeho pořizovací a servisní cenu. A jako bonus si nemůžu udělat složený index, který by sahal přes dvě tabulky.
Neviem sa nikde na webe docitat nejake porovnanie ohladom toho. Skor som mal na mysli ze ak mam na vstupe procedury dajme tomu 50 parametrov a potom spravim insert into a rozpisane parametre ktore sa budu ukladat do jednotlivych stlpcov alebo bude na vstupe iba jeden parameter a to ako xml a potom insert spravim z toho xml do tabulky a to iba v pripade insertu jedneho zaznamu. Ze ktory sposob je lepsi rychlejsi a menej narocnejsi na stroj. Dakujem
Evidence produktů a služeb je poměrně komplexní věc a pokud to nemá být maximálně zjednodušené, tak se jeden objekt určitě bude rozpadat do více tabulek. Zjednodušení znamená to, že se při dalších požadavcích musí předělávat kód a přesypávat data.
Tak teď reálný příklad:
CREATE TABLE [dbo].[Object](
[Id] [int] PRIMARY KEY IDENTITY(1,1) NOT NULL,
[Code] [varchar](128) NULL,
[Name] [varchar](128) NULL,
[Abbreviation] [varchar](32) NULL,
[ParentId] [int] NULL,
[InventoryNumber] [varchar](128) NULL,
[ManufactureId] [int] NULL,
[SupplierId] [int] NULL,
[ServiceId] [int] NULL,
[ManufactureYear] [int] NULL,
[CommissioningDate] [datetime] NULL,
[ServiceContractTo] [datetime] NULL,
[BuyYear] [int] NULL,
[Warranty] [datetime] NULL,
[DecommissioningDate] [datetime] NULL,
[BuyingPrice] [money] NULL,
[ServicePrice] [money] NULL,
[TransportPrice] [money] NULL,
[Note] [varchar](max) NULL,
[CatalogNumber] [varchar](128) NULL,
[BusinessName] [varchar](128) NULL,
[SerialNumber] [varchar](128) NULL,
[StandardNameId] [int] NOT NULL,
[StateCode] [int] NOT NULL,
[TypeMarkEnum] [int] NULL,
[IsInRepair] [bit] NOT NULL,
[IsInMaintenance] [bit] NOT NULL,
[TemplateId] [int] NULL,
[BarCode] [varchar](28) NULL)
(Je to hodně vysekané z aktuálního projektu.) Kolik to je, 30
atributů?
V aplikaci je karta (detail) objektu s příslušnými kontrolkami (textboxy,
comboboxy, checkboxy...) navázanými na konkrétní sloupec datového zdroje.
Ten je selectem z této tabulky dle Id, případné další hodnoty (např.
adresa dodavatele) jsou na detailu objektu needitovatelné, proto není problém
je selectovat joinem. Výsledek:
Stojím si za tím, že to neodporuje normalizaci. Fakt by mě zajímalo, co je špatné na tomhle návrhu.
Nikdo neřekl, že to odporuje normalizaci, nebo že to musí být kategoricky špatně. Každému se může líbit něco jiného a mě vyhovuje rozdělení atributů do skupin, které spolu souvisí. I ta tvoje tabulka má cca třetinu sloupců vazby na jiné tabulky...
Zobrazeno 9 zpráv z 9.