data.hr

SQL Server Bootcamp and the new BOL release

dvitner — Sun, 05 Oct 2008 07:07:00 GMT

My friend Marko Čulo and I delivered the "SQL Server bootcamp" training in Varaždin MIC last week. Those "bootcamp" trainings are always special, I enjoy them very much. In the near future, I plan to do one more 5-days training at...(read more)

Sinergija 2008 and DevReach 2008

dvitner — Tue, 26 Aug 2008 18:04:00 GMT

Today I got an email from Vladimir Knezevic from MS Serbia that my “Microsoft SQL Server 2008 Data Auditing” presentation was accepted at this year's Sinergija conference . It's a great news, I'm so thrilled to be given the opportunity to...(read more)

SQL Server 2008 RTM'd

dvitner — Wed, 06 Aug 2008 18:39:00 GMT

About 9:30 PST SQL Server 2008 RTM'd. It's available for download from MSDN and TechNet. I'm dowloading it already :) http://msdn.microsoft.com/subscriptions/downloads/default.aspx http://technet.microsoft.com/subscriptions/downloads/default...(read more)

CodeCamp.BG

dvitner — Fri, 04 Jul 2008 13:11:00 GMT

Thanks to my good friend Martin Kulov, who invited me, and to Microsoft Bulgaria, who will cover my expences, I'm going to appear at the CodeCamp.BG next weekend. I will be doing my ever-changing and ever-improving "Data Auditing in SQL Server...(read more)

Our Lady of the Lake

dvitner — Mon, 23 Jun 2008 18:24:00 GMT

OK, so the Kulendayz ( http://kulendayz.mscommunity.net ) are over.. I still don't quite believe it, though. It was so intense period -- preparing the event and actually making it happen -- that now I feel kinda empty. It was the best conference ever...(read more)

DLinqy-thingy, Part One

dvitner — Thu, 21 Feb 2008 18:06:00 GMT

At last, I found some spare time to start playing with that Linq2SQL thing. Installed VS2008 RTM. fired it up, created a new C# console project, added a reference to System.Data.Linq, created the appropriate .dbml to Northwind database, and typed in the...(read more)

I unikifikacija ima granice..

dvitner — Tue, 12 Feb 2008 19:21:00 GMT

OK, long time no see.. :)) Svi znamo da mozemo kreirati clustered indeks (CI) na (skoro) bilo kojem subsetu kolona iz tablice. Također, svi znamo da možemo kreirati nonclustered indekse (NCI) na (skoro) bilo kojem subsetu kolona iz tablice, manje-više...(read more)

Lublana ma živalski vrt

dvitner — Fri, 19 Oct 2007 18:57:00 GMT

U srijedu sam bio u Ljubljani, kao gost predavač na sastanku slovenačke UG. Prvi slot sam popunio ja, s SQL Server Mythbusting, drugi slot je odradio domaći SQL Server MVP Dejan Sarka s Database Design Myths. Sve u svemu, jako, jako prijatno iskustvo...(read more)

Myths&legends

dvitner — Mon, 24 Sep 2007 19:17:00 GMT

Mitovi i legende (o SQL Serveru, ne o kralju Arturu) su izgleda popularna tema ovih dana. Na privatnoj MVP news grupi je nedavno bio jedan prilično opsežan thread o njima. Maciej Pilecki je upravo danas popodne radio Myths&legends workshop ovdje u...(read more)

Kriza identiteta

dvitner — Mon, 17 Sep 2007 19:23:00 GMT

Je, znam da sam rekao kako ću ovdje pričati o Katmai-ju i uzbudljivim još-uvijek-novim stvarima u Yukon-u.. Budem. Idući put :) Danas, nešto što mi se mota po glavi zadnjih par dana. Stara i otrcana tema, možda, ali nažalost izgleda još uvijek aktualna.

Prije nekog vremena, na Mobility Day (koji je BTW po meni sasvim uspio kao konfa, svaka čast organizatorima i predavačima!) sjedio sam na predavanju na kojem je predavač, pored još nekih "bisera" koje sad neću spominjati, ničim izazvan ustvrdio kako je ustvari dobra ideja postaviti GUID kao primary key ako se tablica ima namjeru koristiti u replikaciji. Hm..

Pukom slučajnošću, dan-dva iza toga, na hr.comp.programiranje.baze -- prilično divlje zna biti tamo ponekad, ali moj samaritanski duh se hrani pomažući ljudima gdje god -- u jednom odgovoru sam onako u prolazu savjetovao OP-u da ne koristi IDENTITY za primary key. I u tren oka par ljudi je skočilo s pitanjem "pa zašto sad to?". Hmm..

Da stvar bude još gora, jedan učesnik u threadu je, valjda iz želje da pojasni stvari, postao link na članak Kimberly Tripp o clustered indeksima. Hmmm..

