Nové výhodné předplatné namísto kreditů je tu! Více informací. Upravili jsme také naše provozní podmínky.
NOVINKA: Staň se datovým analytikem a získej jistotu práce, lepší plat a nové kariérní možnosti. Více informací:
Avatar
Tayson
Člen
Avatar
Tayson:28.2.2018 13:27

Ahojte,
mam tabulku ktora ma asi 50 stlpcov a nad nou napisanu storovanu proceduru ktora uklada do tejto tabulky hodnoty. Tym padom je aj na vstup procedury 50 vstupnych premennych. Moja otazka sa tyka performance. Je lepsie ked to uklam tak ze na vstup tej storovanej procedury budem naplnat 50 parametrov alebo si to na strane aplikacie dam do formatu xml a ako jeden vstupny parameter do storovanej procedury ? ci pri ukladani to nema nejaky vpliv na performance ?

 
Odpovědět
28.2.2018 13:27
Avatar
Michal Štěpánek
Člen
Avatar
Odpovídá na Tayson
Michal Štěpánek:28.2.2018 14:47

Nechci bejt rejpal, ale 50ti sloupcová tabulka? To zavání špatným návrhem...

Nahoru Odpovědět
28.2.2018 14:47
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Ondřej Crha
Člen
Avatar
Odpovídá na Tayson
Ondřej Crha:1.3.2018 15:32

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?

 
Nahoru Odpovědět
1.3.2018 15:32
Avatar
Michal Štěpánek
Člen
Avatar
Odpovídá na Ondřej Crha
Michal Štěpánek:1.3.2018 16:18

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...

Editováno
Nahoru Odpovědět
1.3.2018 16:18
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Ondřej Crha
Člen
Avatar
Odpovídá na Michal Štěpánek
Ondřej Crha:1.3.2018 16:28

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.

 
Nahoru Odpovědět
1.3.2018 16:28
Avatar
Tayson
Člen
Avatar
Tayson:2.3.2018 10:11

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

 
Nahoru Odpovědět
2.3.2018 10:11
Avatar
plelovsky
Člen
Avatar
Odpovídá na Ondřej Crha
plelovsky:2.3.2018 10:46

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.

 
Nahoru Odpovědět
2.3.2018 10:46
Avatar
Ondřej Crha
Člen
Avatar
Odpovídá na plelovsky
Ondřej Crha:2.3.2018 11:32

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:

  • Uživatel může jednoduše editovat všechny atributy objektu
  • Vývojáři stačí funkce, která posbírá kontrolky, na kterých se prováděla změna (protože všechny jsou naskládané v jedné tabulce), a vytvořit jednoduchý update nad hlavní tabulkou datového zdroje
  • Databázista může reagovat na požadavky uživatele, že seznam objektů omezený na Dodavatele, Servisní organizaci a příznak Je v opravě je pomalý (složený index nad třemi sloupci tabulky)
  • V případě rozšíření tabulky o další atributy je záležitost implementátora upravit datový zdroj a vynést další kontrolku, vývojář akorát houpe nohama

Stojím si za tím, že to neodporuje normalizaci. Fakt by mě zajímalo, co je špatné na tomhle návrhu.

 
Nahoru Odpovědět
2.3.2018 11:32
Avatar
Michal Štěpánek
Člen
Avatar
Odpovídá na Ondřej Crha
Michal Štěpánek:2.3.2018 13:47

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...

Nahoru Odpovědět
2.3.2018 13:47
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 9 zpráv z 9.