DBA'lar nasıl daha 'programcı dostu' olabilir?

Yanıtlar ve yorumlar dba.se sürümü ve programmers.se sürümü sorununun "karşı veya veritabanı katmanında uygulama mantığını koymak için argümanlar nelerdir?" Bazı işyerlerinde DBA'lar ve programcılar arasındaki ayrımı çok açıklamaktadır.

DBA'lar, programcılarla bu gibi konularda daha iyi çalışmak için ne yapabilir?

Yapmalı mıyız:

• Programcılarımızın özellikle iyi tasarlanmış veritabanlarıyla çalışırken karşılaştıkları güçlükleri anlamak için kullandıkları araçları ve dilleri öğrenin.
• Programcıların veritabanları ve iş mantığının veritabanı düzeyinde olmasının avantajları konusunda daha iyi eğitilmelerini teşvik etmek?
• Daha programcı dostu işlemsel API'ler kullanmak gibi (örneğin geriye dönük uyumluluk gibi sorunlar için) verilerimizle arayüzleri tanımlama biçimimizi değiştirin.

Bir Programcı açısından, en çok istediğimiz şeyin veri katmanının nasıl tasarlanıp oluşturulacağına ilişkin tutarlı, iyi tanımlanmış ve uygulanmış standartlar olduğunu söyleyebilirim. Sanal alanınızda istediğiniz gibi oynamaya hazırım, sadece ne istediğinizi söylemelisiniz ve kuralları her zaman değiştirmemelisiniz. Süperprogrammergod bile herkes için aynı şekilde uygulanmalıdır. Onun için istisnalar yaparsanız, o zaman benim desteklememi ve değiştirmemi, ancak benim için işe yaramaz doğru şekilde yeniden uygulamamı istiyorsunuz.

Ve lütfen bana böyle yapma ve gitme deme. Bana ne istediğini ve neden daha iyi olduğunu göstermek için benimle çalış. Eğer anlarsam her zaman uyurum. Bunu anlamadığımda uymak daha zor. DBA olmak istemiyorum. Programlamayı çok seviyorum İşinizi istemiyorum ve eğer iyi bir DBA iseniz o zaman en büyük hayranınız olacağım.

6.5 senedir MySQL DBA'yım. Ayrıca 16 yıl boyunca geliştirici olarak da çalıştım ve birçok DBA ile etkileşim içinde bulundum. Birçoğu pragmatik. Bazıları iğrenç. Birkaçının DBA olmasının ne demek olduğu hakkında hiçbir fikri yok.

Bu sonuca geldim:

Teknik olarak konuşursak, aşağıdaki özelliklerden bir veya daha fazlasına sahip olan DBA'lar çalışmak için en iyisidir:

1. Geliştiricilerin kendisi olarak geçirilen yıllar
2. Veritabanı teorisini kavrayacak
3. RDBMS'nin şirket içinde nasıl çalıştığını iyi anlayın
4. İşletim sistemi hakkında üstün bilgi sahibi olmak

Çok disiplinli, bilgili DBA'ların paylaşacak ve önerecek çok şeyi var. Veritabanı performansını, Geliştiriciler tarafından pek düşünülmeyen bir perspektiften görebilirler. Geliştiriciler veritabanından ne istediklerini biliyor. DBA'lar veritabanına nasıl "kibar" olacağını biliyor

Kişilikler gidince her zaman çatışmalar, sıkıntı ve belki de kıskançlık olacak. Kesin olan bir şey var: Belirli bir düzende DBA'lar ve Geliştiriciler, koca ve karılar gibiler (devam etmekte olan projelerle [4 çocuk] 16 yıldır mutlu bir şekilde evliyim).

Kimin koca olduğu, kimin karısı olarak bakıldığı göz önüne alınmaksızın, bu ilkeler geçerlidir:

1. biri diğerine danışmalı
2. biri diğerinin bakış açısına değer vermeli
3. kişi her iki tarafın iyiliği için karar vermeli
4. kişi alınan kararı desteklemeli ve sabote etmemelidir
5. kararlar kötü sonuçlara yol açarsa, biri diğerini inkar etmemelidir.
6. kişi kararların başarısına her iki tarafın da katkısından memnuniyet duymalıdır
7. Kararın karşılıklı olarak kararlaştırılamaması durumunda, daha yüksek bir otoriteye (HA) danışılmalıdır.

Bu yedi (7) ilke, özellikle BT alanında, işyerinde olduğu kadar geçerlidir.

Her şekilde iletişim kurarak herkes şunları yapmalı:

