Buna diğer bir bakış açısıyla, yani ekip liderinin bakış açısıyla bakmaya değer:

İki farklı yapınız var, biri kanıtlanmış, muhtemelen benzerleri destekleyen çok sayıda insanla test ediliyor. yapılandırılmış uygulamalar. İkincisi, teknik akıl yürütmeyle, ancak en önemlisi, ticari gerekçeler olmadan size getirildi.

Artık o bölgede çalışmadığı için amacınızı anlamamak yerine, siz ' onu anlamıyoruz. Gerekli mantık teknik değil, iş. Başkalarının öğrenmesi gereken yeni bir sistemi uygulamanın maliyet etkisi vardır (insanların öğrenmesi için geçen süre). Tartışmalarınızdan herhangi biri bu konuyu ele aldı mı?

Sorunu uygulamanızın geliştirilmesi bağlamında görüyorsunuz, işle entegrasyon bağlamında değerlendiriyor.

Takım liderim, yazılımın başka bir parçasının zaten üretimde olduğu gibi tabloyu kullandığı gerçeğine dayanarak yapıyı gerçekten değiştirmek istemediğini söyledi

Bu mevcut bloktur. Takım lideriniz, bu tabloyu bölme önerinizi takip etmek için diğer yazılım parçasının değiştirilmesinin (ve risk değerlendirilip test edilip dağıtılmasının) değip değmeyeceğini tartıyor.

Bu alanlar arasında bire bir bağlantı var gibi göründüğü için, bu bir tabloyu üçe bölmeye gerçekten ihtiyaç olup olmadığını da sorguluyorum.

Önceki işimde, ilk olarak yıllar önce yeni bir müşterinin isteği üzerine yapılmış bir modül üzerinde çalışıyordum. Yeni müşteri bize taşınıyordu ve kötü düşünülmüş bir yapıya sahip eski bir veritabanı kullanıyordu. O zamanki teknik ekibimiz, zaman uğruna yapıyı tamamen olduğu gibi benimsemeye karar verdi.

Sonunda herkes müşteriyi unuttu ve yeni ürünümüz, yeni özellikler ve diğer müşterilerin ilgisiyle gelişti. Ancak, katıldığım günden ayrıldığım güne kadar beni rahatsız eden kötü yapı kaldı.

Sizin argümanınız, buna başka herhangi bir ürün gibi davranılması ve tasarım kararlarınızı temel almanız gerektiğidir. gelecekte de ne işe yarayacak. İyi düşünülmüş bir şema, sizi saatlerce kafanızı tırmalamaktan ve koli bandı ve dualarla birlikte bir şeyleri hacklemekten kurtaracaktır. Burada deneyimlerime dayanarak konuşuyorum.

Ana argüman, size zaman kazandıracağı ve gelecekte baş ağrılarından kurtaracağıdır. Yarı düzgün bir şema tasarlayabilmeli ve ardından müşterinin yapısıyla uyumlu bir arayüz (yani veritabanı görünümü) gösterebilmelisiniz. Bu, sizi başka birinin kötü kararlarına bağlamadan ihtiyacınız olan tüm esnekliği sağlar.

Normalleştirme kurallarını biliyor ve bu yapının onları çiğnediğini biliyor, ancak bu onun için mantık yürütmek için yeterli değil.

Ve haklı olarak öyle. Normalleştirme genellikle iyi bir şey olsa da, ondan sapmak için iyi nedenler olabilir. Şu anki işimde epey bir süredir, yeni geliştiriciler için mülakat sürecinde normalleşme hakkında sorular sorardık ve adayın normalleşmeyi bildiğini belirledikten sonra, neden istediğiniz nedenleri düşünüp düşünemeyeceğini sorardık. verileri denormalize edin.

Ona zaten normalleştirilmiş bir yapıyla çalışmanın benim için daha kolay olduğunu açıklamaya çalıştım ama bir şekilde başaramadım.

Bu bir argüman, ancak çok güçlü değil. Alternatifler diğer tüm açılardan eşit derecede iyiyse, çalışmak daha kolay olur.

