Databáza - relácia 1:1

[Radus]

Zdravím vospolok, mám takúto dilemu: Mám rozchodenú databázu, kde mám v jednej tabuľke k užívateľovi priradené len základné údaje. Avšak, postupom času, pre inú aplikáciu ktorá bude túto databázu zdieľať, vznikla požiadavka tieto údaje o dosť rozšíriť.
Mám teda dilemu, či rozšíriť stávajucú tabuľku o ďalšie údaje (stĺpce), alebo vytvoriť ďalšiu tabuľku ktorá bude k prvej v relácii 1:1 (pomocou userId). V prvom prípade sa bojím toho, aby nedošlo k spomaleniu stávajucích aplikácii ak budú musieť pracovať s rozšírenou tabuľkou. V druhom prípade sa zase použitie relácie 1:1 v návrhu databázy všeobecne považuje za chybné...
Skôr by som však potreboval zachovať výkonnosť už stávajúcich aplikácii...
Ďakujem za rady.

[dan21]

Mozno taketo nieco ?

id - PK
user_id - FK
parameter
hodnota

je to 1:n a mozes tam mat hodnot kolko chces

[Radus]

Dobrý pokus Ale nie, takto to nechcem, to by zase zbitočne zaťažovalo databázový stroj...
//minimálne aj kvoli tomu že hodnoty budú rôzneho typu

[dan21]

To teda vysvetli ako by to zatazovalo DB stroj.
Ja pracujem na aplikacii z databazou ktora ma asi 140 tabuliek poprepajanych kade tade.
Niektore maju niekolko milionov zaznamov. Dokonca jedna mi uz zahlasila ze jej doslo cislo na ID !!

Pracuje s tym niekolko desiatok uzivatelov naraz a vsetko slape v pohode

[Radus]

Nepristupoval by som priamo k určitému stlpcu, ale DB stroj by podľa mena paramatera musel vyfiltrovať aký parameter potrebujem a akých užívateľov. Ak budem potrebovať kolekciu parametrov od špecifikých užívateľov...no, príde mi to trochu komplikovanejšie.
A ako som spomínal, je tu otázka rôznych dátových typov. Nebudem ukladať bitovú hodnotu do nejakého dlhého varcharu...
Ako v podstate máš pravdu, šlo by to. Ale mne to nejak nereže...

[pocitujlasku]

zakladna otazka: kolko je tam zaznamov a kolko uzivatelov tam pristupuje.
Ak to vsetko su max. 3miestne cisla, tak je to uplne jedno. Bezne tu mam tabulky, kde su desattisice zaznamov, su tam desiatky dotazov za sek. sialene joiny a chodi to rychlostou blesku.

[Radus]

Skôr by som chcel vedieť ako je to lepšie v takýchto situáciach riešiť, lebo už asi druhý krát stojím pred takouto dilemou.
Ale bavíme sa asi o 3tis záznamov mesačne...

[dan21]

presne tento pristup (schemu) pouzivam v aplikacii. Mam tam este dalsi stlpec v ktorom je definovany typ parametra (int, bool .......)
Kazdu noc sa tam nasype 2.3 miliona novych zaznamov, ktore uzivatelia nasledujuci den pouzivaju
Slape to ako hodinky

[Radus]

Ak tomu dobre rozumiem, máš v stlpcoch meno parametra, hodnotu parametra a typ parametra. Aké dátové typy používaš pre tieto stĺpce?

[dan21]

vsetko je nvarchar. Mam este jednu tabulku (ciselnik) kde je zoznam moznych parametrov, takze v reale pouzivam namiesto stlpca parameter iba parameter_id
Nad tym vsetkym je databazova a aplikacna logika

[Radus]

tak to už hej...

[dan21]

Je to variabilne. Pre tvoj pripad moze mat kazdy uzivatel rozny pocet extra parametrov
Niektore mozes definovat ako povinne , ....................................
vela moznosti .............

[pocitujlasku]

zalezi aj ako je napisana apka. Niektorym nevadi, ze rozsiris strukturu, proste tie ostatne stlpce ignoruju. Ine zase s tym maju problem.
Ak je to jedno, tak z pohladu db je lepsie rozsirit, ako potom davat join.
Taka MSSQL databaza si vie celkom slusne robit optimalizacie, takze vykonovo to nepocitis. Zase na druhu stranu, pokial neriesis bigdata odporuca sa rozbit na mensie. napr. adresa, zamestnavatel, zakladne udaje, doplnujuce udaje... a prepojit cez relacnu tabulku, alebo priamo cez foreign key.
To je vyhodne, ak potrebujes vyhladavat podla roznych kriterii.

