Új hozzászólás

Szia Tamás, Az időzónát is tartalmazó adattípusok (pl datetimeoffset az SQL Server esetén) használatát tudatosan kerüljük az adattárház építések során. Ennek okai a következők: 1) Az adattárházakban mesterséges kulcsokat használunk a dátum, idő és egyéb adattípusok helyett. Nem használunk se datetime, se datetime2 se datetimeoffset és egyéb dátum/idő típusú adattípus. Ez nem az adatbázis-kezelő korlátja, hanem tudatos tervezési döntés. (A miértekről itt olvashatsz: https://www.biprojekt.hu/blog/Miert-hasznaljunk-mesterseges-kulcsot-az-ido-dimenziaban.htm) 2) Az adattárházakat, illetve pontosítok: a csillagsémás adattárházakat (amelyekről e blogban olvashatsz) nem a helytakarékosságra, hanem az egyszerű lekérdezhetőségre tervezzük. Sok információt redundánsan tárolunk, csak azért, hogy az üzleti felhasználók munkáját könnyítsük. Ha az üzleti felhasználóknak fontos, hogy ugyanazon mutatót UTC és lokális időpont szerint is lekérdezzék, akkor előkészítjük nekik ennek lehetősét. (még akkor is, ha tudjuk, hogy egy időzónát is tároló adattípus választása esetén lekérdezhető mind az UTC, mind a lokális időpont is) 3) Az adattárházakban konform dimenziókat használunk, azaz egy vevő, termék, stb. dimenziót építünk és minden ténytáblát ezzel a közös dimenzióval dimenzionálunk. Legyen szó a teljesítési, szállítási vagy akár születési dátumról is. Ez utóbbi esetben semmilyen információval nem bírna egy döntéshozónak például a dolgozó időzóna szerint bontott születési dátuma. Márpedig ha a konform idődimenziónk tartalmazná az időzónát is, akkor ezt a születési dátumnál is figyelembe kéne vennünk. Összefoglalva: Az időzónát is tartalmazó dátum/idő adattípus kerülése az adattárházakban nem az adatbázis-kezelő korlátokból ered, hanem tudatos tervezési döntés eredménye. Üdv, Attila