Normalleştirilmiş verilerin bu proje için doğru şey olduğunu düşünüyorsanız, nedenini bu doğru şey. Normalleşmenin yararları ve sakıncaları vardır; Liderinize, faydaların neden bu proje için dezavantajları geride bıraktığını gösterin. Yani, normalleştirilmiş verileri kullanmanın genel faydalarının bu özel proje için geçerli olduğunu (ve dezavantajlar için de aynı şeyi) göstermeniz gerekir. Potansiyel müşterilerinizin kavram kanıtı, mevcut bir veri yapısına bindiriliyor olduğunu dikkate alın; Bunu sizin önerinizle yapamamak bir dezavantajdır (özellikle de bindirme kodun yeniden kullanımıyla geliyorsa).

Daha önce bir takım lideriydim ve normalleşmenin kurallarını çok iyi biliyorum, bu yüzden burada araya gireceğim.

Ona zaten bunun böyle olduğunu açıklamaya çalıştım. normalleştirilmiş bir yapıyla çalışmak benim için daha kolay, ancak bir şekilde onu ikna edemedim.

Normalleştirme akademisyenleri

Normalize dediğinizde, tam olarak hangi normalizasyon seviyesi / standart doğrudur? 2. normal form? 3. normal form? Boyce – Codd normal formu? 6. normal biçim mi?

Her biri artan kural karmaşıklığına sahip birçok normalleştirme düzeyi vardır: https://en.wikipedia.org/wiki/Database_normalization

Dolayısıyla, normalleştirme iyi olduğu için X'in Y'den daha iyi olduğunu söyleyerek, neyin doğru olduğuna dair tek ve kesin bir kuralı ima etmiş oluyorsunuz.

Normalizasyon ve ödünleşmelerin analizi

Öncelikle yazma performansını optimize etmek ve veri tutarlılığını garanti etmek için normalleştiriyoruz.

GitHub veritabanı performansı hakkındaki şu sayfaya bakın: https://johnnunemaker.com/database-performance-simplified/

"Yazmalar nasıl optimize edilir" önerilerinin, "okumalar nasıl optimize edilir" önerilerinin tersi olduğuna dikkat edin? Bu, bulacağınız genel bir kalıptır. Okuma performansı ile yazma performansı arasında bir denge vardır.

Açıkladığınız spesifik normalleştirme koşulu, bir tabloyu 3 tabloya bölmektir. Bunun 1: 1 olmadığını varsayalım ve bu nedenle bazı tabloların satır sayısı daha küçüktür ve depolama alanını azalttınız. Bu, söz konusu veri kümesine yapılan güncellemelerin daha verimli olabileceği anlamına gelir. Şimdi veri setini nasıl okuyorsunuz? 3 masaya katılarak. Katılmak için 1 yerine 3 tabloya bakmanız gerekir, bu nedenle daha pahalı olur.

Yazıları, okuma pahasına optimize ettiniz.

Geçmiş bir rolde, neredeyse her önemli sorgunun yalnızca tek bir değer bulmak için belirli bir tabloda birleştiğini gördük. Çoğu sorgunun maliyetinin% 10'u bu tek tabloya katılmaktı. Filtrelemek için kullanılmıyordu. Bu nedenle, bu sütunu (asla değişmeyecek olan) birkaç sıkça sorgulanan tabloya kopyalamak, pano genelinde performansı% 10 artırdı. Ne yaptıklarını bilen insanlar tarafından düşünceli ve kasıtlı bir karardı.

Örneğinize geri dönelim. Bu tabloyu 1: 1 ilişki ile 3 tabloya bölerseniz, her zaman güncellemek için en az aynı sayıda satıra sahip olursunuz, bu nedenle yazma açısından bir fayda yoktur, ancak şimdi okurlar 3 tabloya katılmak zorundadır. Yani bir fayda sağlamadan bir performans maliyeti alıyorsunuz.

Sonuç

Bazı veriler okunduğundan çok daha sık yazılır. Bazı veriler yazıldığından çok daha sık okunur. Okuma verimliliği ile yazma verimliliği arasında bir değiş tokuşumuz olduğundan, kullanım modellerimizle eşleşen durumu optimize etmeliyiz.