dan21: tvoje riesenie je trocha zabijak vykonu. ak sa ma hladat podla hodnoty, tak nvarchar je jedno z tych horsich rieseni. Videl som aj take, kde to vsetko dali do xml a tam to bola radost vyhladavat.

[Radus]

Apka je riešená s prístupm len čisto po stĺpcoch, čiže tam by problém nebol. (Nenačítavam všetky stĺpce hromadne) Neviem, ešte si to nechám prejsť hlavou.
Snažím sa ísť hlavne po výkone, už teraz tam mám tak 12 tabuliek a všeobecne sa snažím optimalizovať kde sa dá, čo sa dá...a robiť to čo-možno najlepšie. Kto vie, možno ma to niekedy bude živiť
Mám to rozbehané na MSSQL a aplikácia v C#pe, plus nejaké procedúry v SQL...
danove riešenie je už pre mňa moc overkill...až taký dobrý zase niesom

[dan21]

pocitujlasku: samozrejme ze sa tam nedrzia nejake sialene velke hodnoty. Ci uz ciselne alebo znakove.
Konkretne toto riesenie pouziva tabulku kde je len par tisic zaznamov a na vyhladavanie pouzivam view.
Toto je jedna z najmenej vyuzivanych tabuliek v aplikacii

[pocitujlasku]

varchar pouzivame tak maximalne, ako docasne pri nejakych exportoch/importoch.
Radus: ja tiez robim v c# +mssql. Len tie moje vytvory bezia v bankovom prostredi a bezne su tam aj stovky pripojeni. Zaujimave je, ze co sa tyka db, tak ja som asi jediny, ktoreho to bavi, ostatni sa db vyhybaju ako cert krizu
Vykon v pripade par tis. zaznamov by som neriesil, interne si o vie mssql celkom fajn osefovat, mozno sa pohrat s indexami. Ale aj tam s mierou, aby sa ti nezacali lockovat tabulky.

dan21: view na vyhladavanie nie je dobre. ked pojdes trocha do hlbky, tak to funguje tak, ze si vsetko najoinuje a az potom sa filtruju zaznamy. Kdezto pri cistom selecte si vie priamo pri joinovani db odfiltrovavat zaznamy podla where podmienky.
View je dobre, ak robis reporty a vsetky veci, ktore filtrujes mas v hlavnej tabulke.

[Radus]

Mňa tiež celkom chytili databázy, celkom ma to aj baví, a celkom aj zvažujem že sa tým budem živiť, keby to tak šlo

[pocitujlasku]

Tak to ti prajem pevne nervy. Pri rieseni zaludnosti preco to nefunguje ako ma, a nakoniec zistis, ze taka mssql neriesi jednotlive zaznamy, ale blok zaznamov. Cize sa ti napr. moze stat, ze ak pracujes s jednym zaznamom v tabulke, tak +- okolo neho su tiez zamknute, aj ked s nimi aktualne nic nerobis. a take finy ako select count(*) je rychlejsi, ako select count(1) to sa tiez v zakladoch nespomina.
Ale na druhu stranu, ten pocit, ked upravis procku, ktora bezala 30 minut tak, ze ide 3 minuty je na nezaplatenie A to stacilo len poprehadzovat joiny a trocha upravit sposob ako ich spojit.

[Radus]

Paradzina.
Stále používam select count(*), aký je rozdiel v select count (1)? Ak naozaj počíta len počet riadkov v prvom stĺpci a potom počet riadkov vo všetkých stĺpcoch, potom mi príde že by malo byť rýchlejšie select count (1)...

[pocitujlasku]

vo vysledku vratia to iste, a ano, malo by to byt rychlejsie, ale predstav si to ako vezmem tabulku, vyfiltrujem, a spocitam pocet. pri 1 ale navyse z vysledku vezme len prvy stlpec a ten spocita. cize krok naviac. to su tie speciality, kedy zistis ci je niekto profik, alebo len kopirovac zo stack overflow