Oracle'dan SQL Server'a ve SQL Server'dan Oracle'a Geçiş Kılavuzu - Pt. 3

Bu dizinin birinci ve ikinci bölümleri, işlemlerin uygulanmasında Oracle Veritabanı ve Microsoft SQL Server arasındaki farkları ve sonuçta ortaya çıkan dönüştürme tuzaklarını ve ayrıca yaygın olarak kullanılan bazı sözdizimi öğelerini tartıştı.

Bu son bölüm, Oracle okuma tutarlılığı kavramını ve bu kavrama dayalı mimarinin bir Microsoft SQL Server sürümüne nasıl dönüştürüleceğini kapsayacaktır. Aynı zamanda, eşanlamlıların kullanımına (ve bunların nasıl KULLANILMAMASINA) ve veri tabanı ortamınızı yönetmede değişiklik-kontrol sürecinin rolüne değinecektir.

Oracle Okuma Tutarlılığı ve SQL Server'daki Eşdeğeri

Oracle okuma tutarlılığı, tek bir SQL deyimi tarafından döndürülen tüm verilerin zaman içinde aynı tekil noktadan geldiğinin garantisidir.

Bunun anlamı, 12:01:02.345'te bir SELECT ifadesi yayınladıysanız ve sonuç kümesini döndürmeden önce 5 dakika boyunca çalıştıysa, 12:01:02.345 itibariyle veritabanında taahhüt edilen tüm veriler (ve yalnızca veriler) bunu yapacaktır. dönüş setinize. Veri tabanınızın ekstrenizi işlemesi için geçen 5 dakika boyunca iade setinize herhangi bir yeni veri eklenmeyecek veya herhangi bir güncelleme yapılmayacak ve hiçbir silme görünmeyecektir.