OK, čemu dakle taj hm-hmm-hmmm od mene? Zaista, zašto ne koristiti autogenerated vrijednosti (kao što su IDENTITY i GUID) za primary key na tablici? Odakle pomutnja? Pokušat ću jednostavnim jezikom, i uglavnom o IDENTITY-ju, njega se puno više zloupotrebljava.

Prvi i osnovni razlog je taj što ključevi (primarni, sekundarni, kandidati, kojigod) stvar logičkog dizajna baze podataka, i tiču se samo integriteta podataka. Osnovna zadaća ključeva je da se pomoću njih može jednoznačno identificirati neki red. IDENTITY i GUID su implementacijski detalj u SQL Serveru -- oni ne postoje u realnom svijetu, nisu dio poslovne domene, nemaju ama baš nikakve veze s podacima, njihova vrijednost nije poznata do trenutka nakon što su podaci već upisani, korisniku ne znače ništa i ne može ih koristiti u upitima, GUID pored toga i nije nešto što želite ukucati preko tipkovnice, etc. Očito je da oni ne ispunjavaju onu maloprijespomenutu osnovnu zadaću - da identificiraju red u tablici.

Tu se javlja i par sasvim praktičnih problema. Prvi je taj da, kako sam već rekao, vrijednost IDENTITY kolone nije poznata prije nego što smo podatke upisali u bazu. Uzmimo za primjer onaj čuveni sa SalesOrderHeader i SalesOrderDetail tablicama iz AdventureWorks sample baze (usputbudirečeno, ta baza je više primjer kako NE dizajnirati bazu, nego obrnuto.. no dobro). Imamo SalesOrderID kolonu s dignutim IDENTITY property-jem kao PK na SalesOrderHeader tablici, i postavljen FK constraint sa SalesOrderDetail na SalesOrderHeader preko SalesOrderID kolone. Što radimo kad želimo upisati novi order, i header i details? Nešto ovakvo:

INSERT Sales.SalesOrderHeader (<columns>) VALES (<values>);
SET @SalesOrderID = SCOPE_IDENTITY();
INSERT Sales.SalesOrderDetail (SalesOrderID, <other_columns>) VALUES (@ID, <other_values>);
INSERT Sales.SalesOrderDetail (SalesOrderID, <other_columns>) VALUES (@ID, <other_values>);

Sve pet ako je samo jedan order u pitanju. A što ako želimo odjednom upisati nekoliko ordera? Npr:

INSERT Sales.SalesOrderHeader (<columns>) SELECT (<columns>) FROM OverseasSales.SalesOrderHeader WHERE <filter>;
INSERT Sales.SalesOrderDetail (SalesOrderID, <other_columns>) SELECT ???

Ako i uspijete saznati novogenerirane vrijednosti za SalesOrderID (hint: OUTPUT), kako ćete ih logički povezati s onim izvornima? OK, mi smo kreativni ljudi i smislit ćemo već nešto..

Nadalje, IDENTITY ne mora nužno biti unique (IDENTITY_INSERT, recimo). Bad.

Za identične podatke -- ako ih upisujemo u dva navrata -- možemo dobiti (ne samo da možemo, nego ćemo i dobiti) dvije različite vrijednosti u IDENTITY koloni. Isto je i ako upisujemo identične podatke u dvije različite baze. Pa onda poslije imamo problema s konsolidacijom (i trošimo novce na skupa MDM rješenja).

Vrijednost IDENTITY-ja se generira neovisno o transakciji. Npr:

SET NOCOUNT ON;
GO

USE tempdb;
GO

CREATE TABLE tbl (c1 int IDENTITY(1,1), c2 varchar(10));
GO

INSERT tbl VALUES ('qwerty');

BEGIN TRAN;

INSERT tbl VALUES ('asdfgh');

SELECT * FROM tbl;

ROLLBACK;

INSERT tbl VALUES ('asdfgh');

SELECT * FROM tbl;

DROP TABLE tbl;

c1          c2
----------- ----------
1           qwerty
2           asdfgh

c1          c2
----------- ----------
1           qwerty
3           asdfgh

Za drugi red ('asdfgh') smo prvo dobili vrijednost c1 kolone 2, a nakon ROLLBACK-a pri ponovnom upisu smo dobili 3. Plus toga, imamo i gap (hrvatski: rupu) u redoslijedu, što može i ne mora biti bitno.

A GUID.. Ajd, sad barem imamo NEWSEQUENTIALID(). I da, istina, morate imati uniqueidentifier kolonu da biste replicirali tablicu. Svejedno, ni to nije razlog da je proglasite za primary key :)

