24 Ocak 2014 Cuma

MSSQL Replication

Sql Server aşağıdaki üç tip çoğaltmayı destekliyor:
  • · Transactional replication
  • · Merge replication
  • · Snapshot replication

Ana veritabanına Publisher, dağıtılacak veritabanlarına ise Subscriber diyoruz.

Transactional replication
Bu çoğaltma yöntemi veritabanındaki objelerin ve dataların snapshot’ının (birebir görüntüsünün) alınmasıyla başlıyor. Snapshot alındıktan sonra Publisher veritabanında oluşan data değişiklikleri ya da şema değişiklikleri anında (çok kısa bir gecikmeyle) Subscriber veritabanına dağıtılıyor. Publisher veritabanında oluşan data değişiklikleri Subscriber veritabanına aynı sırayla ve aynı transaction’larla dağıtıldığı için transaction tutarlılığı garanti ediliyor.

Bu replication yöntemini kullanmak aşağıdaki senaryolar için kullanışlı:
. Publisher veritabanında oluşan değişikliklerin yapıldığı haliyle Subscriber veritabanında olmasını istiyorsanız
. Publisher veritabanı ile Subscriber veritabanı arasındaki farkın minimum olmasını istiyorsanız
. Örneğin bir satır beş defa değiştiyse, son halinin değil de tüm 5 değişikliğin de sırasıyla Subscriber veritabanında oluşmasını istiyorsanız
. Publisher veritabanı yüksek insert, update ve delete hareketlerine sahipse
. Publisher ya da Subscriber veritabanı MsSql değilse

Default olarak, Subscriber veritabanı read-only olmalıdır çünkü Subscriber veritabanında yapılan değişiklikler Publisher veritabanına uygulanmaz ama Subscriber veritabanının update edilebilmesini sağlayan bir seçenek de mevcuttur.


Merge replication
Merge replication da transactional replication gibi Publisher veritabanının snapshotını alarak başlar. Daha sonra Publisher ve Subscriber’da oluşan değişiklikler triggerlar yardımıyla takip edilir. Subscriber network’e bağlandığı an Publisher ve Subscriber arasındaki tüm değişiklikler birleştirilir.

Merge replication aşağıdaki durumlar için uygun:
. Bir veyahut daha çok Subscriber aynı datayı değişik zamanlarda değiştirip, Publisher’a ve diğer Subscriber’lara dağıtmasını istiyorsanız
. Subscriberların datayı alıp üzerinde offline olarak çalışıp daha sonra senkronize etmesini istiyorsanız
. Her Subscriber’ın datanın değişik kısımlarına ihtiyacı varsa
. Çakışmalar olabileceği için, bunları farkedip çözebilmelisiniz
. Kullandığınız uygulamalar en son değişikliği istiyorsa, örneğin bir satır beş defa değiştiyse, beş değişikliği değil de en son halini istiyorsa

Merge replication birden çok uygulamanızın birbirinden bağımsız olarak çalışıp daha sonra bu bilgileri birleştirmek için kullanabileceğiniz bir yöntemdir.


Snapshot replication
Bu replication yöntemi güncellemeleri takip etmeden belirtilen zamanda tüm datayı birebir kopyalarak Subscriber veritabanını günceller.

Aşağıdaki durumlar için kullanılabilir:
. Datalar nadir olarak değişiyorsa
. Subscriber veritabanındaki dataların biraz eski olması kabul edilebilirse
. Varolan datanın küçük bir kısmı dağıtılıyorsa
. Varolan datanın büyük bir kısmı kısa bir aralıkta değişiyorsa
Transactional
Merge
Snapshot




TypeScript

Aslında daha çok DART'a benziyor ama arasındaki farkı Anders Hejlsberg şöyle açıklamış:

DART, tamamen Javascript'i yeniliyor. Yeni bir programlama dili ve yeni bir sanal makine. Kodunuzu Javascript'e çevirebiliyorsunuz fakat bunu yaparken yeni bir dilin semantiğini alıp Javascript'e benzetmeye çalışıyor. Script# aynı şeyi C# için, Google Web Toolkit ise JAVA için yapıyor. Bunu yaptıkları için karışıklığa ve maliyete sebep oluyorlar.