1. beklentilerini belirleme
2. diğer tarafın geçmiş performansına dayanarak kendi rolünü yapma kabiliyetine saygı göstermek
3. karşı tarafın görevini tamamlayabileceğine dair güven ve güveni
4. kendi beklentilerimizi karşılamak
5. HA'nın rehberliği altında devralma (bkz. ilke # 7)

Bu konuda mikro yönetime yer yok. DBA OLMALI SÖYLEYİN DEĞİL nasıl DBA gibi düşünmeye Geliştiriciler. Geliştiriciler söylememeliyiz nasıl Geliştiriciler olmak DBA'ların. Veri tabanı performansı ve kullanımı hakkındaki nihai kararlar DBA'lara dayanmalıdır . Başvuru ihtiyaçları ile ilgili nihai kararlar Geliştiricilere aittir . Bu sembiyoz daima korunmalıdır.

SON DÜŞÜNCELER

İlke # 7, YÜKSEK YETKİLİLİK (HA), yani proje yöneticisi, takım lideri, baş geliştirici tarafından aktif katılım ve denetim gerektirir. HA'nız, her iki tarafın da bireysel olarak nasıl çalıştığını ve her iki tarafın birlikte nasıl çalışması gerektiğini daha iyi bilir. Eğer HA her iki taraf için temel kurallar getirmezse veya HA taraflara bireysel olarak ve birlikte rehberlik edemezse, projeler her zaman bir noktada durur ve Geliştiricinin, DBA'nın varlığını (istihdamını) tehlikeye atar, veya hatta HA.

Ekiplerin farklı bölümlerde / katlarda oturması, bir şekilde "bizi vs onları" zihniyetini teşvik ediyor gibi görünmektedir.

Geliştirme ekibinin tam ortasına DBA'ya oturmak, programcı / DBA duvarını yıkmanın harika bir yoludur. Açık görüşlü kalırlarsa ve egolarını bir kenara bırakırlarsa, hem DBA hem de programcılar bundan faydalanacaktır.

Yüz yüze iletişim, özellikle fikirleri paylaşırken, e-postadan çok daha etkilidir ve yanlış anlaşılmalardan dolayı zor duygular yaşama şansı daha azdır.

Bu tür şeyler, bir yerden bir yere değişebilir. Şu anki sitemde, geliştiricilerle DBA'lar arasındaki satır gerçekten çok bulanık - biz (DBA'lar) PL / SQL de yazıyoruz ve onlar (geliştiriciler) sorgu planlarını inceliyorlar. Hepimiz kendimizi sadece farklı beceri ve sorumluluklarla meslektaş olarak görüyoruz. Bu çok eğlenceli: Son zamanlarda şirket DevOps radyosuna atladı . Veri tabanı topluluğu bunu hiç anlamıyor; biz hep böyle çalıştık. Bunun gibi son derece üretken olduğumuzu söylemeye gerek yok: veritabanı katmanı uzaklardaŞirketin teknoloji yığınının en güvenilir kısmı, kullanımı kolaydır (DBA ekibinde uygulamayı derinlemesine anlayabilme becerisine sahip olduğumuzdan ve geliştiricilerin 24/7/365 işlemlerini ve bunların nasıl yapılacağını anlamak için DBA’ya maruz kalma bunun için uygulamalarını yapılandırmak için).