A što nam je htio reći onaj kolega s početka priče, kad nas je naputio da pročitamo članak o clustered indeksima s bloga Kimberly Tripp? To je jedan od onih "mitova i legendi" o kojima će, pretpostavljam, pričati Marko na bootcampu ovaj mjesec. Radi se naime o tome da su primary key i unique constrainti u SQL Serveru podržani preko (unique) indeksa. Što je sasvim OK. Ono što nije OK je to da će, ako eksplicitno ne kažete drugačije, SQL Server primary key podržati s clustered indeksom. A to nije OK iz najmanje dva razloga. Prvo, to stvara konfuziju kod ljudi, i prečesto se te dvije stvari poistovjećuju, iako se ustvari radi o dvije različite stvari -- jedno je integrity constraint, a drugo implementacija, tj kako je taj constraint realiziran -- pa se onda često priča o jednom, a misli se na drugo. Zatim, clustered indeks je jedna prilično važna alatka iz arsenala perf tuninga. Postavljanjem clustered indeksa na ovoj ili onoj koloni možemo nekad ubrzati određenu vrstu upita, recimo range query-je (ordered scan). Ne, ovime nisam želio reći da ćemo ako želimo ubrzati range upite obavezno postaviti CI na kolonu po kojoj je definiran range. Ovisi. Na koju kolonu ćemo postaviti clustered indeks, ili ga nećemo postaviti uopće, ovisi o podacima i njihovom korištenju, ali želimo li doista odreći se te mogućnosti?

Nakon svega ovoga -- ipak, IDENTITY uopće nije tako loš, ali važno je znati što nije i koja su ograničenja. Nekad je dapače i koristan -- može se postaviti unique constraint na njega i raditi DRI, pa čak i clustered indeks se može postaviti na njega. Ako imate razloga za to. Sve ovisi :)

Puno više o svemu ovome ćemo pričati na bootcampu u Varaždinu. Kog zanima, dobrodošao je. Early bird i dodatni popust za community još uvijek se mogu iskoristiti.

Pozdrav, čujemo se.

Dean

Please allow me..

dvitner — Fri, 07 Sep 2007 20:22:00 GMT

Što nam donosi SQL Server 2008 (FKA Katmai)? To je jedna od tema kojima ćemo se baviti ovdje u narednim postovima. Budite sigurni, nećemo samo nabrajati i ilustrirati nove feature-s -- kao i uvijek od mene, ovdje mozete očekivati i kritičke osvrte i osobna mišljenja.

Za početak, ustvari i prije početka, jedan generalni stav -- Katmai ne donosi ništa tako revolucionarno novo kao što je donijela 2005-ica. Nema velikih arhitektonskih promjena, kao što su u Yukonu primjerice bili CLRSQL, XML podrška, ili (najvažnija stvar IMHO) copy-on-write i row versioning. Ono što Katmai donosi, to bi se prije moglo reći da su stvari koje nisu uspjele ući u Yukon timeframe (DATE i TIME tipovi, npr, ali "done right this time"), ili se svode na poliranje postojećih funkcionalnosti (kao recimo unaprijeđenja na DB mirroring-u). Naravno, ima i par zgodnih sasvim novih stvari. Ali, o tome ćemo kasnije.

Yukon je još uvijek, čak i za mnoge MVP-jeve, "nova" verzija sikvela, nešto što se na mnogim mjestima tek uvodi u poslovanje ili se uvođenje tek priprema. Mnoge stvari koje imamo u Yukonu zato su još nedovoljno poznate ili nedovoljno korištene. Te "nove" stvari, njihovo korištenje u praksi, do's and don'ts, best practices i perf implikacije, bit će druga velika tema narednih postova.

Pored ovog dvoga, koristit ću ovaj prostor i za najavu nekih kako svojih osobnih tako i community akcija.

Za početak, volio bih vas sve pozvati na Vladanov codecamp 19-og (http://codecamp.mscommunity.net/). Ne znam koliko sad i ovdje smijem reći o samom eventu, jer agenda još nije službeno objavljena, ali već sada je jasno da će to biti najjači skup kvalitetnih i zanimljivih predavača iz (ne samo HR!) MS community-ja okupljenih na jednom mjestu -- ikada.

Odmah nakon toga, prvi tjedan u listopadu, Marko i ja radimo "second edition" SQL Server botcampa u MSPTC u Varaždinu (http://www.mscommunity.net/Default.aspx?tabid=1103). Ako ne znate što je "bootcamp", samo tri riječi: krv, suze i znoj. Prijavite se, dodjite, nećete požaliti.

A sredinom listopada, Marko i ja idemo u radni posjet Dejanu i Mihi u Ljubljanu, na sastanak SLO UG. Sunčana strana Alpa :)

Pozdrav, čujemo se.

Dean