TypeScript ise herşeyden önce aslında Javascript, yeni bir dil öğrenmenize gerek yok, sadece parametrelerinize açıklamaları nasıl koyacağınızı öğrenmeniz yeterli ve bu o kadar da zor değil. İkinci ve asıl önemlisi öğrendiğiniz bu yeni şeyler ECMAScript 6 ile uyumlu (Javascript'in bir sonraki sürümü). Yani aslında TypeScript öğrenirken, Javascript öğreniyorsunuz. Ayrıca tüm diğer Javascript frameworklerini bu dille rahatlıkla kullanabilirsiniz.

Bu arada TypeScript açık kaynak kodlu bir proje.
http://typescript.codeplex.com

Açıklamanın tam metni:
http://www.eweek.com/developer/microsoft-delivers-typescript-a-better-javascript-for-big-apps/

REST vs SOAP

Bu iki teknolojinin en temel farklılıkları SOAP’ın veri isteklerini HTTP data kısmında halletmesi. RESTful web servislerinde ise istekler  HTTP header kısmında halledilir. Bunu sağlamak için HTTP protokolunde bulunan POST,PUT,GET,DELETE parametreleri kullanır.  Bu da RESTful web servislerinin en önemli özelliğidir.
Genel olarak farkları ;
·         REST daha az trafik harcar, Platform ve dil (java ile .net haberleşebilir)  bağımsızdır.
·         Veriler REST’te işlenmeden de okunabilirliği yüksek olur.
·         SOAP ‘ta WSDL’den otomatik proxy class oluşturulup , client uygulamaya kolay entegre edilebilir.
·         REST’te client uygulamaya entegre etmek için proxy class yazılması gerekir.
·         SOAP tip korumalıdır. SOAP headerda belirtilen şekilde veri gelir.
·         REST’da veri tanımlaması yoktur.
·         SOAP alt yapısında xml kullanır(JSON veri gömülebilir).
·         REST verileri xml veya JSON olarak gönderebilir.
·         REST, veritabanına uzaktan erişim gibi çalışır. SOAP ise uzaktan metot çağırma(RPC) ilkesine dayanır.
·         REST’i uygulamak için url etkin şekilde kullanılır ve url tasarımı yapılması gerekir.
·         SOAP’ta ise uzaktan metot çağrıma tekniği kullanılır.

REST
SOAP
Dönüş değerini belirleyebildiğimiz için, bu değer çok küçük boyutta olabilir.
Dönüş değeri XML tipinde olduğu için boyutu daha büyük.
Client tarafında cache'lenebilir.
Cient tarafında cache özelliği yok.
Twitter, Facebook ve Google REST kullanıyor.
Google 2006'dan sonra kullanmaktan vazgeçmiş.
Uygulaması ve öğrenmesi çok kolay.
Standartlarını öğrenmesi zor.
Stateless olduğu için scale etmesi kolay.
Scale etmesi zor.
Her MIME tipinde dönüş yapabilir.
Sadece XML döner.
Mobile playformlar için iOS ve Android tarafından destekleniyor.
Mobile platformlarda tüm özellikleriyle desteklenmiyor.
Async desteği yok.
Async desteği var.
Session desteği yok.
Session desteği var.
Standart mesajlaşma sistemi içermediğinden dolayı iletişim hatalarında zorluk çıkarabilir.
Standart mesajlaşma sistemi olduğundan otomatik olarak başarısız bir isteği tekrar deneyebilir.
Kullanıcı doğrulama sistemi zahmetli.
Session desteğiyle birlikte, daha kolay bir kullanıcı doğrulama sistemi var.
Kısıtlı kaynak ve hızlı kod geliştirme için uygun.
Yüksek güvenlik ve büyük data transferleri için uygun.
 

Sql Server Üzerindeki Tüm Veritabanlarında Sorgu Çalıştırmak

Aşağıdaki örnek size yardımcı olacaktır.
Kolay gelsin.

CREATE TABLE ##tempTable
(
      DatabaseName VARCHAR(64),
      ObjectName VARCHAR(128),
      ObjectKind VARCHAR(128)
)
 
EXEC sp_Msforeachdb "USE [?];
      INSERT ##tempTable (DatabaseName, ObjectName, ObjectKind)
      SELECT db_name(), t1.name, t1.xtype
      FROM sysobjects t1"
 
SELECT  *
FROM    ##tempTable
 
DROP TABLE ##tempTable

Angular.js için Ücretsiz Kaynak

AngularJS'ye başlangıç yapmak için güzel bir ücretsiz kaynak: http://www.egghead.io

CLR Fonksiyon DLL'leri Nerede Tutulur?

CLR DLL'ler Sql Server'a yüklendikten sonra dosya olarak değil, veritabanı içerisinde bir obje olarak tutulduğundan dolayı sadece yükleme aşamasında Sql Server'ın görebileceği bir yerde durması yeterli, daha sonra kendisini silebilirsiniz.

Kaynaklar:
CLR in a cluster is no different than in a stand-alone instance. When you create a CLR object in SQL Server, it's in the DB - not the file system. The dll's for CLR assemblies in SQL Server are not loaded from the file-system, but from the database itself.
http://dbaspot.com/ms-sqlserver/218767-implementing-clr-cluster-print.html

When using CLR the placement of the dll is only important while loading the CLR assembly. Once this hace succesfully done you can remove the dll. So even on a cluster it makes no difference if you use a local drive or one of the shared cluster drives.
http://www.sqlservercentral.com/Forums/Topic395782-386-1.aspx#bm395787

VideoConverter.js

Ffmpeg kütüphanesini Javascript'e çevirip, video çevirme ve kesme işlerini javascript ile halletmişler. Enteresan bir proje.

http://github.com/bgrins/videoconverter.js