Şirkette yeni olduğunuza göre, takım lideriniz muhtemelen daha fazlasını biliyor bu verilerin sizden daha iyi nasıl kullanıldığı hakkında .

Bir dahaki sefere

Öyleyse: Ekip liderimi başka bir veri yapısının daha iyi olacağına nasıl ikna edebilirim?

Bunu stackoverflow'a veya DBA Stack Exchange'e getirmediğiniz ve sorunuzu haklı olduğunuz birini nasıl ikna edeceğinizi sorarak sonlandırmanız, ekibinizin liderliğini düşünmediğinizi gösteriyor aslında haklı olabilir.

Bir dahaki sefere, endişelerini açıklamasını isteyerek bir anlaşmazlığa yaklaşmalısınız ve sonra hala aynı fikirde değilseniz, stackoverflow.com veya dba.stackexchange.com adresine gidip sorun teknik değerleri size açıklayacak biri. Anlaşmazlıkları, iradenizi başkalarına dayatmak için fırsatlardan ziyade bir öğrenme fırsatı olarak görmeye çalışmalısınız. Özellikle yeniyseniz ve etrafınızda kendinizden daha bilgili kişilerle çevrili olduğunuzda.

Bu bana, bu SE için biraz fazla teknik görünüyor. Yine de size iki sentimi vereyim.

Burada bir tahminde bulunuyorum, ancak resminizden uzun süredir çalışmıyorsunuz gibi görünüyor. Muhtemelen son zamanlarda öğrendiğiniz şeyler konusunda hala zinde ve heveslisiniz. Bu övgüye değer.

Ancak yeni bir yere geldiğinizde gidip statükoya meydan okumak her zaman en iyi fikir değildir. Özellikle uzmanlığı için işe alınmış çok kıdemli bir kişi değilseniz (yine tahmin ediyorum).

Bu veritabanı tablosunun olduğu gibi tasarlanması için çok sayıda neden olabilir. Aşağıdakileri içerebilir, ancak bunlarla sınırlı olmayabilir:

• "tarihsel nedenler" (birinin daha iyi bilmediği gibi)
• verilerin denetim için gereksiz olması gerekir nedenler (sabit olması gerektiğinden, her bir ürünün fiyatını tutan e-com siparişleri ve buna bakmak yerine KDV gibi)
• hız
• çok fazla veri onu yeniden düzenlemek ve tabloyu değiştirmek sonsuza kadar sürecek
• "geliştiricilerimiz için çok zekice"

Gerçek hayatta çoğu zaman en iyi uygulamaların her zaman takip edilmez. Bazen bu işle ilgili nedenlerden dolayıdır, bazen bunun nedeni yeterli zamanın olmaması ve iş değerlerinin kaliteden daha hızlı yayılması ve bunun teknik borç oluşturacağının farkına varmaktan çok uzak olması ya da teknik borca ​​ve maliyete çoktan alışmış olmasıdır. bakımın değişmemesi veya belki de sorumlu kişinin yetersiz kalması.

İster ticari ister teknik nedenlerle olsun, bu kararın tüm alternatifler tartıldıktan sonra kasıtlı olarak alındığı durumlar vardır. Dışarıdan "yanlış seçim" gibi görünen şey, bu iş için pekala en iyi seçim olabilir. Dışarıdan görmek çok zor, özellikle de deneyiminiz olmadığında. Sonuçlara varmak çok kolay.

Yeni kod yazarken, işleri "doğru" şekilde yapmayı deneyebilirsiniz. Bunu savunmaya, diğer geliştiriciler sizin kadar iyi eğitimli olmadığı için bunun için dokümantasyon yazmaya veya insanlar değişimden hoşlanmadığı için iyileştirmeleriniz için savaşmaya hazır olun. Ancak, akademik olmayan yaklaşım işe daha çok uyduğu için başkalarının argümanlarının nihayetinde daha iyi olabileceğini unutmayın.