Oracle mimarisi, verilerdeki her değişikliği dahili olarak zaman damgalayarak ve iki kaynaktan bir sonuç seti oluşturarak okuma tutarlılığı sağlar: kalıcı veri dosyaları ve bir geri alma segmenti (veya sürüm 10g'ye kadar bilindiği gibi “geri alma segmenti”).

Bunu desteklemek için geri alma bilgisi korunmalıdır. Üzerine yazılırsa, kötü şöhretli ORA-01555: snapshot too old hatasıyla sonuçlanır.

Segment yönetimini geri almayı ve ORA-01555: snapshot too old hatasında nasıl gezinileceğini bir kenara bırakarak, Oracle'daki herhangi bir pratik uygulamada okuma tutarlılığının etkilerine bakalım. Ayrıca, PostgreSQL'in olası ve nitelikli istisnası dışında, diğer RDBMS uygulamalarında olduğu gibi bunu desteklemeyen SQL Server'da nasıl yansıtılmalıdır?

Anahtar, Oracle'ın okuma ve yazma işlemlerinin birbirini engellememesidir. Ayrıca, uzun süredir devam eden sorgu dönüş kümenizin en son verilere sahip olmayabileceği anlamına gelir.

Okuma ve yazmaları engellemeyen, Oracle'ın sahip olduğu bir avantajdır ve işlem kapsamını etkiler.

Ancak okuma tutarlılığı, verilerin en son durumuna sahip olmadığınız anlamına da gelir. Bazı senaryolarda tamamen iyi olduğunda (belirli bir zaman için bir rapor hazırlamak gibi), diğerlerinde önemli sorunlar yaratabilir.

En son, hatta "kirli" veya taahhüt edilmemiş verilere sahip olmamak kritik olabilir: Klasik senaryo, bir otel odası rezervasyon sistemidir.

Aşağıdaki kullanım durumunu göz önünde bulundurun: Aynı anda oda rezervasyonu siparişlerini kabul eden iki müşteri hizmetleri temsilciniz var. Odaların çifte rezerve edilmemesini nasıl sağlayabilirsiniz?

SQL Server'da, açık bir işlem başlatabilir ve mevcut odaların listesinden (bir tablo veya görünüm olabilir) bir kayıt SELECT . Bu işlem ( COMMIT veya ROLLBACK tarafından) kapatılmadığı sürece, seçtiğiniz oda kaydını kimse alamaz. Bu, çifte rezervasyonu önler, ancak aynı zamanda diğer tüm acentelerin sırayla rezervasyon isteklerini birer birer tamamlamasını beklemesine neden olur.

Oracle'da, arama kriterlerinize uyan kayıtlara karşı bir SELECT ... FOR UPDATE ifadesi yayınlayarak aynı sonucu elde edebilirsiniz.

Not: Erişimi körü körüne kilitlemek yerine, bir odayı "değerlendirilmekte" olarak gösteren geçici bir bayrak ayarlamak gibi daha iyi çözümler mevcuttur. Ancak bunlar mimari çözümler, dil seçenekleri değil.

Sonuç : Oracle okuma tutarlılığı "tamamen iyi" veya "tamamen kötü" değil, platformun iyi anlaşılması gereken ve platformlar arası kod geçişi için kritik olan önemli bir özelliğidir.

Oracle ve Microsoft SQL Server'da Genel (ve Özel) Eşanlamlılar

"Genel eşanlamlılar kötüdür." Bu tam olarak benim kişisel keşfim değil, ama günüm, haftam ve yılım genel eş anlamlı kelimelerle kurtarılana kadar onu müjde olarak kabul etmiştim.

Pek çok veritabanı ortamında - birlikte çalışma şansına sahip olduğum, ancak tasarlamadığım tüm Oracle ortamlarında - her nesne için CREATE PUBLIC SYNONYM kullanmak rutindi çünkü "biz bunu hep böyle yaptık".

Bu ortamlarda, genel eşanlamlıların yalnızca bir işlevi vardı: sahibini belirtmeden bir nesneye başvuruya izin vermek. Ve bu, halka açık eşanlamlılar yapmak için kötü düşünülmüş bir nedendir.

Bununla birlikte, Oracle genel eşanlamlıları son derece yararlı olabilir ve doğru bir şekilde ve bir nedenle uygulanırsa ve yönetilirse, tüm dezavantajlarından önemli ölçüde daha ağır basan ekip üretkenliği faydaları sağlayabilir. Evet, “ekip üretkenliği” dedim. Ama nasıl? Bunun için Oracle'da isim çözümlemenin nasıl çalıştığını anlamamız gerekiyor.

Oracle ayrıştırıcı bir ad (ayrılmamış bir anahtar sözcük) bulduğunda, onu aşağıdaki sırayla mevcut bir veritabanı nesnesiyle eşleştirmeye çalışır:

Not: Ortaya çıkan hata ORA-00942: table or view does not exist veya PLS-00201: identifier 'my_object' must be declared .

Bu ad çözümleme sıralamasında, bir geliştirici kendi şemasında çalışırken, genel eşanlamlı olarak aynı ada sahip herhangi bir yerel nesnenin bu genel eşanlamlıyı gizleyeceğini görmek kolaydır. (Not: Oracle 18c, "salt oturum açma" şema türünü uygulamıştır ve bu tartışma bunun için geçerli değildir.)

Ölçeklendirme Takımları için Genel Eşanlamlılar: Oracle Change Control

Şimdi aynı veritabanı üzerinde çalışan 100 geliştiriciden oluşan varsayımsal bir ekibe bakalım (ki bu benim deneyimlediğim bir şey). Ayrıca, hepsinin kendi kişisel iş istasyonlarında yerel olarak çalıştıklarını ve bağımsız olarak, tümü aynı veritabanı geliştirme ortamına bağlı olarak veritabanı dışı derlemeler yaptıklarını varsayalım. Veritabanı olmayan kodda (C#, Java, C++, Python veya başka bir şey olsun) birleştirme kodunun çözümü, değişiklik denetimi check-in zamanında yapılacak ve bir sonraki kod oluşturma ile yürürlüğe girecek. Ancak, devam eden geliştirme sırasında veritabanı tabloları, kod ve verilerin birden çok kez değiştirilmesi gerekir. Her geliştirici bunu bağımsız olarak yapar ve hemen yürürlüğe girer.

Bunun için tüm veritabanı nesneleri ortak bir uygulama şemasında oluşturulur. Bu, uygulamanın başvurduğu şemadır. Her geliştirici:

• Kişisel kullanıcı hesabı/şeması ile veritabanına bağlanır
• Her zaman boş bir kişisel şema ile başlar
• Ortak şemaya yalnızca ad çözümlemesi yoluyla yukarıda açıklandığı gibi genel bir eşanlamlıya başvurur

Bir geliştiricinin veritabanında herhangi bir değişiklik yapması gerektiğinde (bir tablo oluşturması veya değiştirmesi, prosedür kodunu değiştirmesi, hatta bazı test senaryolarını desteklemek için bir veri setini değiştirmesi) kişisel şemalarında nesnenin bir kopyasını oluştururlar. Bunu DESCRIBE komutunu kullanarak DDL kodunu alıp yerel olarak çalıştırarak yaparlar.

Bu andan itibaren, bu geliştiricinin kodu, nesnenin ve verinin yerel sürümünü görecek ve bu sürüm başka kimse tarafından görülmeyecek (veya üzerinde bir etkisi olmayacak) olacaktır. Geliştirme tamamlandıktan sonra, değiştirilen veritabanı kodu kaynak denetimine alınır ve çakışmalar çözülür. Ardından, son kod (ve gerekirse veriler) ortak şemada uygulanır.

Bundan sonra, tüm geliştirme ekibi aynı veritabanını tekrar görebilir. Kodu yeni teslim eden geliştirici, tüm nesneleri kişisel şemasından düşürür ve yeni bir görev için hazırdır.

Birden çok geliştirici için bu bağımsız paralel çalışmayı kolaylaştırma yeteneği, genel eşanlamlıların ana yararıdır - abartması zor bir önem. Ancak pratikte, ekiplerin Oracle uygulamalarında "her zaman yaptığımız için" genel eş anlamlılar oluşturduğunu görmeye devam ediyorum. Buna karşılık, SQL Server kullanan ekiplerde, ortak bir uygulama olarak kurulan ortak eşanlamlıların oluşturulmasını görmüyorum. İşlevsellik mevcuttur, ancak sık kullanılmaz.

SQL Server'da, bir kullanıcı için geçerli varsayılan şema, kullanıcı yapılandırmasında tanımlanır ve "kullanıcıyı değiştirme" ayrıcalıklarına sahipseniz herhangi bir zamanda değiştirilebilir. Oracle için yukarıda açıklananla aynı metodoloji uygulanabilir. Ancak bu yöntem kullanılmazsa, genel eş anlamlılar kopyalanmamalıdır.

Microsoft SQL Server, varsayılan olarak (Oracle'ın yaptığı gibi) yeni bir kullanıcı hesabını kendi şemasıyla ilişkilendirmediğinden, ilişkilendirme, standart "kullanıcı oluştur" komut dosyanızın bir parçası olmalıdır.

Aşağıda, özel kullanıcı şemaları oluşturan ve bir kullanıcıya atayan bir komut dosyası örneği verilmiştir.

İlk olarak, DevelopmentDatabase adlı veritabanına katılması gereken yeni kullanıcılar için şemalar oluşturun (her şema kendi toplu işinde oluşturulmalıdır):

 use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

İkinci olarak, atanmış varsayılan şemasıyla ilk kullanıcıyı oluşturun:

 CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

Bu noktada Dev1 kullanıcısı için varsayılan şema Dev1 olacaktır.

Ardından, varsayılan şema olmadan diğer kullanıcıyı oluşturun:

 CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

Dev2 kullanıcısı için varsayılan dbo Dev2 .

Şimdi varsayılan şemasını Dev2 olarak değiştirmek için Dev2 kullanıcısını değiştirin:

 ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

Artık Dev2 Dev2

Bu komut dosyası, Microsoft SQL Server veritabanlarında bir kullanıcı için varsayılan bir şema atamanın ve değiştirmenin iki yolunu gösterir. SQL Server, birden çok kullanıcı kimlik doğrulama yöntemini desteklediğinden (en yaygın olanı Windows kimlik doğrulamasıdır) ve kullanıcı katılımı DBA'lar yerine sistem yöneticileri tarafından gerçekleştirilebildiğinden, ALTER USER varsayılan şema atama/değiştirme yöntemi daha kullanışlı olacaktır.

Not: Şemanın adını bir kullanıcının adıyla aynı yaptım. SQL Server'da bu şekilde olmak zorunda değil, ama benim tercihim çünkü (1) Oracle'da nasıl yapıldığına uyuyor ve (2) kullanıcı yönetimini basitleştiriyor (bir DBA'nın doğru yapmaya yönelik en büyük itirazını ele alıyor) ilk olarak)—bir kullanıcının adını bilirsiniz ve otomatik olarak kullanıcının varsayılan şemasını bilirsiniz.

Sonuç : Genel eş anlamlılar, istikrarlı ve iyi korunan çok kullanıcılı bir geliştirme ortamı oluşturmak için önemli bir araçtır. Ne yazık ki, sektördeki gözlemlerime göre, daha sık yanlış nedenlerle kullanılıyor; ekiplerin, faydalarını fark etmeden karışıklık ve genel eş anlamlıların diğer olumsuz taraflarından muzdarip olmalarına neden oluyor. Bu uygulamayı herkese açık eşanlamlılardan gerçek faydalar elde edecek şekilde değiştirmek, bir ekibin geliştirme iş akışına gerçek faydalar sağlayabilir.

Veritabanı Erişim Yönetimi ve Değişiklik Yönetimi Süreçleri

Az önce büyük ekipler tarafından paralel geliştirme desteğinden bahsettiğimiz için, ayrı ve sıklıkla yanlış anlaşılan bir konuya değinmeye değer: değişim-kontrol süreçleri.

Değişim yönetimi genellikle ekip liderleri ve DBA'lar tarafından kontrol edilen, “dün” değilse de “şimdi” de olsa her şeyi teslim etmek isteyen asi geliştiriciler tarafından hor görülen bir bürokrasi biçimi haline gelir.

Bir DBA olarak, "benim" veri tabanıma her zaman koruyucu engeller koyarım. Bunun için çok iyi bir nedenim var: Veritabanı, paylaşılan bir kaynaktır.

Cıvıldamak

Kaynak denetimi bağlamında, bir ekibin yeni ancak bozuk koddan eski ancak çalışan koda dönmesine izin verdiği için değişiklik yönetimi genellikle kabul edilir. Ancak bir veritabanı bağlamında, değişiklik yönetimi DBA'lar tarafından yerleştirilen bir dizi mantıksız engel ve kısıtlama gibi görünebilir: Geliştirmeyi gereksiz yere yavaşlatan saf çılgınlık!

Bu geliştiricinin lafını bir kenara bırakalım: Ben bir DBA'yım ve kendime taş atmayacağım! Bir DBA olarak, "benim" veri tabanıma giden yolda her zaman koruyucu engeller koyarım. Bunun için çok iyi bir nedenim var: Veritabanı, paylaşılan bir kaynaktır.

Her geliştirme ekibinin ve geliştiricilerinin her birinin çok özel olarak tanımlanmış bir hedefi ve çok özel bir çıktısı vardır. Her gün bir DBA'nın masasında olan tek amaç, paylaşılan bir kaynak olarak veritabanının kararlılığıdır. Bir DBA, bir kuruluşta tüm ekipler arasındaki tüm geliştirme çabalarını denetlemek ve tüm geliştiricilerin eriştiği bir veritabanını kontrol etmek için benzersiz bir role sahiptir. Tüm projelerin ve tüm süreçlerin birbirine müdahale etmeden çalışmasını ve her birinin çalışması için gereken kaynaklara sahip olmasını sağlayan DBA'dır.

Sorun, hem geliştirme hem de DBA ekiplerinin kendi fildişi kulelerinde kilitli kalmasıdır.

Geliştiriciler bilmiyorlar, erişimleri yok ve onlar için iyi çalıştığı sürece veritabanında ne olduğu umurlarında bile değil. (Bu onların teslimatı değildir ve performans değerlendirmelerini etkilemez.)

DBA ekibi, veritabanını kasaya yakın tutar ve bu konuda "hiçbir şey bilmeyen" geliştiricilerden korur, çünkü ekiplerin hedefi veritabanı kararlılığıdır. Ve istikrarı sağlamanın en iyi yolu, yıkıcı değişiklikleri önlemektir; bu genellikle veritabanını herhangi bir değişiklikten mümkün olduğunca koruma tutumuyla sonuçlanır.

Bir veritabanına yönelik bu çelişkili tutumlar, gördüğüm gibi, geliştirme ve DBA ekipleri arasında düşmanlığa yol açabilir ve çalışamaz bir ortamla sonuçlanabilir. Ancak DBA'lar ve geliştirme ekibi ortak bir hedefe ulaşmak için birlikte çalışmalıdır: onları bir araya getiren şey olan bir iş çözümü sunmak.

Geliştirici-DBA ayrımının her iki tarafında da bulunduktan sonra, DBA'lar geliştirme ekiplerinin ortak görevlerini ve hedeflerini daha iyi anladığında sorunun çözülmesinin kolay olduğunu biliyorum. Geliştiricilerin, bir veritabanını soyut bir kavram olarak değil, paylaşılan bir kaynak olarak görmeleri gerekir ve orada bir DBA, bir eğitimci rolünü üstlenmelidir.

Geliştirici olmayan DBA'ların yaptığı en yaygın hata, geliştiricinin veri sözlüğüne ve kod optimizasyon araçlarına erişimini kısıtlamaktır. Oracle DBA_ katalog görünümlerine, dinamik V$ görünümlerine ve SYS tablolarına erişim, aslında bunlar kritik geliştirme araçları olsa da birçok DBA'ya “DBA ayrıcalıklı” gibi görünmektedir.

Aynısı SQL Server için de geçerlidir, bir komplikasyonla: Bazı sistem görünümlerine doğrudan erişim verilemez, ancak bu sadece SYSADMIN veritabanı rolünün bir parçasıdır ve bu rol asla DBA ekibinin dışında verilmemelidir. Bu, SYSADMIN ayrıcalıkları altında yürütülen ancak DBA dışındaki kullanıcılar tarafından erişilebilen görünümler ve saklı prosedürler oluşturarak çözülebilir (ve bir projenin Oracle'dan SQL Server'a geçişi durumunda çözülmelidir). Bu, yeni bir SQL Server geliştirme ortamı olarak yapılandırılmış olarak DBA'nın geliştirme işidir.

Veri koruma, bir DBA'nın ana sorumluluklarından biridir. Buna rağmen, geliştirme ekiplerinin verilerle ilgili bilet sorun giderme işlemlerine izin vermek için filtrelenmemiş üretim verilerine tam erişime sahip olması oldukça yaygındır. Bunlar, veri yapısına (ilk etapta onlar tarafından veya onlar için oluşturulmuş yapı) sınırlı erişime sahip geliştiricilerin aynısıdır.

Geliştirme ve DBA ekipleri arasında uygun çalışma ilişkileri kurulduğunda, iyi bir değişiklik kontrol sürecinin oluşturulması sezgisel hale gelir. Veritabanı tarafı değişiklik yönetiminin özellikleri ve zorluğu, aynı zamanda bir veritabanının katılığı ve akışkanlığıdır - yapı katıdır, veriler akışkandır.

Veri değişikliklerinin değişiklik yönetimi yolunda çok az veya hiç olmamasına rağmen, yapı değişikliğinde (yani veri tanımlama dilinde veya DDL'de) değişiklik yönetiminin iyi kurulmuş olduğu sıklıkla görülür. Gerekçe basittir - veriler her zaman değişir.

Ancak buna daha yakından bakarsak, herhangi bir sistemde tüm verilerin iki kategoriden birine girdiğini görürüz: uygulama verileri ve kullanıcı verileri.

Uygulama verileri , bir uygulamanın davranışını tanımlayan ve süreçleri için herhangi bir uygulama kodu kadar kritik olan bir veri sözlüğüdür. Bu verilerde yapılan değişiklikler, diğer tüm uygulama değişikliklerinde olduğu gibi, sıkı değişiklik kontrol süreçleri altında olmalıdır. Uygulama verileri değişiklikleri için değişiklik kontrol sürecinde şeffaflık yaratmak amacıyla, uygulama verileri ve kullanıcı verileri açıkça ayrılmalıdır.

Oracle'da uygulama ve kullanıcı verilerinin her biri kendi şemasına yerleştirilerek yapılmalıdır. Microsoft SQL Server'da her biri ayrı bir şemaya veya - çok daha iyisi - ayrı bir veritabanına yerleştirilerek yapılmalıdır. Bu seçimleri yapmak geçiş planlamasının bir parçası olmalıdır: Oracle iki seviyeli isim çözümlemesine (şema/sahip – nesne adı) sahipken SQL Server üç seviyeli isim çözümlemesine (veritabanı – şema/sahip – nesne adı) sahiptir.

Uygulama ve kullanıcı verilerinin doğru şekilde ayrılması, bir DBA ekibinin ikinci en önemli endişesini ele almasına olanak tanır: kullanıcı verilerinin güvenliği. Kullanıcı verileri ayrı olarak bulunduğundan, gerektiğinde kullanıcı verilerine erişim için cam kırma prosedürünü uygulamak çok kolay olacaktır.

Sonuç : Değişiklik kontrol süreçleri herhangi bir projede kritik öneme sahiptir. Yazılım mühendisliğinde, verinin "fazla akıcı" olduğu görüldüğünden, veritabanı tarafındaki değişiklik yönetimi genellikle ihmal edilir. Ancak bunun nedeni tam olarak verilerin "akışkan" ve aynı zamanda "kalıcı" olması, iyi tasarlanmış bir değişiklik kontrol sürecinin uygun veritabanı ortamı mimarisinin temel taşı olması gerektiğidir.

Kod Taşıma Araçlarının Kullanımı Hakkında

Standart birinci taraf araçlar, Oracle Migration Workbench ve SQL Server Migration Assistant, kod geçişlerinde yardımcı olabilir. Ancak dikkate alınması gereken şey 80/20 kuralıdır: Kod %80 doğru bir şekilde taşındığında, kalan %20'yi çözmek, taşıma çabanızın %80'ini alacaktır.

Taşıma araçlarının kullanımındaki en büyük risk, açık ara "gümüş kurşun" algısıdır. Kişi, “İşi yapacak ve benim biraz temizlik ve toplama yapmam gerekecek” diye düşünmeye cazip gelebilir. Dönüşüm ekibinin ve teknik liderliğinin bu tutumu nedeniyle başarısız olan bir proje gözlemledim.

Öte yandan, ana düzenleme aracı olarak Notepad++'ın toplu değiştirme işlevini kullanarak orta büyüklükte bir Microsoft SQL Server 2008 sisteminin (yaklaşık 200 nesne) temel dönüşümünü gerçekleştirmem dört iş günümü aldı.

Şimdiye kadar ele aldığım kritik geçiş öğelerinin hiçbiri, geçiş araçlarıyla çözülemez.

Elbette, geçiş yardımı araçlarını kullanın, ancak bunların yalnızca düzenleme yardımı sağladığını unutmayın. Ortaya çıkan çıktı metninin, üretime uygun kod haline gelmesi için gözden geçirilmesi, değiştirilmesi ve bazı durumlarda yeniden yazılması gerekir.

Yapay zeka araçlarının geliştirilmesi, gelecekte bu geçiş aracı eksikliklerini giderebilir, ancak veritabanları arasındaki farklılıkların o zamandan önce bulanıklaşacağını ve herhangi bir geçiş sürecinin gereksiz hale geleceğini umuyorum. Dolayısıyla, bu tür projelere ihtiyaç duyulduğu sürece, bunu eski moda insan zekasını kullanarak eski yöntemle yapmamız gerekecek.

Sonuç : Göç yardımı araçlarını kullanmak faydalıdır, ancak bu bir “gümüş kurşun” değildir ve herhangi bir dönüştürme projesi yine de yukarıdaki noktaların ayrıntılı bir incelemesini gerektirir.

Oracle/SQL Server Migrations: Daima Yakından Bakın

Oracle ve Microsoft SQL Server, kurumsal ortamda en çok çoğalan iki RDBMS platformudur. Her ikisi de ANSI SQL standardı ile temel uyumluluğa sahiptir ve küçük kod bölümleri çok az değişiklikle, hatta olduğu gibi taşınabilir.

Bu benzerlik, iki platform arasında geçişin basit ve anlaşılır bir görev olduğu ve aynı uygulamanın bir RDBMS arka ucundan diğerine kolayca uyarlanabileceği konusunda aldatıcı bir izlenim yaratıyor.

Uygulamada, bu tür platform geçişleri önemsiz olmaktan uzaktır ve her platformun iç işleyişinin ince öğelerini ve hepsinden önemlisi, veri yönetiminin en kritik öğesi olan işlemler için desteği uygulama biçimini hesaba katmak zorundadır.

Uzmanlığımın merkezinde yer alan iki RDBMS platformunu ele almış olsam da, aynı uyarı—"benzer görünüyor, aynı şekilde çalıştığı anlamına gelmez"—diğer SQL uyumlu veritabanı yönetim sistemleri arasında kod taşımak için uygulanmalıdır. Ve her durumda, ilk dikkat edilmesi gereken nokta, işlem yönetiminin uygulanmasının kaynak ve hedef platformlar arasında nasıl farklılık gösterdiği üzerine olmalıdır.