Doktrin ve Propel, nesne ilişkilerini haritalamak için tek ve somut tablo kalıtımını kullanır. Birincisi, sınıf ağacındaki tüm olası alanları tek bir tabloya eşlenirken görürken, ikincisi her sınıfı belirli bir tabloya eşler ve kalıtım hiyerarşisindeki ortak alanları çoğaltır.
Bu ORM cihazını kolaylaştırırken, bana kötü veritabanı tasarımı önerir. Bu kötü tasarım kalıpları bir veritabanında uygulanacak mı?
Yanıtlar:
Uygulamanın ne yaptığını, verilerin şeklini, performans beklentilerini vb. Bilmeden belirli bir veritabanı tasarımının kötü olup olmadığını söylemek imkansızdır. Genellikle normalleştirme (bir dereceye kadar) en iyi uygulama olarak görülmekle birlikte, veri tabanlarının alanlarını performans nedenleriyle denormalize etmek oldukça yaygındır, bu nedenle iyi ve kötü, çoğu insanın başladığı zamandan çok daha fazla veri olmadan tartışmaya çok açıktır.
İlişkisel eşlemelere itiraz edebilecek birçok yaklaşımı ekleyin ve "en iyi" veritabanı yapısı belirli nesne modeline, kalıtım düzeyine ve benzerlerine bağlı olacağından işler daha da karmaşık hale gelir.
Tek bir boyuta uyan tüm yaklaşıma uygun ORM kalıcılığı kütüphaneleri neredeyse her zaman herhangi bir durum için optimal olmayan bir veritabanı yapısı üretecek ve belirli bir durum için kötü uygulama olarak görülebilecek bazı şeyleri kullanacaktır .
Kesinlikle normalize edilmiş bir ORM yazabilirsiniz, ancak ana tablodaki her ekleme için oldukça ağır performans sonuçları görürsünüz, değerlerin var olup olmadığını, anahtarlarını elde edip etmediklerini ve almadılarsa görmek için çeşitli arama tablolarını taramak gerekir. ilgili kesici uçları gerçekleştirmeyin.
(Bunu elle yaptığınızda, bunlara sadece geçerli değeri içeren bir açılır liste ile sunduğunuzu bildiğiniz için bazılarını kısaltabilirsiniz, böylece bu aramaları yapmanıza gerek kalmaz, sadece gittiği için mutlu anahtarı kullanabilirsiniz. geçerli olması için ORM, kullanıcı arayüzünü kontrol etmediği için bu varsayımı yapamadı.)
Ancak hatırlamanız gereken şey, veritabanı performansı veya veri bütünlüğü için optimize etmeyi hedeflemedikleri, geliştirme hızı için optimize ettikleri . Verilerinizin belirli yapısı sizin için önemliyse, nesne / RDBMS eşlemelerinizi elle kodlamanız veya en azından mevcut tüm kütüphanelerin ayrıntılı bir değerlendirmesini yapmanız ve ihtiyaçlarınızı en iyi karşılayanı seçmeniz gerekir ( varsa).
Temelde gereksinimler ve iyi yapılandırılmış veri, veritabanı performansı ve geliştirme hızı arasındaki değiş tokuş ile ilgilidir. Birçok değiş tokuşda olduğu gibi üçünü de seçemezsiniz.
ORM'in normalleştirmeyi veya kötü veritabanı tasarımını desteklediğini kabul etmiyorum. Aslında gördüğüm en kötü tasarlanmış veritabanları ORM'siz yapıldı. Rastgele bir alanın değerine dayalı bir ilişki yapmak yerine satır kimliğine dayalı uygun ilişkilere sahip olmayı basitleştirerek, iyi bir veritabanı tasarımını teşvik eder.
Muhtemelen normalleşmeyi desteklemez, ancak yine de tablo / nesne ve ilişkilerin yapılmasının kolay olduğu bir ORM de bunu teşvik etmek için neredeyse görülebilir. Bir ORM'de adresleri içeren bir "konum" tablosu oluşturmak ve adresi çalışan tablosuna eklemek yerine çalışanları konuma bağlamak daha fazla iş değildir. Ancak ORM olmadan, konumu ayırmak, konuma her erişmek istediğinizde bir katılmanız gerektiği anlamına gelir.
Yani cevabım: Hayır, sanmıyorum . Muhtemelen başka bir yol daha var, iyi bir ORM , en azından az deneyime sahip olanlar hakkında iyi veritabanı tasarımını teşvik eder .