Bu arada, yavaşlamanızı, yerin nasıl işlediğini öğrenmenizi ve bir şeyler yapmayı öneriyorum. orada yapıldıkları yol. Neden yaptıkları gibi yaptıklarını anladığınızda daha iyi uygulamalara geçin, böylece uygun argümanlar getirebilirsiniz. Bazı öğrendiklerinizi ortadan kaldırın. Tüm bunlarda kazanılacak bilgi var.

Buna kesinlikle normalleştirilmiş bir şekilde sahip olmanız gerekiyorsa, bir soyutlama katmanı yazın. Onlara kodunuzun nasıl daha iyi / daha hızlı / bakımı daha kolay / daha güzel / daha karmaşık / neyse onu gösterin ve bunun neden tercih edildiğini açıklayın ve ardından soyutlama katmanını mevcut kodu yeniden düzenlemek için geçici bir çözüm olarak kullanmaya ikna edin, böylece yapabilirsiniz ardından veritabanını yeniden düzenleyin.

Kanıt toplayın.

Her birinin profesyonellerini ve eksilerini tartın ve ona neden yolunuzun mevcut yapıdan daha iyi olduğunu ve ekibinize / şirketinize nasıl fayda sağlayacağını söyleyin. Neden yolunuzun daha iyi olduğuna ve bunu neden yaptığınıza odaklanın.

Buradaki yanıtların çoğu, burada aynı konunun farklı yönlerine atıfta bulunur: Bu, bu durumda nispeten düşük bir düzeyde olmakla birlikte, yazılım mimarisi ile ilgilidir.

Yine de, yazılım mimarisinde kararlara varmak için çok iyi bazı yaklaşımlar var (sonuçta, yazılım mimarisi bununla ilgili) ve burada size yardımcı olabilir.

İlk olarak, toplayın. ilgili gereksinimler ve kısıtlamalar. Genellikle bunlar IEC 9126 gibi bir standardın gereksinimlerini içermelidir. Örneğin, tablolar normalleştirildiğinde sürdürülebilirlik artabilir. Ayrıca, tablolar zamanla nasıl davranır? Çok fazla veri eklenecekse, bir çözüm diğerinden daha üstün olabilir - ancak bu yalnızca performans önemliyse geçerlidir.

Ancak tablo üzerinde halihazırda çalışan mevcut yazılım, uyulması gereken bir kısıtlamadır . Diğerlerinin önerdiği gibi, bu bir uyumluluk katmanı (örneğin bir görünüm) gerektirebilir. Bunu çözüm tasarımınıza da dahil etmelisiniz.

Genel olarak, mevcut bir çözümü böyle değiştirmek istiyorsanız, yukarıda bahsedilen standardın (veya diğer standartların) yardımıyla argümanlarınızı iyi hazırlayın. . Yazılım için halihazırda bir yardımcı program ağacı varsa, iyi argümanlar toplamanızı (veya tek tablonun belki de en uygun olanı olduğunu tespit etmenizi çok daha kolay hale getirmelidir. Çözüm burada).

Ama sadece "bu verilerin normalleştirilmesi gerekir çünkü bunu böyle yaparsınız" demek yazılım mühendisliğinde gerçekten yeterli değildir. Yeni mezunlara tuhaf görünebilecek birçok teknik çözüm var, ancak tüm kısıtlamaları ve (işlevsel olmayan) gereksinimleri kontrol ederken tamamen uygun. (Ve elbette, olmayan çok daha fazlası var.)

Tuhaf bir şekilde, RDBMS'de geçmişi tutmak için her iki varyantınız arasında (her iki yönde de!) mevcut tabloları tasarlamam, aralarında karar vermem veya değiştirmem gereken bir durumdaydım, öyleyse oynayayım the advocatus diavoli burada.

Kısa ve basit tutayım: evet, normalizasyon iyidir ve şüpheniz varsa normalleşir. Ancak, tamamen aptalca olmayan nedenlerle (örneğin, performans veya kullanım kolaylığı) gönüllü, kasıtlı fazlalık kullanan veri depolama biçimleri (bu tür bir tarihleme gibi) vardır. Bu, işyeri.SE yerine stackoverflow.SE olsaydı, derinlemesine gidebilirdik, ama hadi burada ortaya koyalım.

