dotNETportal.cz

Jak sehrát 2 SQL databáze?

Musíte být konkrétnější

Dělám program na sledování povinných zdravotních prohlídek, nebude nijak propojený s ofic. personálním SW. Občas bude třeba z ofic. SW přihrát nové zaměstnce do mého programu resp. zrušit odchozí. Čili jakási synchronizace ...

Trochu nevíte o čem mluvíte.Na tohle je replikace DB naprosto zbytečná věc.

Pokud jen potřebujete občas ofic.SW přidat/odebrat pár dat,tak stačí jedna DB (sdílená)

Nevolil bych spojení typu "nevíte o čem mluvíte", dokud nemáte dostatek informací. Většinou totiž nic není černobílé a nutnost druhé databáze může být opodstatněná. Navíc, kdyby tazatel vědět, jak problém vyřešit, tak se na něj neptá.

Pokud existuje databáze nějakého produktu, ze které chce tazatel synchronizovat seznam zaměstnanců do své databáze, tak na tom není vůbec nic špatného. Já osobně bych to řešil SQL Jobem nebo nějakou naplánovanou úlohou, která jednoduchým dotazem přečte data z jedné databáze a nahraje je do druhé. Vše udělat tedy manuálně.

V tom případě ano..ze zadání jsem to ale pochopil tak,že tazatel chce mít dvě totožné DB,v takovém případě nevidím důvod...Pokud budou strukturově obě DB odlišné,tak pak určitě SQL Job(agent) či jiná scheduled úloha.

Je to přesně tak jak píšete: druhá databáze je nutná, protože nemohu zasahovat do ofic. SW (sdílet DB), který si i dodavatelská firma sama přes VPN servisuje.

Ze zálohy jejich DB bych občas potřeboval aktualizovat moji DB, po stránce nových zaměstnanců, resp. zrušených.

Moje DB bude využívat jen zlomek položek Date Type ze zdrojové DB.

No popravdě toto není důvod natož omluva...pokud je jejich DB "uzavřená",tedy,nemáte přístup k tomu,abyste nějaká data četl či měnil,tak nevidím důvod proč neudělat v dané DB view,přes které budete moci číst.

Ať už je to pohled nebo obyčejný dotaz, preferuji data přečíst a zapsat do nové DB. Občas je nutná transformace dat nebo různé vyjímky. Navíc se zbavujete přímé závislosti na druhé DB, která se může měnit v rámci aktualizací. Pokud by totiž byla její struktura změněna, takto jen upravíte ten script pro import dat a není potřeba promítnout změny v pohledu hlouběji do cílové aplikace.

Možná to možné je..já jsem z praxe zvyklí na databáze o velikostí desítek GB(ne-li TB) a s těmi pracovat jako se soubory(přenášet,restore,atd) by bylo dost krokolomné.Navíc dělat podobné nesystémové "obezličky" považuji vždy za mínus než přínos...Ale jak řikám,soudím tak dle toho,že pracuji ve velkých prostředích(tisíce uživtelů,PC,reportingové databáze,..)

Také pracuji s databázemi o velikosti několika kB až několika TB. A co se týká uživatelů, tady se pohybujeme v rámci desítek milionů ;-). Ale na každý problém je vhodné jiné řešení. A synchronizace uživatelů z nějakého komerčního systému (mzdový, personalistika, docházka...) jsem téměř vždy nakonec provedl jako "export > transformace > import do cílového systému". Snižuje se závislost na druhém systému a v naprosté většině případů je to dostačující řešení. Záleží na požadavcích na aplikaci.

A když už jste to nakousnul, tak si neodpustím jednu poznámku. Zrovna přenášení a restore velkých databází je někdy jediné řešení, jak provádět náročnější analytické operace bez ovlivnění produkčních prostředí :) - například cache, zámky, úpravy dat atp.

Určitě máte pravdu... vždy záleží na daném řešení,prostředí,atd.

Vzhledem k tomu,by bylo vhodné kdyby tazatel více popsal vše potřebné a dle toho se dále navrhlo řešení.

Jinak jsem ten restore nemyslel ani tak složitý po stránce času,sys.prostředků atd,ale spíše co se týče přenositelnosti.