Ama "yanlış" bir geliştirici hakkında konuşurken ne demek istediğini biliyorum. Kendi içinde asil bir şey olan kendi kendini eğitmiştir, ancak bu arada, her türlü resmi talimatlara karşı bir güvensizlik tespit etmiştir. O bilmediği bilmiyor ve onu aydınlatmak için çalışıyor herkes, onun kendi kendine öğrenme becerilerine bir hakaret olarak görüyor bakmıştır. Zorunlu programlama stilini öğrendi, çünkü bunu CS türlerinin her zaman gevezelik ettiği teorik şeyler olmadan öğrenebilirsin (iyi, kötü bir şekilde; herkesin büyük O'yu bilmesi gerekir).ve benzer teori bitleri). Java kullanmak zorunda olduğu için de bir miktar OO öğrendi. Fakat iyi bir veritabanı uzmanı - geliştirici veya DBA - bildirimsel bir tarzda rahatça düşünmek, küme teorisi, normal formlar hakkında düşünmek, hatta ilişkisel cebir ve hesaplamaları anlayabilmek için rahat olmalı. Bu insanlarla iletişim kurmak çok, çok zordur, çünkü aktif olarak kendilerini rahat bir alandan mahvedebilecek herhangi bir şeye düşmandırlar; bu da bir web sayfasını nasıl biçimlendireceğine bağlı değildir. Veritabanlarını hiç düşünüyorlarsa, bir tablonun bir sınıf ve bir satırın nesne gibi olduğunu düşünürler. Bu adamlar kelimenin tam anlamıyla sadece kendi kodlarındakiSELECT * FROM TABLE sonuçları yapacak ve filtreleyecek ve sıralayacak. Gerçekten de, bir veritabanının neden düz bir dosyadan daha iyi olduğunu anlamıyorlar (ve gizlice ilişkisel bir veritabanı kullanan birinin aptal olduğunu düşünmüyorlar).

Size gerçek bir örnek vereyim: Son zamanlarda, eğer bir sorun QA'dan geçmişse, yazılımımızın piyasaya sürülmesinden sonra piyasaya sürülmesini geri almakla ilgili konular hakkında konuştum. Başvurusunu geri alabilirken (veritabanına erişen pek çoğundan biri), hala dağıtılmış veritabanıyla çalışabilmesi gerektiğini açıkladım. Neden diye sordu ve ben de dedim ki, bu yeni tablo ve sütunlarda gerçek müşteri verileri olacak. Sonra dedi, yani geçici bir tabloya kopyalayın, sorun ne. Ona güvensizlik içinde baktım: bir müşteri aradığında ve söylediğinde, param hesabımdan kayboldu, ona ne söyleyelim, sorun değil, geçici bir masada mı? Diğer insanların parası ile uğraşırken, sorumlu bir yetişkin gibi davranmanız gerektiğinin farkında değildi. Bildiğim kadarıyla hala bilmiyor; o artık bizimle değil.

MySQL kampı uzun zamandır böyle gibiydi; Yaptığınız işlemlere, yabancı anahtarlara vb. ihtiyacınız olmadığını söylerlerdi. Yaptığınızı, sadece ne yaptığınız hakkında hiçbir fikriniz olmadığını düşündüğünüzden, vb. Bunlar, ActiveRecord veya Hibernate gibi ORM'lerin geliştirildiği insanlardı, bu nedenle SQL'e dokunmaya gerek kalmadan veritabanı uygulamaları yazabiliyorlardı. Bu teknolojilerin kullanımı bir kırmızı bayrak olarak görüyorum - bu DBA becerilerine değer veren bir şirket değil. Gerçekten istedikleri şey çocuk bakıcısı ...

Veritabanını daha iyi anlayan bir programcı olarak beni daha iyi bir programcı yaptı. Bir veritabanı yöneticisi olduğumda bu daha da önemli hale geldi, bu nedenle eğitimin anahtar olduğuna inanıyorum.

DBA'lar geliştiricilere, yetkin profesyoneller olarak davranmalarını sabırla yönlendirmelidir. Birkaç programcı, bir ayar işlemi ile müşteri tarafında bir satır satır işlem arasındaki farkı gösterdiğinde fikir kaybedecektir. Aynı hedeflerden bazılarını paylaşıyoruz - uygulama hızı, veri güvenliği, bakım kolaylığı vb. Bu yalnızca uygulama mantığı sorusu için değil, aynı zamanda veritabanı etkileşiminin tüm yönleri için de geçerlidir. Programcılar araçlarını daha iyi kullanmak istiyor ve DBA daha çok veritabanı araçlarını nasıl daha iyi kullandıklarını gösterebiliyor.

Hangi altyapıyı desteklediğimiz önemli değil, kullanıcılarını desteklememiz gerekiyor. Birçok kullanıcı geliştiricidir, bu yüzden geliştiricilere bu altyapının en iyi şekilde kullanılmasını sağlamak için destek veriyoruz. Bunu yapabilmek için farklı fikir ve bakış açılarıyla birbirimizi anlamamız gerekir. Her iki taraftan da görüşlere bakış açısı, işler için işleri daha iyi hale getirmemize yardımcı olur ve bu bizim birleşik hedefimizdir. BT'nin mümkün olan en etkili şekilde iş yapmasını destekleyin.

Birçok organizasyonda tanrı modunda çalışan bazı dba türleri görüyoruz. Bunlar çoğu zaman, yeterlilik ölçülürse çok iyi puan alanlar değildir.

Kanımca, 'programcı dostu' olmakla daha profesyonel olmakla alakası yok. Bir dba için kullanılabilirlik, ölçeklenebilirlik, geri kazanılabilirlik ve performans gibi normal hedefleri kaybetmeden, yardımcı olursak, yaptığımız işleri neden yaptığımızı ve kiraya vermeye hazır olduğumuzu açıklayabileceğimiz anlamına gelir. Programcı için dba ile iletişim kurması, bazen dba öğretmesi, bazen de dba'dan ders alması gerektiği anlamına gelir. Bununla ilgili sloganım şudur: Bir şey öğrenemediğim ilk gün tabutun kafamın üstünde kapandığı gün olsun. Normal işbirliği, geliştiricilerle takımları bir araya getirmek ve dba'lar kesinlikle işleri kolaylaştırmaya yardımcı oluyor.

Bence sorunun bir kısmı perspektif. Dbas ve veri analistleri ve veritabanı geliştiricileri zaman içindeki verilerle ilgilenmek zorundadır. Uygulama geliştiricileri, işleri üretime gönderdiklerinde nasıl işler hale getirecekleriyle ilgileniyorlar. Dağıtıldığında herhangi bir hata olmadığı sürece, verilerin altı ay içinde nasıl görüneceği konusunda çok endişelenmezler.

Ancak veri insanları, verilerin bütünlüğünü yitirmesine veya yinelenen kayıtların eklenmesine neden olan kısa görüşlü kararların sonuçları ile yaşamak zorundadır ve ardından verilerin neden kötü olduğunu açıklamaya çalışırlar. DBA'lar, yalnızca bin kayıt varken iyi çalışan süreçten kaynaklanan performans sorunuyla uğraşmak zorunda olanlardır, ancak şimdi 100.000.000 kayıtla saatler sürmektedir.

Veritabanları refactor için daha zordur, bu nedenle DBA'lar ilk defa doğru elde etmekle ilgilenir. Geliştiriciler, yolun aşağısında yeniden canlanmada bir sorun görmüyor.

Geliştiriciler veritabanını nesne yönelmiş gibi davranmasını sağlamada bir sorun görmezler, veritabanı çalışanları bunun verileri depolamanın veya elde etmenin en etkili veya verimli yolu olmadığını bilir.

Uygulama geliştiricileri çoğu zaman yalnızca küçük bir kayıt alt kümesiyle ilgilenir, ancak büyük miktarda veri ithalat / ihracat veya raporlaması ile ilgilenmez. Bir rekor girmek için iyi çalışan şeyler, bir milyonu almaktan söz ederken işe yaramazlar. Uygulamadaki iş mantığı (genellikle raporlama uygulamasına erişilemez) rapor yazarının bir milyon kayıt için ekranda aynı anda bir kayıt gösterildiğiyle aynı sonuçları almasına yardımcı olmaz.

Sorunun bir diğer kısmı ise her iki tarafa da saygısızlıktır. Veri çalışmasının zor ya da ilginç olmadığını düşünen ve bu işi ancak kendi dünyasında kesemezseniz yapacağınıza inanan birkaç uygulama geliştiricisiyle tanıştım. İnsanlar aptal ve işe yaramaz gibi muamele görmeye iyi tepki göstermezler. Öte yandan, bazı DBA'lar uygulama geliştiricilere saygısızlık göstererek davranma eğilimindedir ve geliştiricilerin veritabanına ne yaptığını gözden geçirme görevlerini düşük öncelikli olarak işleme koyma eğilimindedir (büyük karmaşık üretim veritabanlarına sahip olduğunuzda olabilir). Duymayı reddedebilir veya cevap verebilirler. DBA'nın iki hafta sonra incelemesine kadar tüm projesinin beklemesini kim istiyor? Sonra da kabul edilemez olduğunu ve her şeyi yeniden yazmak zorunda olduğunu söyledi.

SQL Server (1998) ile başladığımdan bu yana geçen yıllar boyunca, birçok geliştiricinin bana işimi nasıl yapacağımı anlattığını gördüm. Onlar bu ilginç bütün biliyorum benden fazla yanı olmanın süper .net geliştiricileri. Aslında onlar da mimardır ve kod maymunu yapmaktan daha büyük şeyler yapmalıdırlar.

Belki de benden yanlış bir tutumdur: ancak birçok dükkanda oldukça yaygın bir geliştirici tutumu. Bunu da birbirlerine yaparlar, unutmayın: akran değerlendirmeleri önerdiğinde dövüşlerin başladığını izle.

Düzeltmeleri diğer cevaplara bırakacağım (şimdiye kadar% 100'le aynı fikirdeyim) ancak yönetim ve mağaza kültürünün işbirliğini desteklemesi ve beslemesi gerektiğini de ekleyeceğim .

Bir geliştirici olarak, senden tek istediğim, ihtiyacım olanı nasıl iletmemi istediğini bilmek. Eğer saçma bir şey istiyorsam, bana söylemeni istiyorum - ve bana söylersen, inanacağım çünkü dürüstlük için bir sicile sahipsin. Ne istediğimi anlamıyorsanız, ne demek istediğimi düşündüğünüzü açıklamak için zaman ayırın - ve dinlemek için zaman ayıracağım.

... Ortak tema, doğru ... İletişim ... iletişim ... iletişim.

Bunu koymak için gerçekten daha iyi bir yol yok. Geliştiriciler gıdıklandı çünkü "DBA bana bunun yapılamayacağını söyledi - geçen sefer yanlış olduğunu kesin olarak kanıtladım." DBA'lar işaretlendi çünkü “bu geliştirici özelliklerini her değiştirdiğinde ne yapmam gerektiğini anlamıyor”.

Geliştiricilerin ve DBA'ların @Rolando’da belirtildiği gibi birbirlerini anlamaları gerekir. Her şey onun üstüne geldiğinde, ikimiz de "Ones & Zeros" diyoruz - bunun iyi bir eşleşme olacağını düşünürdünüz. 2 sorumluluk alanımız var: DBA'ların verileri var, Geliştiriciler bilgisayarın geri kalanını alıyor. Ancak veriler olmadan, programcıların yapacak çok şeyi olmazdı.

Bizim bir DBA'mız yok ve zaman zaman acı veriyor. On yıl önce DBA olmak isteyen o parçam, yaptığımız bazı şeyleri gördüğümde sıkılaşacak. Yarın bir DBA kiralarsak, yürüdüğü yeri öperdim sanırım.

Bazı şirketlerde, belki de çoğunda, ürün geliştirmenin derlenmiş bir dilde yazamayan birini görmezden gelme eğilimi vardır. Serbest bırakma zamanı geldiğinde, direnç var çünkü ağ yöneticileri, DBA'lar, sistem yöneticileri, kullanıcı desteği vb. Genellikle baş ağrıları vardır, çünkü çevrenin kilit yönleri dikkate alınmamıştır. Bu doğal olarak takımlar arasında gerginliğe neden olur.

Burada kim suçlanıyor? Bayan İletişim

Geliştiricilerin konuşlandırılacağı çevre kodunu anlaması gerekir. İnsanlara uyum sağlamaları için adil bir uyarı verilmesi gerekir. Ortamın hangi nedenle olursa olsun (güvenlik, ekipman, politika) uyum sağlayamadığı durumlarda, yazılımın uyum sağlaması gerekir. Bu, tasarım ve uygulama sürecinde gerçekleşirse, herkes mutlu olur. Konuşlandırma zamanına kadar başlamazsa, incinmiş bir dünyadır.

Evet, takımların birbirleriyle konuşması (ve dinlemesi) gerekir, ancak proje / ürün müdürünün bunun olabileceği bir ortam yaratması gerekir.

Şanslıydım, çalıştığım çoğu yerde karşılıklı saygı ve iletişim kültürün bir parçası.

İyi bir DBA'nın anlaması gereken tek şey, veri politikasıdır. Birkaç yıl boyunca veritabanı programcılığını ve tasarımcılığını, deneyimli programcılara ve birkaç tane hazırlanmış DBA'ya öğrettim. Düzenli olarak ortaya çıkacak bir soru şuydu: dükkanımdaki tüm veritabanları nasıl bu kadar politik hale geldi?

Standart cevabım şuydu: Eğer veritabanı faydalıysa, o zaman veri paylaşıyorsunuzdur. Veri paylaşıyorsanız, gücü paylaşıyorsunuzdur. İktidar paylaşıldığında, politika olur.

Politikayı sevmeniz veya politikadan nefret etmeniz önemli değil. İyi bir veritabanı çalışması yapacaksanız buna alışın.

Bu arada, bazılarınız yalnızca bir geliştirme ortamında çalıştınız. Çitin üretim tarafında çalışan ve geliştiricilerle çok az etkileşimi olan DBA'lar var. Üretimde daha az politika olduğunu düşünebilirsiniz. Fazlası var. Büyük üretim veritabanları, işletme çapında olma ve görev kritik olma eğilimindedir.

Biraz alçakgönüllülük bazılarınız için yardımcı olabilir. ;)

Her iki yaklaşım için de açıkça geçerli argümanlar var, bunu tanıyarak başlamanızı öneririm. Yazılım geliştirme, doğru travmaları yapmakla ilgilidir. İki yönlü bir cadde ise, belki DBA'lar da açık fikirli olmalıdır.