Başka bir özellik de bazen (n + 1 ) önceki n yinelemeleri gibi bir şeyin tekrarlanması BT'de değerli bir şeydir ve karşılaştığınız her bit için yeni bir tasarıma sahip olmaktan cüce olabilir. Yeni tasarım gerçekten eskisinden daha iyiyse, eski olanın tüm oluşumlarını aynı anda değiştirene kadar eskiyi korumak faydalı olabilir.

Tüm bunlar işyeri için fazla teknik olabilir, ancak asıl önemli olan takım liderinizin bir noktaya sahip olmasıdır. "Tüm tablolar her zaman normalleştirilmelidir" den daha fazlasına ihtiyacınız var. Benzer vakalar için benzer bir yaklaşım gibi geçmişini, geleceği, yumuşak yönlerini ve hatta evet, diğer geliştiricilerin / paydaşların içgüdülerini, fikirlerini ve önyargılarını tartmalısınız.

Benim düşünceme göre, yaklaşımınızın sıçramalarla ve sınırlarla daha iyi olduğunu gerçekten sıkı bir kodla kanıtlayamazsanız , bir iş arkadaşınız yine de bazı Konuyu çevreleyen ve en azından onunla kalıp kalmayacağını tartışılabilir kılan yönü, bu yüzden ... dövüşünü akıllıca seç. Elbette biraz zorlamaya çalışın ama bunun üzerine uykunuzu kaçırmayın.

@JozefWoods'un mükemmel cevabını biraz genişletmek gerekirse, teknik borcun geri ödenmesi yalnızca bu borcun genel giderleri büyük olasılıkla aşacaksa mantıklıdır bunu düzeltmenin maliyeti. Bu maliyet sadece uygulamayı değil, her türlü manuel testi, dokümantasyonu, onunla arayüz oluşturan her yazılım parçasını değiştirmeyi, geçişi, kesinti süresini, hataların ortaya çıkma riskini içerir ve en önemlisi, fırsat.

Yaygın bir pratik kural, uygulamayı başka bir şeyi uygulamak için değiştirirken yalnızca dokunduğunuz kısımları yeniden düzenlemektir ve ardından çok dikkatli olmaktır. işin yeniden düzenlenmesi, toplamın küçük bir parçasıdır. Bunu tutarlı bir şekilde yapmak, teknik borcu her seferinde küçük bir parçaya kesmek, büyük çamur toplarında bile harikalar yaratabilir.

Buradaki cevap çok kısadır:

Normalleştirilmiş yapınızın işletme için sorunları nasıl çözdüğünü gösteren bir demo oluşturun.

Düz masayı kullanan başka projeler olduğunu söylediniz. Demo bu diğer projeleri ve yeni projeleri içermelidir.

Normalleştirilmiş tablolar her durumda en iyi seçenek değildir. Bir teknoloji liderini bir şey yapmaya ikna etmek istiyorsanız, teklifinizin herkesin işini nasıl kolaylaştırdığını veya daha büyük bir sorunu ders kitabı teorisiyle değil, çalışan bir demo ile nasıl çözdüğünü gösterin. Demo, tek başına herhangi bir tartışmadan çok daha güçlü bir öneridir.

Bu, kodun kelimelerden daha yüksek sesle konuştuğu bir durumdur. Bir sürümü kendi yönteminizle, bir sürümü kendi yolunuzu kullanarak ve bir sürümü üst katmanda kendi yolunuza çevirerek alt katmanda kendi yolunuzu kullanarak yazın. Veri yapınız gerçekten üstünse, bunu yansıtacak kod yazabilmelisiniz. Tüm özelliği 3 şekilde uygulamak için çok fazla zaman harcamanıza gerek yok, sadece bunu anlamaya yetecek kadar.

Bazen, bu alıştırmayı yaptığımda, aslında hoşlanmadığım yolu buluyorum '' t çok kötü. Genellikle, başka bir sürümü daha temiz yazmama yardımcı olacak şeyler yazarak öğrenirim. Neredeyse her zaman her iki yaklaşımın artılarını ve eksilerini daha kesin bir şekilde ifade etmeyi öğreniyorum.

Yapıyı değiştirmek benim için biraz kırmızı ringa balığı durumudur. Temel soru, programcıların neden en başta belirli bir uygulamayı karşılaması gerektiğidir.

Kapsanması gereken işlevsellik, gerekli olanı yapmak için işlevler sağlayan iyi bir API'de sunulmalıdır. ve bunları, uygulamanın ayrıntıları API'nin her yerine sızmadan bazı verimli uygulamalarla eşleştirir. Bu bir kez elde edildiğinde, veri yapısının kullanıcıları için hayat daha kolay hale gelir ve veri yapısını performans profiliyle daha iyi eşleşen bir şeyle değiştirmek, API ve altta yatan yapının bakımcıları için daha kolay hale gelir.

Bu nedenle, arzunuzu dört ayrı göreve ayırdım: mevcut ve istediğiniz veri yapısını çalıştırmanın en verimli yolunu desteklemek için gerekli ifadeye sahip iyi bir nötr API tasarlamak, bu API'yi uygulamak, mevcut kod (bir kullanılabilirlik / sürdürülebilirlik sorunu) ve sonra, farklı bir uygulama önerme ve performans sonuçlarını kontrol etme durumu nispeten ucuzdur.

Teoride. Pratikte burası, insanlar en sevdikleri hack için API'nizi atladıkları ve alttaki uygulamayı değiştirerek bozulan API'nizi atladıkları için "bu API'yi kurmanın" aslında tamamlanmadığını öğrendiğiniz yerdir. Ya da aslında hiçbir şeyi değiştirmedi. Ancak o zaman bu değişikliği sarmak için daha iyi bir konumdasınız ve API tasarımınızın iyi ve eksiksiz olduğunu varsayarsak, insanlar zamanında bundan memnun olacaklardır. Ve yapmaları daha iyi olur, çünkü değilse, bu dublörü gerçekleştirme sayınız sınırlı olacaktır, bu yüzden her şeyi doğru yapsanız iyi olur.

Bu harika bir soru ve bunun sıklıkla gündeme geldiğine inanıyorum! Anlaşılması gereken ilk şey, teknik bir iş yapıyor olmanıza rağmen, teknik alanda kararlar nadiren yalnızca teknik faydalar temelinde alınır. Bu, birilerinin üniversite gibi geleneksel bir eğitim kanalından günümüze kadar yaşadıklarından son derece farklıdır.

Deneyimlerim bir kez devreye girdiğinde, işle ilgili karar verme süreçleri teknik olanları geçersiz kılma eğilimindedir. Bu nedenle, işletmeyi bu veri şemasını değiştirmeye ikna etmek için normalleştirilmiş bir yapıyı savunmak gibi tasarım ilkelerine atıfta bulunmak yerine iş perspektifinden tartışmanız gerekir.

Bunun anlamı Veri yapısını değiştirmenin neden işletme için daha iyi bir sonuç doğuracağını ifade etmek. Normalleştirme 'ye daha iyi bağlı kalarak, önerdiğiniz değişiklikler nedeniyle insanların fikirlerini değiştirmek için yeterli olduğunu iddia edemezsiniz.

Davanızı belirtmek için daveti de incelemenizi tavsiye ederim. . Öncelikle, diğer mühendislerin kararı desteklemek için ne kadar istekli olacağını bulmak için bazı invaziv olmayan yöntemler denemelisiniz. Ne zaman ve hangi savaşların yapılacağını seçmek önemlidir. Değişim için bir iştah yoksa, ilerlemek verimli olmazdı, çoğu zaman insanlar değişikliği kabul edeceklerinden daha az kolaylaştırıyorlar. Şemanın neden değiştirilmediğini anlar ve bu noktada değiştirilmemesi gerektiğini kabul ederseniz, amacınıza daha iyi hizmet edebilir.

Ancak doğru zamanı ve parçayı beklerseniz kucağınıza düşecek bir iş, o zaman önerilerinizi uygulamaya koymak için daha fırsatçı bir zaman olabilir.